Reg Juju Api

[Rajendar K]

Hi Mark,
                Thanks for your kind reply.
It makes me to understand better about juju..

Here are my few queires..






*(i) Each charm starts with a "blank" machine, like "centos6" or "trusty"
or"windows8", and then does what it needs to do to add the service
itdescribes to that machine. So for each cloud you just need to know
whatthe "blank" machine image is for the OS versions your charms will
use.IN future we might support creating snapshots which can be reused
forfaster startup of additional machines. [Mark]*

- I very much impressed with the way of the drag and drop of the VM
deployment.
My question is about, how the deployment of VMs made from the charm store.
[ the way i drag
and drop from charm store]. It means the image format handled at charm
store is neutral or
how it is being handled to cater across the clouds.?

(ii) Reg configuration management ( building relations)
      How the configuration management is handled? [ not for creation of
new charms].
Existing charms how the configuration is being made ( by drawing the
relation between the VMs]?
For eg : Wordpress with Mysql
IS the relation already pre-defined on each charm.[how the IP and hostname
being exchanged across
the VMs].


(iii) How to download and use charms from charmstore?
        I need to download charm from charmstore and boot on KVM/hypervisor.
Also it would be useful, if you could let details the format (image format)
managed at charm store.



with thanks and regards,
Raj




On Wed, Feb 25, 2015 at 10:19 PM, Mark Shuttleworth <mark at ubuntu.com> wrote:

> On 25/02/15 11:30, Rajendar K wrote:
> >           Quite new to this forum.
>
> Welcome!
>
> > I would like to know the details about the juju-API for communication to
> > public clouds (Amazon, etc).(where i can download
> > and start using)
>
> There is code built into Juju that knows about each cloud; we call that
> a "provider", it's like a driver for the cloud, and it maps what Juju
> needs to the API of that particular cloud. Those are usually written in
> Go and built into Juju core itself; the libraries can typically be
> reused in your own Go project easily enough and we would take patches if
> they were helpful for others too.
>
> If you have a cloud that speaks an entirely new API, there is a
> short-cut to getting up and running, which is called a plug-in. The
> plug-in runs on the client, not the server, and basically allows you to
> use shell scripts that talk to your cloud, and have Juju call those when
> it needs to do things like start a new machine. The machines are started
> by your shell script, then Juju remotely logs in to the machine and
> "manually" configures it. There are a few sets of plug-ins for popular
> clouds that don't yet have full providers built-in to Juju.
>
> > I have my own cloud infrastructure, is it possible to call those APIs for
> > managing VMs across Cloud platforms?
>
> Yes, if your cloud talks a common API like AWS or OpenStack, then you
> can probably use the native API support built in to Juju, otherwise I
> would suggest you start with a plug-in and then write a Go provider when
> you think it's time to do so.
>
> > Also i would like to know about juju charms, especially the image
> > management how it is being handled.?
>
> Each charm starts with a "blank" machine, like "centos6" or "trusty" or
> "windows8", and then does what it needs to do to add the service it
> describes to that machine. So for each cloud you just need to know what
> the "blank" machine image is for the OS versions your charms will use.
> IN future we might support creating snapshots which can be reused for
> faster startup of additional machines.
>
> Does that answer your question?
>
> Mark
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150226/6a9284a6/attachment.html>