Reg Juju Api

[Kapil Thangavelu]

On Wed, Feb 25, 2015 at 8:05 PM, Rajendar K <k.rajendar at gmail.com> wrote:

> 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.?
>

The charms specify a symbolic identifier for an os name & version aka the
series which is resolved in each cloud using simple stream tools which maps
those symbolic names to actual images in each cloud. For all the major
public clouds simple streams are published for users. For private clouds or
smaller public clouds, the user has to manage that process themselves.
Specifically the case of smaller public clouds typically entails either
re-using the manual provider (ie client side api automation with ssh or
userdata initialization) or writing a cloud provider for juju.  There are
several client side plugins using manual provider extant (digitalocean,
softlayer, etc).

The source tree for juju (https://github.com/juju/juju) contains the
various provider implementations extant.

>
> (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].
>

relations form a bi-directional communcation channel across which this
information is carried and actions taken out. ie. mysql upon receiving a
new client relation will create a new logical db, user, password and pass
along with its address along the relation to its client.

the charms themselves declare in metadata their relations by interface. ie.
mysql declares it provides the mysql interface, wordpress declares it
requires the mysql interface, alternate implementations of those interfaces
are readily interchagable. ie. using amazon aurora/rds for mysql.


>
>
> (iii) How to download and use charms from charmstore?
>

atm the charm store contains charm artifacts pulled from vcs in launchpad.
there are a few mirrors or dual published charms to github as well.


>         I need to download charm from charmstore and boot on
> KVM/hypervisor.
>

the juju environment will automatically do that for you, else you can
checkout one out via vcs and deploy it as a local charm. (see docs).



> Also it would be useful, if you could let details the format (image
> format) managed at charm store.
>
>
there are no images being managed by the charm store, just the symbolic
identifier as described above embedded in the charm typically at publishing
time.



cheers,

Kapil


>
> 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
>>
>>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150225/ef756c56/attachment.html>