Re: please give a presentation to my user group
On Sat Dec 13 2014 at 17:52:32 sheila miguez she...@pobox.com wrote: Would any of the juju devs like to give a talk to my linux user group? Hi Sheila, I'd love to hop on the train and do a talk, ping me off-list and maybe we can sort something for January/Feb? -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [Calico] Project Calico and Juju Charms
For those of you looking for the bundle it is at: http://www.mail-archive.com/calico@lists.projectcalico.org/msg00081.html CoryB, Thanks to you and the Project Calico or sharing this solution, and your contribution to the Juju community. I saw the mail list stripped your bundle. You can also share your bundle in LP and have it ingested by the charm store. The process is documented at: https://jujucharms.com/docs/charms-bundles#creating-a-bundle -thanks, Antonio On Fri, Dec 12, 2014 at 12:38 PM, Kapil Thangavelu kapil.thangav...@canonical.com wrote: -- Forwarded message -- From: Cory Benfield cory.benfi...@metaswitch.com Date: Fri, Dec 12, 2014 at 4:26 AM Subject: [Calico] Project Calico and Juju Charms To: cal...@lists.projectcalico.org cal...@lists.projectcalico.org Hi everybody, I'm excited to announce that, after a fairly substantial amount of work, our first preview release of Juju Charms for Project Calico is available! Juju is a tool written by Canonical that makes it extremely easy to build and orchestrate complex services. One of its most powerful features is that it can combine with Metal-as-a-Service, another Canonical tool, to make it extremely simple to deploy OpenStack in a number of configurations. For the past couple of months we've been working on making it possible to build an OpenStack deployment using Juju that uses Calico to provide the OpenStack networking. Today marks the public availability of the first set of beta charms for doing just that. As of right now you can go online and get started with OpenStack Calico using Juju. It's never been easier! If you've already got a MAAS + Juju system up and running, you can get started right now. Attached to this email is the bundle we sent to the OpenStack Interoperability Lab. You should be able to drag and drop this bundle into your Juju GUI and immediately get OpenStack with Calico running. This particular bundle deploys OpenStack very densely, loading almost all the management services onto a single server, and using two more to act as compute nodes. If you want a more spread out deployment, feel free to edit the bundle: if you need assistance in doing that, please don't hesitate to ask for help on this list. If you're not familiar with Juju or MAAS and want to give them a try, you can find out more on the Juju website[0] and the MAAS website[1]. Both products are free and open source, and are absolutely worth checking out. The source code for the charms is available on Launchpad. The links are below[2-7]. In the next few weeks we aim to get our modifications to existing charms upstreamed into those existing charms. We also plan to add our custom charms to the charm store, though that will require a bit more work. The eventual goal is that you will be able to install OpenStack with Calico seamlessly with Juju, making it easier than ever to simplify and scale your OpenStack deployment. Keep watching this space! Cory (on behalf of the Project Calico team). [0]: https://jujucharms.com/ [1]: https://maas.ubuntu.com/ [2]: https://code.launchpad.net/~cory-benfield/charms/trusty/bird/trunk [3]: https://code.launchpad.net/~cory-benfield/charms/trusty/calico-acl-manager/trunk [4]: https://code.launchpad.net/~cory-benfield/charms/trusty/neutron-api/trunk [5]: https://code.launchpad.net/~cory-benfield/charms/trusty/nova-cloud-controller/trunk [6]: https://code.launchpad.net/~cory-benfield/charms/trusty/nova-compute/trunk [7]: https://code.launchpad.net/~cory-benfield/charms/trusty/neutron-calico/trunk ___ Calico mailing list cal...@lists.projectcalico.org http://lists.projectcalico.org/listinfo/calico -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Antonio Rosales Juju Ecosystem Canonical -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Juju chef cookbook
Hello! I was looking for chef cookbook, which can operate with juju using HWRP or LWRP. Maybe someone have it? Can't find anything on Github or at chef.io. Anyway, I want to deploy my server applications with chef, and some web applications with juju in LXC. So, I decided to write a cookbook that will install juju and use it with chef resources. So I can tell it what charms to install and expose. What do you think about this use case? Is it acceptable? Thanks! -- Best Regards, Egor http://aylium.net-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Fwd: juju min version feature
moving to juju-dev On Mon, Dec 15, 2014 at 9:50 AM, Horacio Duran horacio.du...@canonical.com wrote: Hello everybody, for those of you who don't know me, I am Horacio Duran, I am part of Moonstone team on juju-core. All of you have been signalled as stakeholders on juju's min version feature. Juju min version is intended to create charms that use newer features of juju without breaking older jujus. This is a basic first version of the spec containing the stories we believe define this feture. Feel free to add comments into the doc, email me or even say I dont want to be part of this or even if you feel anybody else should be here. Here is the link to the doc: https://docs.google.com/a/canonical.com/document/d/1vcpc1xLMdxvo_edMMlB2RS-h4I9eefkk5-a_Ey8ZoQE/edit# cheers. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: juju min version feature
Then we should take up the burden to help others realize that their code will work with older versions of juju. Perhaps I am assuming, but if I am a charm author and I am wondering what my minimum version of juju is I will select the one I am currently using. Running tests and older versions are not something I'm going to do want to take up the burden on. This means that users of juju will have a smaller set of charms available to them because of this declaration even though it may actually work. Rick On Dec 15, 2014 11:51 AM, Nate Finch nate.fi...@canonical.com wrote: OK, so, many people in juju-core have talked about this with Eco, and we came to the conclusion that per-feature flags would be way too confusing for the charm consumer. When I want to deploy a charm, I don't wnat to have to figure out what version of juju supports leader election so I can know if the charm I want is supported by my version of juju. I just want to see a min version and compare it to my version of juju. This does put a little more burden on charm authors, to do that translation themselves, but they would need to be able to do that anyway to understand what versions of juju support their charm. This way we at least take that burden off the person deploying the charm. Also, we very specifically only support min version. This just means we'll need to be backwards compatible. There won't be leader election 2.0 that makes 1.0 not work. On Mon, Dec 15, 2014 at 11:47 AM, Nate Finch nate.fi...@canonical.com wrote: last copy of context to juju-dev On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard adam.coll...@canonical.com wrote: On 15 December 2014 at 15:06, Marco Ceppi marco.ce...@canonical.com wrote: I'm against this idea, what if something changes in the implementation of leader_election? Now there's a requirement to track version of features released and complexity grows. Well if that were to happen, the charm author would have to know which version of Juju they need anyway? In fact the version based tracking of this makes it even worse, let's for the sake of argument assume that leader election 1.0 comes in Juju 1.22.0 and leader election 2.0 comes in Juju 1.24.0. If the charm is using the 1.0 model they have to say I require Juju = 1.22.0 and Juju 1.24.0. In the capability model they simply state I require a Juju capable of leader_election_2 (or some other better token that describes the change in a semantic way). I think the capabilities based model can easily extend into a provider based constraint as well. So the charm can say I require container addressing and MAAS Provider will be fine but everything else will fail as per the current spec. Using a capabilities model is more expressive and can be extended. Using version numbers is clunky. It seems much easier (testing and comprehension-wise) to have the author say Won't work unless you have this version of Juju or higher. This makes testing, linting, and other typical charm author actions simpler while yielding virtually the same result. I don't think manually mapping features to Juju versions is simple for anyone now, let alone the expanded base of charm authors that we're targetting. As for your use case of bugs in juju break user experience is an already existent risk and can be improved in other ways that I think are outside the scope of this. Agreed. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: juju min version feature
Ideally we will provide tools for the user to determine this, unless I understood wrongly the requirement. On Mon, Dec 15, 2014 at 1:55 PM, Rick Harding rick.hard...@canonical.com wrote: Then we should take up the burden to help others realize that their code will work with older versions of juju. Perhaps I am assuming, but if I am a charm author and I am wondering what my minimum version of juju is I will select the one I am currently using. Running tests and older versions are not something I'm going to do want to take up the burden on. This means that users of juju will have a smaller set of charms available to them because of this declaration even though it may actually work. Rick On Dec 15, 2014 11:51 AM, Nate Finch nate.fi...@canonical.com wrote: OK, so, many people in juju-core have talked about this with Eco, and we came to the conclusion that per-feature flags would be way too confusing for the charm consumer. When I want to deploy a charm, I don't wnat to have to figure out what version of juju supports leader election so I can know if the charm I want is supported by my version of juju. I just want to see a min version and compare it to my version of juju. This does put a little more burden on charm authors, to do that translation themselves, but they would need to be able to do that anyway to understand what versions of juju support their charm. This way we at least take that burden off the person deploying the charm. Also, we very specifically only support min version. This just means we'll need to be backwards compatible. There won't be leader election 2.0 that makes 1.0 not work. On Mon, Dec 15, 2014 at 11:47 AM, Nate Finch nate.fi...@canonical.com wrote: last copy of context to juju-dev On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard adam.coll...@canonical.com wrote: On 15 December 2014 at 15:06, Marco Ceppi marco.ce...@canonical.com wrote: I'm against this idea, what if something changes in the implementation of leader_election? Now there's a requirement to track version of features released and complexity grows. Well if that were to happen, the charm author would have to know which version of Juju they need anyway? In fact the version based tracking of this makes it even worse, let's for the sake of argument assume that leader election 1.0 comes in Juju 1.22.0 and leader election 2.0 comes in Juju 1.24.0. If the charm is using the 1.0 model they have to say I require Juju = 1.22.0 and Juju 1.24.0. In the capability model they simply state I require a Juju capable of leader_election_2 (or some other better token that describes the change in a semantic way). I think the capabilities based model can easily extend into a provider based constraint as well. So the charm can say I require container addressing and MAAS Provider will be fine but everything else will fail as per the current spec. Using a capabilities model is more expressive and can be extended. Using version numbers is clunky. It seems much easier (testing and comprehension-wise) to have the author say Won't work unless you have this version of Juju or higher. This makes testing, linting, and other typical charm author actions simpler while yielding virtually the same result. I don't think manually mapping features to Juju versions is simple for anyone now, let alone the expanded base of charm authors that we're targetting. As for your use case of bugs in juju break user experience is an already existent risk and can be improved in other ways that I think are outside the scope of this. Agreed. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: juju min version feature
Can't we just as easily provide tools to find out what version of Juju provides a particular feature? Certainly a CLI of: $ juju supported-features leader-election container-addressibility Or even possibly something that talks to something like the charm-store: $ juju known-features leader-election: juju = 2.2 container-addressibility: juju = 2.0 I'm personally on the side of having charm *authors* talk about the features they want. Because then in juju-world we can enable/disable specific features based on them being requested, which makes charm authors get the features they need right. (e.g., if the charm doesn't say it needs leader-election, then it doesn't get leader tools exposed.) min-version, otoh, leads to people just setting it to the thing they are using, and doesn't give Juju a way to smartly enable/disable functionality. It also suffers from when we want to drop a feature that didn't turn out quite like what we thought it would. John =:- On Mon, Dec 15, 2014 at 7:01 PM, Horacio Duran horacio.du...@canonical.com wrote: Ideally we will provide tools for the user to determine this, unless I understood wrongly the requirement. On Mon, Dec 15, 2014 at 1:55 PM, Rick Harding rick.hard...@canonical.com wrote: Then we should take up the burden to help others realize that their code will work with older versions of juju. Perhaps I am assuming, but if I am a charm author and I am wondering what my minimum version of juju is I will select the one I am currently using. Running tests and older versions are not something I'm going to do want to take up the burden on. This means that users of juju will have a smaller set of charms available to them because of this declaration even though it may actually work. Rick On Dec 15, 2014 11:51 AM, Nate Finch nate.fi...@canonical.com wrote: OK, so, many people in juju-core have talked about this with Eco, and we came to the conclusion that per-feature flags would be way too confusing for the charm consumer. When I want to deploy a charm, I don't wnat to have to figure out what version of juju supports leader election so I can know if the charm I want is supported by my version of juju. I just want to see a min version and compare it to my version of juju. This does put a little more burden on charm authors, to do that translation themselves, but they would need to be able to do that anyway to understand what versions of juju support their charm. This way we at least take that burden off the person deploying the charm. Also, we very specifically only support min version. This just means we'll need to be backwards compatible. There won't be leader election 2.0 that makes 1.0 not work. On Mon, Dec 15, 2014 at 11:47 AM, Nate Finch nate.fi...@canonical.com wrote: last copy of context to juju-dev On Mon, Dec 15, 2014 at 10:17 AM, Adam Collard adam.coll...@canonical.com wrote: On 15 December 2014 at 15:06, Marco Ceppi marco.ce...@canonical.com wrote: I'm against this idea, what if something changes in the implementation of leader_election? Now there's a requirement to track version of features released and complexity grows. Well if that were to happen, the charm author would have to know which version of Juju they need anyway? In fact the version based tracking of this makes it even worse, let's for the sake of argument assume that leader election 1.0 comes in Juju 1.22.0 and leader election 2.0 comes in Juju 1.24.0. If the charm is using the 1.0 model they have to say I require Juju = 1.22.0 and Juju 1.24.0. In the capability model they simply state I require a Juju capable of leader_election_2 (or some other better token that describes the change in a semantic way). I think the capabilities based model can easily extend into a provider based constraint as well. So the charm can say I require container addressing and MAAS Provider will be fine but everything else will fail as per the current spec. Using a capabilities model is more expressive and can be extended. Using version numbers is clunky. It seems much easier (testing and comprehension-wise) to have the author say Won't work unless you have this version of Juju or higher. This makes testing, linting, and other typical charm author actions simpler while yielding virtually the same result. I don't think manually mapping features to Juju versions is simple for anyone now, let alone the expanded base of charm authors that we're targetting. As for your use case of bugs in juju break user experience is an already existent risk and can be improved in other ways that I think are outside the scope of this. Agreed. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev --
Re: juju min version feature
On 16 December 2014 at 00:13, John Meinel j...@arbash-meinel.com wrote: Can't we just as easily provide tools to find out what version of Juju provides a particular feature? Certainly a CLI of: $ juju supported-features leader-election container-addressibility Or even possibly something that talks to something like the charm-store: $ juju known-features leader-election: juju = 2.2 container-addressibility: juju = 2.0 I'm personally on the side of having charm *authors* talk about the features they want. Because then in juju-world we can enable/disable specific features based on them being requested, which makes charm authors get the features they need right. (e.g., if the charm doesn't say it needs leader-election, then it doesn't get leader tools exposed.) min-version, otoh, leads to people just setting it to the thing they are using, and doesn't give Juju a way to smartly enable/disable functionality. It also suffers from when we want to drop a feature that didn't turn out quite like what we thought it would. On the flip side, I could state that I am developing my charm for juju 1.20 and not care what features I'm using. If someone deploys my charm with juju 2.1, then juju could do so by deploying the charm in a 1.20 compatible environment. Juju devs can forge ahead and make backwards incompatible changes to hook tools and the meanings of environment variables by providing a compatibility layer. I do think it is useful to encode the required juju version in the charm. We also need versioning on interfaces (charms need to make backwards incompatible changes to interfaces), and better support for multiple charm series (1.0, 1.1, 2.0 vs 'trusty', 'precise'), but that is all future spec work. I think we need the required juju version even if we also allow people to specify features. swift-storage could specify that it needs 'the version of juju that configures lxc to allow loopback mounts', which is a bug fix rather than a feature. Providing a feature flag for every bug fix that a charm may depend on is impractical. -- Stuart Bishop stuart.bis...@canonical.com -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
