On Thu, Feb 26, 2015 at 7:48 PM, Rajendar K <[email protected]> wrote:
> Hi Kapil, > Thanks for your clear description about my queries. > > I have installed and configured juju and set cloud provider as LXC. > > As you mentioned, > *(i) 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)* > > > Whether i need to deploy in LXC? > i'm not sure what your asking. To deploy something you can either $ juju deploy mysql or if you want to edit the charm you can $ export JUJU_REPOSITORY=$PWD $ mkdir trusty $ cd trusty $ bzr branch lp:charms/trusty/mysql $ juju deploy local:trusty/mysql > Is there any references/tutorials available for deploying on specific > hypervisor?. > there are docs for various providers at http://juju.ubuntu.com/docs lxc is not technically a hypervisor, local provider supports either kvm or lxc. -k > > > > thanks and regards > Raj > > > > On Thu, Feb 26, 2015 at 9:33 AM, Kapil Thangavelu <[email protected]> > wrote: > >> >> >> On Wed, Feb 25, 2015 at 8:05 PM, Rajendar K <[email protected]> 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 <[email protected]> >>> 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 >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >>> >> >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
