Need Juju on cloudstack!
Hello, We have been following juju over the last few months @Orange with intense interest and would like to be able to use it. We just love the service approach that juju offers compared to other tools (we use Chef right now) Our problem is that we have a cloud based on CloudStack and we cannot use juju... What we would like is to be able to use the EC2 compatible API that CloudStack provides. Currently I don't think juju can be tweaked to choose another endpoint than AWS. I did open a bug report last may on the matter: (3rd hit if you google juju cloudstack) Bug #1182508 - juju cannot connect to cloudstack (non-ec2 ec2 cloud) Would it be possible to have an idea of when this bug/feature request might be implemented? I can understand that given the amount of work you have done this may seem irrelevant. Please excuse me if this is not the place to ask for this kind of question. Best regards Franck Dehay franck.de...@orange.commailto:franck.de...@orange-ftgroup.com _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Odd ec2 behavior - volumes attached to bootstrap node.
Is this expected? Notice one of my volumes is attached after the bootstrap
node comes up. The ec2-tools and aws dashboard show the same thing.
I've never seen this behavior before (I haven't looked that much), but I'm
having trouble finding anything other than the -b option to ec2-run-instances
that would expose anything like this.
dpb@helo:~$ euca-describe-volumes
VOLUME vol-d59280d71 us-west-2a available
2014-03-11T19:22:23.660Zstandard
TAG volume vol-d59280d7volume_name nfs/0 volume
VOLUME vol-0a3735049 us-west-2b available
2014-03-20T17:02:22.356Zstandard
TAG volume vol-0a373504volume_name postgresql/0 volume
dpb@helo:~$ juju bootstrap; juju status -v
verbose is deprecated with the current meaning, use show-log
2014-03-20 21:06:32 INFO juju.provider.ec2 ec2.go:193 opening environment
dpb-aws-us-west-2
2014-03-20 21:06:54 INFO juju.state open.go:68 opening state; mongo addresses:
[ec2-54-245-152-4.us-west-2.compute.amazonaws.com:37017]; entity
2014-03-20 21:10:04 INFO juju.state open.go:106 connection established
2014-03-20 21:10:04 INFO juju conn.go:66 juju: authorization error while
connecting to state server; retrying
2014-03-20 21:10:04 INFO juju.state open.go:68 opening state; mongo addresses:
[ec2-54-245-152-4.us-west-2.compute.amazonaws.com:37017]; entity
2014-03-20 21:10:05 INFO juju.state open.go:106 connection established
environment: dpb-aws-us-west-2
machines:
0:
agent-state: pending
dns-name: ec2-54-245-152-4.us-west-2.compute.amazonaws.com
instance-id: i-7bae4d73
instance-state: running
series: precise
hardware: arch=amd64 cpu-cores=1 cpu-power=100 mem=1740M root-disk=8192M
services: {}
2014-03-20 21:10:07 INFO juju supercommand.go:286 command finished
dpb@helo:~$ euca-describe-volumes
VOLUME vol-d59280d71 us-west-2a available
2014-03-11T19:22:23.660Zstandard
TAG volume vol-d59280d7volume_name nfs/0 volume
VOLUME vol-2a1cf92f8 snap-00d68df1 us-west-2a in-use
2014-03-20T21:06:35.358Zstandard
ATTACHMENT vol-2a1cf92fi-7bae4d73 /dev/sda1 attached
2014-03-20T21:06:35.000Z
VOLUME vol-0a3735049 us-west-2b available
2014-03-20T17:02:22.356Zstandard
TAG volume vol-0a373504volume_name postgresql/0 volume
--
David Britton david.brit...@canonical.com
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Help with arcitecture Part1
I would actually just use MaaS + LXC or KVM virtualization. You should be able to bring up a MaaS environment, and then do: juju deploy NEWSERVICE --to lxc:10 And Juju will create a new LXC container on machine 10 and deploy the NEWSERVICE into it. That gives you all the give me baremetal when I want it, and it gives you container separation as well. (You should also be able to do juju deploy foo --to kvm:12 for times when you have a Charm that needs direct device access.) John =:- On Thu, Mar 20, 2014 at 8:32 PM, Brian Wawok bwa...@gmail.com wrote: I was chatting with some awesome people in #juju, but having trouble deciding what to do. I was hoping that people with more juju experience could tell me the right way to go for what I want to do, or if juju is just a horrible idea in general and I should do something else. I have spent a few days playing Juju charms. They seem cool. I think I can use some of the existing juju charms in the store, and convert the rest of my custom apps to juju charms without a lot of work. The question is, how do I want to structure things in terms of manual vs openstack vs Here is what I have: Currently own all servers apps run on. Nothing in the cloud, basically want a virtual private cloud. Say 100 servers I want to deploy 300 apps to. Random facts about the setup: * 10 of these servers I want to run bare metal, i.e. 1 juju charm right on the server. * 90 of the servers I want to run a bunch of juju charms on them. * I am leaning towards LXC as a way to separate charms because it seems to work well, but it is also possible to just shove the apps right on the server. LXC would just make it a little cleaner by providing some environment separation, but it would not bury me under having to preallocate memory and such as I would with OpenVZ or such. * I always know exactly what I want to host where. So with the --to command, i will say where an app should run. I don't need any magic in that way. * I do not need any of the spin up more VMs when busy, spin down when slow type magic. Happy to just run the VMs I need for peak load. * I would like to buy a new server, plug it in, and have it available to deploy apps to with no manual work. So any ideas on ways to go? It seems like MAAS is good, it gets servers installed. Works well for my 10 apps that go right on metal. What about my other 290 apps? I could * Deploy multiple charms right to the server, forcing it with --to (seems easiest, but then I lose the nice separation LXC gives) * Deploy an openstack charm to the 90 VM hosts, and then use juju to deploy to it. That means I need 2 juju envionments (MAAS and openstack), and openstack seems way too complicated for what I need. Do not need 90 GUIs to manage, with 20 charm bundles. * Do manual provisioning, and set up the LXC myself. Which may not be too bad, but I have never done LXC by hand. And is there a downside to doing a manual provisioning environment on top of a MAAS server? Really, I just like how juju local works a lot. i want to expand that magic to both new hardware from scratch, and to installing to many VMs. Thoughts? -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Juju 1.17.6 is released.
juju-core 1.17.6 A new development release of Juju, juju-core 1.17.6, is now available. Getting Juju juju-core 1.17.6 is available for trusty and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/devel Upgrading from stable releases to development releases is not supported. You can upgrade test environments to development releases to test new features and fixes, but it is not advised to upgrade production environments to 1.17.6. If you are using a development release of juju-core, and find you need to go back to a stable release, you can find it in the juju stable PPA: https://launchpad.net/~juju/+archive/stable If you have multiple sources of juju-core, you can select the version you want using apt: sudo apt-get install juju-core=1.16.6* New and Notable * Juju now supports juju-mongodb, a mongodb tuned for juju’s needs * Juju now has support for proxies * Juju local provider can use clone for faster LXC Resolved issues * Juju uses tools for the wrong architecture when unable to find correct tools Lp 1227722 * Call to relation-get failing with 'permission denied' Lp 1239681 * Network interface br0 not brought up by cloud-init script with MAAS provider Lp 1271144 * Juju bootstrap --upload-tools does not honor the arch of the machine being created Lp 1282869 * Filesystem mount from lxc template causes filesystem permission breakages Lp 1293549 * Juju userdata should not restart networking Lp 1248283 * Juju deploy -n 15 gets rate limited in EC2 Lp 1277397 * Juju bootstrap does not select tools with respect to constraints Lp 1282870 * Juju 1.17.5 tries to execute non-existent hooks 1293310 Juju now supports juju-mongodb, a mongodb tuned for juju’s needs The Juju state-server (bootstrap node) prefers juju-mongodb and it will use it when it is available. The package is available in Ubuntu Trusty, the new db will be used when a Trusty environment is bootstrapped. The juju-local package on Trusty will include juju-mongodb when mongodb-server is not already installed. Upgrades of the juju-local package will continue to use mongodb-server to preserve continuity with existing local environments. Trusty users can install juju-mongodb to bootstrap new lxc and kvm environments with it. Juju now has support for proxies Proxies can now be configured for the providers in the environments.yaml file, or added to an existing environment using ‘juju set-env’ The configuration values are: http-proxy, https-proxy, ftp-proxy, no-proxy The values that are set for these proxies are exported in all hook execution contexts, and also available in the shell through ‘juju ssh’ or ‘juju run’. There are three additional proxy values specific for apt: apt-http-proxy, apt-https-proxy, apt-ftp-proxy These are set to be the same as the non-apt proxy values, but can be overridden independently. For example, having squid-deb-proxy running on a laptop, you can specify the apt-http-proxy to use it for the containers by doing: apt-http-proxy: http://10.0.3.1:8000 The IP address here is the address on the host machine’s network-bridge as seen from the machines on the bridge. Note: there is a known limitation here (bug 1295372), once you have set a value, there is no way to remove it. Juju local provider can use clone for faster LXC The local provider gains the ability to use lxc-clone to create the containers used as machines. This ability is controlled through a configuration value on the provider: lxc-clone This value defaults to ‘true’ for Trusty and above, and ‘false’ before that. You can try to use lxc-clone on earlier releases, but it is not a supported value. It may well work. The local provider is btrfs aware. If your LXC directory is on a btrfs filesystem, the clones use snapshots and are much faster to create and take up much less space. There is also support for using aufs as a backing-store for the LXC clones, but there are some situations where aufs doesn’t entirely behave as intuitively as one might expect, so this must be turned on explicitly. lxc-clone-aufs: true When using clone, the first machine to be created will create a ‘template’ machine that is used as the basis for the clones. This will be called ‘juju-series-template’, so for a precise image, the name is ‘juju-precise-template’. You should not modify or start this image while a local provider environment is running, as you cannot clone a running lxc machine. Some work is in progress, to be delivered as a plugin, that will provide additional functionality to create these template images independently of an environment, and helper functions to keep it up to date (i.e. running apt-get update/upgrade inside the container). Finally We encourage everyone to subscribe the mailing list at juju-...@lists.canonical.com, or join us on #juju-dev on freenode. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui
Re: Juju 1.17.6 is released.
Fantastic! Looks like streams.canonical.com is also nice and updated. John =:- On Fri, Mar 21, 2014 at 5:03 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: juju-core 1.17.6 A new development release of Juju, juju-core 1.17.6, is now available. Getting Juju juju-core 1.17.6 is available for trusty and backported to earlier series in the following PPA: https://launchpad.net/~juju/+archive/devel Upgrading from stable releases to development releases is not supported. You can upgrade test environments to development releases to test new features and fixes, but it is not advised to upgrade production environments to 1.17.6. If you are using a development release of juju-core, and find you need to go back to a stable release, you can find it in the juju stable PPA: https://launchpad.net/~juju/+archive/stable If you have multiple sources of juju-core, you can select the version you want using apt: sudo apt-get install juju-core=1.16.6* New and Notable * Juju now supports juju-mongodb, a mongodb tuned for juju’s needs * Juju now has support for proxies * Juju local provider can use clone for faster LXC Resolved issues * Juju uses tools for the wrong architecture when unable to find correct tools Lp 1227722 * Call to relation-get failing with 'permission denied' Lp 1239681 * Network interface br0 not brought up by cloud-init script with MAAS provider Lp 1271144 * Juju bootstrap --upload-tools does not honor the arch of the machine being created Lp 1282869 * Filesystem mount from lxc template causes filesystem permission breakages Lp 1293549 * Juju userdata should not restart networking Lp 1248283 * Juju deploy -n 15 gets rate limited in EC2 Lp 1277397 * Juju bootstrap does not select tools with respect to constraints Lp 1282870 * Juju 1.17.5 tries to execute non-existent hooks 1293310 Juju now supports juju-mongodb, a mongodb tuned for juju’s needs The Juju state-server (bootstrap node) prefers juju-mongodb and it will use it when it is available. The package is available in Ubuntu Trusty, the new db will be used when a Trusty environment is bootstrapped. The juju-local package on Trusty will include juju-mongodb when mongodb-server is not already installed. Upgrades of the juju-local package will continue to use mongodb-server to preserve continuity with existing local environments. Trusty users can install juju-mongodb to bootstrap new lxc and kvm environments with it. Juju now has support for proxies Proxies can now be configured for the providers in the environments.yaml file, or added to an existing environment using ‘juju set-env’ The configuration values are: http-proxy, https-proxy, ftp-proxy, no-proxy The values that are set for these proxies are exported in all hook execution contexts, and also available in the shell through ‘juju ssh’ or ‘juju run’. There are three additional proxy values specific for apt: apt-http-proxy, apt-https-proxy, apt-ftp-proxy These are set to be the same as the non-apt proxy values, but can be overridden independently. For example, having squid-deb-proxy running on a laptop, you can specify the apt-http-proxy to use it for the containers by doing: apt-http-proxy: http://10.0.3.1:8000 The IP address here is the address on the host machine’s network-bridge as seen from the machines on the bridge. Note: there is a known limitation here (bug 1295372), once you have set a value, there is no way to remove it. Juju local provider can use clone for faster LXC The local provider gains the ability to use lxc-clone to create the containers used as machines. This ability is controlled through a configuration value on the provider: lxc-clone This value defaults to ‘true’ for Trusty and above, and ‘false’ before that. You can try to use lxc-clone on earlier releases, but it is not a supported value. It may well work. The local provider is btrfs aware. If your LXC directory is on a btrfs filesystem, the clones use snapshots and are much faster to create and take up much less space. There is also support for using aufs as a backing-store for the LXC clones, but there are some situations where aufs doesn’t entirely behave as intuitively as one might expect, so this must be turned on explicitly. lxc-clone-aufs: true When using clone, the first machine to be created will create a ‘template’ machine that is used as the basis for the clones. This will be called ‘juju-series-template’, so for a precise image, the name is ‘juju-precise-template’. You should not modify or start this image while a local provider environment is running, as you cannot clone a running lxc machine. Some work is in progress, to be delivered as a plugin, that will provide additional functionality to create these template images independently of an environment, and helper functions to keep it up to date (i.e. running apt-get
