Re: Mongo DB on the Juju controller
Hey Giu, the juju wiki on GitHub has some details on how to login into mongodb. https://github.com/juju/juju/wiki/Login-into-MongoDB Cheers -- Sandor Zeestraten On Tue, Jun 12, 2018, 19:18 Giu Platania wrote: > All, > > We are trying to access the MongoDB instance within the juju controller. > > What is the admin password for it? > > The standard Ubuntu Sudo user is not working > > Thanks > > -- > > > Giu Platania > TOGAF certified Enterprise Architect > email: giu.plata...@cloudgensys.com > Cell: +1 902 748 0992 > Profile: http://www.linkedin.com/profile/view?id=119360308 > > > -- > 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
Blog post about expanding Ceph clusters with Juju
Hey Juju folks, I wrote up a short blog post about expanding Ceph clusters with Juju in case anyone is interested and looking to do the same. https://zeestrataca.com/posts/expanding-ceph-clusters-with-juju/ Cheers -- Sandor Zeestraten -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
LXD and constraints
Hey folks, I'd like continue a discussion about LXD containers and constraints from last year ( https://lists.ubuntu.com/archives/juju-dev/2017-January/006269.html). The use case of limiting/capping the resources (such as cores and memory) of LXD containers deployed by Juju is still not covered today. Now, I understand that using regular constraints would conflict with the current Juju concept of constraints meaning the minimums. However, I'd really like to get some more eyes on how to extend the current constraints or create a new syntax. Managing resources is rather essential when colocating different services with different footprints on hosts. https://bugs.launchpad.net/juju/+bug/1582105 Cheers -- Sandor Zeestraten -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: More juju upgrade-juju failings
Glad to help. I reported http://pad.lv/1761288 regarding the ability to abort/rollback broken upgrades in order to get out of sticky upgrade situations. Also hope to see a clean up of the UX and the addition of actual dry-run capabilities in http://pad.lv/1638714 We're looking forward to upgrading from 2.3 to 2.4 with ease and confidence! Regards -- Sandor Zeestraten On Wed, Apr 4, 2018 at 8:13 PM, Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > Sandor, thanks for this perspective! It was really helpful to see how > upgrades went for you in real life, and more importantly, that 2.3.x seems > to have gone smoothly. We'll be carefully watching and monitoring 2.3->2.4 > upgrades as the release draws nearer. > > Nicholas > > On 04/01/2018 04:04 AM, Sandor Zeestraten wrote: > >> Hi Nicholas, >> >> Thanks for the input. I wrote up a short blog post about our experiences >> going from 2.1 to 2.3. Hopefully it provides some feedback and can be >> helpful for others in the same position. >> >> http://zeestrataca.com/posts/upgrading-juju/ < >> http://zeestrataca.com/posts/upgrading-juju/> >> >> Regards >> -- >> Sandor Zeestraten >> >> >> On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs < >> nicholas.ska...@canonical.com <mailto:nicholas.ska...@canonical.com>> >> wrote: >> >> Sandor, re:sharing experiences, if you want to frame some >> scenarios you've had trouble with, please feel free to share >> those. Distilling it down into a repeatable deployment -> upgrade >> will help us understand and account for it. As Tim mentioned, >> tools like juju-upgrader are generally candidates for >> incorporation into juju itself, provided they prove valuable to >> the community at large. We always welcome any PR's, but especially >> so for improvements that add this functionality. >> >> Nicholas >> >> On 03/21/2018 08:43 PM, Tim Penhey wrote: >> >> Hi Sandor, >> >> Streamlining upgrades is definitely on the team's road-map. We >> are aware >> of the juju-upgrader plugin, and will be looking to >> incorporate some of >> that functionality into the core codebase. >> >> The core team has worked on better upgrade testing as part of >> our CI, >> which enables more test scenarios to help discover issues >> between more >> versions. >> >> Cheers, >> Tim >> >> On 22/03/18 05:32, Sandor Zeestraten wrote: >> >> Is this shared google doc open for external contributors? >> >> After spending a while upgrading our 2.1.x environments to >> 2.3.x and >> hitting some bugs along the way in staging (see below), >> I'd agree that >> the process needs a bit of love and wouldn't mind sharing >> some experiences. >> >> Rick mentioned https://launchpad.net/juju-upgrader >> <https://launchpad.net/juju-upgrader> on the Juju show a >> couple of episodes back, but I haven't seen it mentioned >> anywhere else >> yet. Are those tools supposed to deal with some of these >> issues and >> eventually be rolled into juju-core? >> >> https://bugs.launchpad.net/juju/+bug/1746265 >> <https://bugs.launchpad.net/juju/+bug/1746265> >> https://bugs.launchpad.net/juju/+bug/1748294 >> <https://bugs.launchpad.net/juju/+bug/1748294> >> https://bugs.launchpad.net/juju/+bug/1697936 >> <https://bugs.launchpad.net/juju/+bug/1697936> >> >> Regards >> -- >> Sandor Zeestraten >> >> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth >> mailto:m...@ubuntu.com> >> <mailto:m...@ubuntu.com <mailto:m...@ubuntu.com>>> wrote: >> >> >> I think this UX on the upgrade process has obvious >> problems. Nobody >> should have to guess at what to do, in which sequence. >> >> Can I suggest that we have a shared Google doc to >> mock up a nice >> experience starting with the simple command 'juju >> upgrade' which then >>
Re: More juju upgrade-juju failings
Hi Nicholas, Thanks for the input. I wrote up a short blog post about our experiences going from 2.1 to 2.3. Hopefully it provides some feedback and can be helpful for others in the same position. http://zeestrataca.com/posts/upgrading-juju/ Regards -- Sandor Zeestraten On Thu, Mar 22, 2018 at 4:39 PM, Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > Sandor, re:sharing experiences, if you want to frame some scenarios you've > had trouble with, please feel free to share those. Distilling it down into > a repeatable deployment -> upgrade will help us understand and account for > it. As Tim mentioned, tools like juju-upgrader are generally candidates for > incorporation into juju itself, provided they prove valuable to the > community at large. We always welcome any PR's, but especially so for > improvements that add this functionality. > > Nicholas > > On 03/21/2018 08:43 PM, Tim Penhey wrote: > >> Hi Sandor, >> >> Streamlining upgrades is definitely on the team's road-map. We are aware >> of the juju-upgrader plugin, and will be looking to incorporate some of >> that functionality into the core codebase. >> >> The core team has worked on better upgrade testing as part of our CI, >> which enables more test scenarios to help discover issues between more >> versions. >> >> Cheers, >> Tim >> >> On 22/03/18 05:32, Sandor Zeestraten wrote: >> >>> Is this shared google doc open for external contributors? >>> >>> After spending a while upgrading our 2.1.x environments to 2.3.x and >>> hitting some bugs along the way in staging (see below), I'd agree that >>> the process needs a bit of love and wouldn't mind sharing some >>> experiences. >>> >>> Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a >>> couple of episodes back, but I haven't seen it mentioned anywhere else >>> yet. Are those tools supposed to deal with some of these issues and >>> eventually be rolled into juju-core? >>> >>> https://bugs.launchpad.net/juju/+bug/1746265 >>> https://bugs.launchpad.net/juju/+bug/1748294 >>> https://bugs.launchpad.net/juju/+bug/1697936 >>> >>> Regards >>> -- >>> Sandor Zeestraten >>> >>> On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth >> <mailto:m...@ubuntu.com>> wrote: >>> >>> >>> I think this UX on the upgrade process has obvious problems. Nobody >>> should have to guess at what to do, in which sequence. >>> >>> Can I suggest that we have a shared Google doc to mock up a nice >>> experience starting with the simple command 'juju upgrade' which >>> then >>> walks people through the process, including the distinction between >>> upgrading charms, agents and controllers, as well as the ability to >>> do >>> aerospace-grade upgrades through live migration to newer >>> controllers? >>> >>> Mark >>> >>> On 02/27/2018 11:26 PM, Tim Penhey wrote: >>> > Hi Daniel, >>> > >>> > The issue here is that you are upgrading the default model, not >>> the >>> > controller model itself. >>> > >>> > I think we could make the error messaging more clear, and also >>> have the >>> > command also check the controller version before showing a lot of >>> > baffling output. >>> > >>> > What you need to do is upgrade the controller model first, so >>> either >>> > switch to it or run: >>> > >>> > juju upgrade-juju -m controller --agent-version 2.3.3 >>> > >>> > Cheers, >>> > Tim >>> > >>> > On 28/02/18 11:19, Daniel Bidwell wrote: >>> >> I am running on juju 2.3.3-xenial-amd64 and my controllers are >>> running >>> >> in VMware Vsphere with version 2.3.2. I thought that it would >>> be a >>> >> good thing for me to upgrade the controllers. >>> >> >>> >> I have a controller, "juju switch" generates: >>> >> bannercontroller:admin/default >>> >> >>> >> and juju status generates: >>> >> ModelControllerCloud/Region Version >>> SLA >>> >> default bann
Re: More juju upgrade-juju failings
Is this shared google doc open for external contributors?
After spending a while upgrading our 2.1.x environments to 2.3.x and
hitting some bugs along the way in staging (see below), I'd agree that the
process needs a bit of love and wouldn't mind sharing some experiences.
Rick mentioned https://launchpad.net/juju-upgrader on the Juju show a
couple of episodes back, but I haven't seen it mentioned anywhere else yet.
Are those tools supposed to deal with some of these issues and eventually
be rolled into juju-core?
https://bugs.launchpad.net/juju/+bug/1746265
https://bugs.launchpad.net/juju/+bug/1748294
https://bugs.launchpad.net/juju/+bug/1697936
Regards
--
Sandor Zeestraten
On Wed, Feb 28, 2018 at 8:30 AM, Mark Shuttleworth wrote:
>
> I think this UX on the upgrade process has obvious problems. Nobody
> should have to guess at what to do, in which sequence.
>
> Can I suggest that we have a shared Google doc to mock up a nice
> experience starting with the simple command 'juju upgrade' which then
> walks people through the process, including the distinction between
> upgrading charms, agents and controllers, as well as the ability to do
> aerospace-grade upgrades through live migration to newer controllers?
>
> Mark
>
> On 02/27/2018 11:26 PM, Tim Penhey wrote:
> > Hi Daniel,
> >
> > The issue here is that you are upgrading the default model, not the
> > controller model itself.
> >
> > I think we could make the error messaging more clear, and also have the
> > command also check the controller version before showing a lot of
> > baffling output.
> >
> > What you need to do is upgrade the controller model first, so either
> > switch to it or run:
> >
> > juju upgrade-juju -m controller --agent-version 2.3.3
> >
> > Cheers,
> > Tim
> >
> > On 28/02/18 11:19, Daniel Bidwell wrote:
> >> I am running on juju 2.3.3-xenial-amd64 and my controllers are running
> >> in VMware Vsphere with version 2.3.2. I thought that it would be a
> >> good thing for me to upgrade the controllers.
> >>
> >> I have a controller, "juju switch" generates:
> >> bannercontroller:admin/default
> >>
> >> and juju status generates:
> >> ModelControllerCloud/Region Version SLA
> >> default bannercontroller myvscloud/New Datacenter 2.3.2
> unsupported
> >>
> >> App Version Status Scale Charm Store Rev OS Notes
> >>
> >> Unit Workload Agent Machine Public address Ports Message
> >>
> >> Machine State DNS Inst id Series AZ Message
> >>
> >> doing "juju upgrade-juju --agent-version 2.3.3 --debug" generates:
> >>
> >> 17:16:19 INFO juju.cmd supercommand.go:56 running juju [2.3.3 gc
> go1.9.2]
> >> 17:16:19 DEBUG juju.cmd supercommand.go:57 args:
> []string{"/snap/juju/3452/bin/juju", "upgrade-juju", "--agent-version",
> "2.3.3", "--debug"}
> >> 17:16:19 INFO juju.juju api.go:67 connecting to API addresses: [
> 10.1.61.239:17070]
> >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed "wss://
> 10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> >> 17:16:19 INFO juju.api apiclient.go:597 connection established to
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> >> 17:16:19 INFO juju.juju api.go:67 connecting to API addresses: [
> 10.1.61.239:17070]
> >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed "wss://
> 10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> >> 17:16:19 INFO juju.api apiclient.go:597 connection established to
> "wss://10.1.61.239:17070/model/5a057215-e835-42fb-8c5a-f9d57eded74c/api"
> >> 17:16:19 INFO juju.juju api.go:67 connecting to API addresses: [
> 10.1.61.239:17070]
> >> 17:16:19 DEBUG juju.api apiclient.go:843 successfully dialed "wss://
> 10.1.61.239:17070/api"
> >> 17:16:19 INFO juju.api apiclient.go:597 connection established to
> "wss://10.1.61.239:17070/api"
> >> 17:16:19 DEBUG juju.cmd.juju.commands upgradejuju.go:466 searching for
> agent binaries with major: 2
> >> 17:16:22 INFO cmd upgradejuju.go:363 available agent binaries:
> >> 2.3.3-artful-amd64
> >> 2.3.3-artful-arm64
> >> 2.3.3-artful-ppc64el
> >> 2.3.3-artful-s390x
> >> 2.3.3-bionic-amd64
> >> 2.3.3-bionic-arm64
> >> 2.3.3-bionic-ppc64el
> >> 2.3.3-bionic-s390x
> >>
Re: Juju Charm Store and CI
On Wed, Feb 28, 2018 at 8:51 AM, Mark Shuttleworth wrote:
> On 02/27/2018 10:44 PM, Sandor Zeestraten wrote:
>
> I feel like I'm hitting some rough spots while setting up a simple
> pipeline which pushes a charm build to the edge channel using the charm
> store CLI.
> The last Juju Show (#30) talked about macaroon support in libjuju and CI
> which sounds great, but that seems to be aimed at those using libjuju
> and/or JAAS controllers.
>
>
> The charm store should definitely use macaroons, and should have a
> language to be able to setup limited-use macaroons ('token to push for this
> charm', 'token to release to edge channel for this charm' etc).
>
> Can I suggest a hangout between folks interested in this, and the charm
> store folks, to work out whats needed?
>
> Mark
>
>
Hey Mark, happy to join a hangout if needed. I'm mainly CET, but can do NA
time zones with some planning.
Thanks
--
Sandor Zeestraten
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Juju Charm Store and CI
Hey Tom. Yes, I saw your hack in https://lists.ubuntu.com/archives/juju/2017-November/009691.html which was handy, however I was hoping for something less hacky from the charm store folks. -- Sandor Zeestraten On Feb 27, 2018 22:54, "Tom Barber" wrote: I have a proper hack for a circleci build chain I wrote, but works pretty well: https://github.com/spiculedata/circleci-juju On 27/02/18 21:44, Sandor Zeestraten wrote: Hey Juju folks, I feel like I'm hitting some rough spots while setting up a simple pipeline which pushes a charm build to the edge channel using the charm store CLI. The last Juju Show (#30) talked about macaroon support in libjuju and CI which sounds great, but that seems to be aimed at those using libjuju and/or JAAS controllers. Here are some of the steps for a new project: * Create a launchpad team for a namespace in the charm store - Fair enough * Create a launchpad CI user/bot and add it project so we can push to the store without using personal credentials - This feels like a hack and rather insecure. Why not use limited deploy/API keys? https://github.com/juju/charmstore/issues/776 * Manually login to launchpad with the CI user in order to activate it in the charm store - This gotcha took me a few moments to figure out. https://jujucharms.com/docs/stable/authors-charm-store#the-juju-charm-store * Manually login to the charm store with the CI user with `charm login` to create a token. - Had to find this bug, https://github.com/juju/c harmstore-client/issues/61, after I figured out that `charm login` did not have a non-interactive way to authenticate - This is still not document anywhere as far as I can tell. https://github.com/juju/charmstore-client/issues/145 - According to the comments in #61 it needs to be updated periodically - I've seen another approach using expect, https://lists.ubuntu.c om/archives/juju/2017-November/009691.html, but that seems like a workaround too * Encrypt and deploy token to a specific directory in CI in order for `charm login` to work - Again, https://github.com/juju/charmstore-client/issues/61 and https://github.com/juju/charmstore-client/issues/145 * Mess around with `charm push` and `charm release` in order to push charm to the edge channel - This involves dealing with revisions which feels rather unnecessary - See https://github.com/juju/charmstore-client/issues/135 and https://github.com/juju/charmstore-client/issues/146 * Celebrate with your favourite beverage How are you all interacting with the charm store with your charm CI? Am I missing some obvious steps which would simplify things? Is anyone working on proper deploy/API keys for the charm store? Cheers -- Sandor Zeestraten Spicule Limited is registered in England & Wales. Company Number: 09954122. Registered office: First Floor, Telecom House, 125-135 Preston Road, Brighton, England, BN1 6AF. VAT No. 251478891. All engagements are subject to Spicule Terms and Conditions of Business. This email and its contents are intended solely for the individual to whom it is addressed and may contain information that is confidential, privileged or otherwise protected from disclosure, distributing or copying. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Spicule Limited. The company accepts no liability for any damage caused by any virus transmitted by this email. If you have received this message in error, please notify us immediately by reply email before deleting it from your system. Service of legal notice cannot be effected on Spicule Limited by email. -- 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 Charm Store and CI
Hey Juju folks, I feel like I'm hitting some rough spots while setting up a simple pipeline which pushes a charm build to the edge channel using the charm store CLI. The last Juju Show (#30) talked about macaroon support in libjuju and CI which sounds great, but that seems to be aimed at those using libjuju and/or JAAS controllers. Here are some of the steps for a new project: * Create a launchpad team for a namespace in the charm store - Fair enough * Create a launchpad CI user/bot and add it project so we can push to the store without using personal credentials - This feels like a hack and rather insecure. Why not use limited deploy/API keys? https://github.com/juju/charmstore/issues/776 * Manually login to launchpad with the CI user in order to activate it in the charm store - This gotcha took me a few moments to figure out. https://jujucharms.com/docs/stable/authors-charm-store#the-juju-charm-store * Manually login to the charm store with the CI user with `charm login` to create a token. - Had to find this bug, https://github.com/juju/c harmstore-client/issues/61, after I figured out that `charm login` did not have a non-interactive way to authenticate - This is still not document anywhere as far as I can tell. https://github.com/juju/charmstore-client/issues/145 - According to the comments in #61 it needs to be updated periodically - I've seen another approach using expect, https://lists.ubuntu.c om/archives/juju/2017-November/009691.html, but that seems like a workaround too * Encrypt and deploy token to a specific directory in CI in order for `charm login` to work - Again, https://github.com/juju/charmstore-client/issues/61 and https://github.com/juju/charmstore-client/issues/145 * Mess around with `charm push` and `charm release` in order to push charm to the edge channel - This involves dealing with revisions which feels rather unnecessary - See https://github.com/juju/charmstore-client/issues/135 and https://github.com/juju/charmstore-client/issues/146 * Celebrate with your favourite beverage How are you all interacting with the charm store with your charm CI? Am I missing some obvious steps which would simplify things? Is anyone working on proper deploy/API keys for the charm store? Cheers -- Sandor Zeestraten -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Charm Tools distribution channels and versions
Hey folks, I'm having a bit of a hard time figuring out which distribution of charm-tools I can/should use and how they are versioned in order to keep track of bugfixes. As far as I understand, the snaps are preferred over the packages in the Juju PPA and PyPI falls somewhere in between? The snap channels all refer to 2.2 which makes it a bit difficult to tell which are which (see below), yet they all display charm 2.2.2 and charm-tools 2.1.2 when running "charm version". I'm sure I'm missing something obvious but how do I keep track of what is in each snap build? Finally, we're using bundletester for running tests which pulls inn charm-tools from PyPI which seems to have 2.2.0 as the latest version. Does PyPI still get new charm-tools releases? If not, what's the recommended workflow for those running bundletester? P.S. The page on PyPI still refers to installing charm-tools from the Juju PPA which probably should be fixed. $ snap info charm name: charm summary: "charm and charm-tools" publisher: charms contact: juju@lists.ubuntu.com description: | charmstore-client and charm-tools snap-id: 2Rryoc2ylScfbFl4eQtpntHD9iuZuMvt commands: - charm tracking:stable installed: 2.2 (17) 102MB - refreshed: 2017-07-31 18:40:23 + UTC channels: stable:2.2 (17) 102MB - candidate: 2.2 (23) 102MB - beta: ↑ edge: 2.2 (37) 102MB - Regards -- Sandor Zeestraten -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Future of the Charm Review Queue
If the community curation approach is the way forward then the charm store will need some improvements to allow for rating (perhaps also feedback) and sorting charms, especially when searching. Here are some examples on how other config management tools do it: https://galaxy.ansible.com/explore#/ https://supermarket.chef.io/cookbooks https://forge.puppet.com/ -- Sandor Zeestraten On Aug 7, 2017 6:27 PM, "Tim Van Steenburgh" < tim.van.steenbu...@canonical.com> wrote: Not that I'm aware of, but it can't hurt to open a github issue for that idea. On Fri, Aug 4, 2017 at 2:40 PM, Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Are there any plans to let users assess the "quality" of a charm in a > different way? Like showing the amount of (successful) deploys or smth? > > On Aug 4, 2017 16:21, "Tim Van Steenburgh" com> wrote: > >> Hi All, >> >> I wanted to send a note about some changes in the way we handle charm >> reviews and the top-level namespace of the charm store. We’ve taken a look >> at what’s happened in the past and where we want to get to and decided that >> a much more lightweight process is the way forward. >> >> The biggest change is actually the sunsetting of the charm review queue. >> The reality is the process as it stands cannot keep up with the demand for >> reviews. We’ve decided to take a community curation approach. >> >> A charm review is no longer a prerequisite for promulgation to the >> top-level namespace of the charm store. If you would like your charm >> promulgated, and the name is available, you may simply request promulgation >> on this mailing list. A member of the ~charmers Launchpad group will then: >> >> >>1. >> >>Download your charm using `charm pull` >>2. >> >>Run `charm proof` on your charm >>3. >> >>Ensure you have `charm set` a bugs-url and homepage >>4. >> >>If 2 or 3 fails, the charmer will request an update to the charm >>5. >> >>`charm promulgate` the charm (or request that #2-3 be fixed) >>6. >> >>`charm grant` you write access on the promulgated charm >> >> >> Some things to keep in mind as a charm author: >> >> >>1. >> >>It is your responsibility as the charm author and maintainer to test >>your charm and ensure its quality and security. >>2. >> >>Promulgation to the top level does not imply endorsement by Canonical. >>3. >> >>Charm authors are encouraged to use their personal or group >>namespace. Although promulgation is still available, there is nothing >> wrong >>with using personal and group namespaces. >> >> >> For those seeking assistance with charm development, members of ~charmers >> and other proficient charm developers are available in #juju on Freenode >> IRC and on this mailing list. Discontinuing the formal charm review process >> does not in any way decrease the availability of or access to these >> resources. If you need help, just ask! >> >> In the coming weeks, the docs at jujucharms.com will be updated to >> reflect these changes. The review queue (review.jujucharms.com) will be >> shut down, and all open reviews will be closed with a comment/email linking >> to this explanatory post. Anyone with an open review that still desires >> promulgation can request it with an email to this list. >> >> If you have any questions or concerns, please reply to this post! >> >> Thanks, >> >> Tim Van Steenburgh >> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> >> -- 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
Clarifying the concept of bindings in charms
Hi all, The new network requirements in Juju 2.1.x where operators must explicitly specifying which bindings to use are confusing me a bit. Just to clarify, where do I find which bindings/endpoints are available for each charm? The charm store does not seem to display these without looking in the metadata.yaml file. I've created https://github.com/CanonicalLtd/jujucharms.com/issues/402 to track this. The metadata page has a section ( https://jujucharms.com/docs/stable/authors-charm-metadata#extra-bindings) on extra-bindings which I thought was supposed to specify the bindings that are available. However I've also seen some references to using the fields in the provider section of the metadata file. What am I missing? Is one preferred over the other? -- Sandor Zeestraten -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: juju 2.0.2 picking a random ip address from maas
Where do we find which bindings a charm has so they can be specified directly? According to the docs on the metadata ( https://jujucharms.com/docs/stable/authors-charm-metadata) there's a section called extra-bindings but that only seems to be used in some charms. -- Sandor Zeestraten On Thu, Mar 9, 2017 at 2:34 PM, John Meinel wrote: > In the meantime, you can work around it by specifying the bindings > directly: so in the case of mysql that would be: > juju deploy mysql --bind "db=db-space monitors=db-space ha=db-space ..." > > John > =:-> > > > On Thu, Mar 9, 2017 at 7:25 AM, John Meinel > wrote: > >> "juju deploy mysql --bind db-space" is exactly the syntax that should be >> working, and I'm seeing it failing now. I will work to fix that and make >> sure we don't regress here. We certainly should have caught that before >> release. >> >> John >> =:-> >> >> >> On Thu, Mar 9, 2017 at 1:47 AM, Patrizio Bassi >> wrote: >> >>> Hi Ante, >>> >>> no that is not working, but i think it's by design. >>> That constraint means: pick up a machine that has a leg in the db-space >>> leg. >>> >>> So my machine with 2 eth ports in two different spaces satisfy that >>> constraint, >>> it is picked, but the IP is wrong. >>> >>> Another option i tried is: >>> >>> juju deploy mysql --constraints spaces=db-space,^space_i_dont_want >>> >>> in that case the machine is filtered out, because, as i said before, it >>> means "a machine that is in db-space space but not in space_i_dont_want >>> space". >>> >>> i just want it to pick the right ip! >>> >>> I checked the json coming from maas: it seems sorting ipv4 addresses >>> from "smallest" to biggest and juju just picks the first one. in juju >>> status i continue to see "dns-name" set to the wrong ip address, which >>> doesn't resolve too. >>> >>> even using --to fqdn it doesn't get the right ip >>> >>> So i think there are two bugs: >>> 1) juju deploy --bind cannot find space name reporting "empty names" >>> error msg >>> 2) juju doesn't try to resolve ips/hostname to check what's the machine >>> name >>> >>> can you reproduce it? >>> >>> Patrizio >>> >>> >>> 2017-03-09 8:39 GMT+01:00 Ante Karamatić : >>> >>>> Hi Patrizio, >>>> >>>> this is exactly what I saw yesterday too, unrelated to this thread. >>>> What you could do is: >>>> >>>> juju deploy mysql --constraints spaces=db-space >>>> >>>> Let me know if the constraints workaround works for you. >>>> >>>> On Thu, Mar 9, 2017 at 8:28 AM Patrizio Bassi >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> i simply would like to do what's written in >>>>> https://jujucharms.com/docs/2.1/charms-deploying >>>>> >>>>> "When deploying an application to a target with multiple spaces, the >>>>> operator must specify which space to use because ambiguous bindings will >>>>> result in a provisioning failure." >>>>> >>>>> This is exactly my case: a machine with 2 eth ports, two different >>>>> subnets in two different spaces. >>>>> >>>>> the doc says i may do (c/p): $ juju deploy mysql --bind db-space >>>>> >>>>> and so bind a maas space for all the application. Unfortunately it >>>>> seems not working (i get the "empty names" error). >>>>> >>>>> Patrizio >>>>> >>>>> 2017-03-08 20:40 GMT+01:00 John Meinel : >>>>> >>>>> So without bindings, I would expect the behavior, the question is why >>>>> you would be seeing: >>>>> "cannot run instances: cannot run instance: interface bindings >>>>> cannot have empty names" >>>>> >>>>> Can you open a bug on https://bugs.launchpad.net/juju/+filebug and >>>>> include some more information like the logs from the controller machine? >>>>> >>>>> I'm not quite sure I understand what you mean by "my binding should be >>>>> global for a local bundle charm". >>>>> >>>>&g
Nagios charm maintenance
Hey Juju folks, We've been running into some issues (especially http://pad.lv/1605733) when using the promulgated Nagios charm for various deployments and would like to contribute back some fixes. The bug tracker for the charm/nagios-charmers seems pretty dead so I was wondering if anybody knew the status of the Nagios charm and if/who is maintaining it? P.S. Even the Canonical Bootstack Squad seems to have hit by the bug mentioned above (http://lists.openstack.org/pipermail/openstack-dev/2017- January/110567.html) Thanks -- Sandor Zeestraten -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Immutable configuration best practices for charms
Hey folks, How are you all dealing with immutable configurations when charming? I know that the best practices[1] say that charm configurations should not be immutable, however not all applications are created equally (see for example [2]). Anyone have any thoughts or ideas on how to deal with these issues where you have to lock down something when deploying? [1] https://jujucharms.com/docs/2.0/authors-charm-best-practice#juju-best-practices-and-tips-from-canonical's-infrastructure-team [2] https://bugs.launchpad.net/charms/+source/nova-compute/+bug/1623679 Thanks, Sandor -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Complex store queries
To go back to the original request from Ondřej and Merlijn, I would also like to see something a bit more queryable than just http://interfaces.juju.solutions/ Can we put in a bug/request somewhere so it can be tracked? -- Sandor Zeestraten On Tue, Oct 25, 2016 at 11:26 PM, Marco Ceppi wrote: > It sounds like you really want to add landscape client to each ;) > > On Tue, Oct 25, 2016, 10:21 PM Casey Marshall < > casey.marsh...@canonical.com> wrote: > >> On Mon, Oct 24, 2016 at 6:15 AM, Merlijn Sebrechts < >> merlijn.sebrec...@gmail.com> wrote: >> >> +1 for "which charms use this layer" queries. This has a number of uses: >> >> - for finding what the quality of a layer is (more use in recommended >> charms = better quality) >> - for the maintainer of a layer so he can see what the impact is of a >> change on his layer >> - to see which charms have to be rebuilt if a vulnerability has been >> found in a layer >> >> >> Related to that last use case, it's also possible that a security update >> needs to be applied based on the software that gets installed by the layer. >> >> Today I noticed a security update for nginx: https://www.ubuntu.com/usn/ >> usn-3114-1/ >> >> This affects all deployed applications that were built with layer:nginx. >> You'll definitely want to `juju run "apt-get update && apt-get upgrade -y >> nginx"` on those. >> >> >> >> 2016-10-18 16:55 GMT+02:00 Ondřej Kuzník : >> >> Hi, >> developing new charms or just exploring the store, one might want to >> raise random queries like "which charms use a layer x", "which charms >> are subordinate" and some others. Are there any plans to add those, >> concerns why this might not be a good idea? >> >> While the store could extend the API to include these, I presume it >> would just be an addition to a hardcoded list. Another option would be >> for someone to scrape the store to PostgreSQL or a document DB of some >> sort that could be searched with rather arbitrary queries (and a few >> indexes for the more common ones). >> >> My first reaction is that such a scraper would be frowned upon as it >> might not have a way to update its database intelligently and keep >> hitting all sorts of rate limits imposed by the store, but I might be >> wrong here. >> >> Any thoughts on this? >> >> Thanks, >> Ondrej >> >> -- >> Consultant >> >> credativ Ltd >> Open Source for Business >> UK office: +44 1788 298150 >> Email: ondrej.kuz...@credativ.co.uk >> Web:http://www.credativ.co.uk >> Suite 5 | Bloxam Court | Corporation Street | Rugby | CV21 2DU | UK >> >> We would love to hear your thoughts on our service! >> Please send your comments to feedb...@credativ.co.uk >> >> credativ Ltd is registered in England & Wales, company no. 5261743 >> Certified by CompTIA / AccredITUK with the ICT Supply standard of >> quality for Software Product Design and Development >> >> >> -- >> 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 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 mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Cross-model relations
That sounds great. Is this on the roadmap for the 2.0 release or a bit further down the line? Thanks, Sandor On Fri, Jul 22, 2016 at 9:37 AM, Mark Shuttleworth wrote: > On 22/07/16 09:14, Sandor Zeestraten wrote: > > What are your thoughts on cross-model relations? Is this something that is > compatible with the current design philosophy of Juju 2.0 or am I not > understanding the model concept? > > Let's say you have a bunch of separate models with services that you'd > like to monitor. Could you have one central monitoring service in a > dedicated monitoring model that then has relations to the different models? > Or do you need to deploy a monitoring charm in each model and then > aggregate the results? > > Any thoughts or ideas on how to approach this? > > > Yes, this is exactly what we'd like to do! All the pieces are now in place > with multi-user multi-model controllers, we just need to connect the dots > very carefully :) > > Mark > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Cross-model relations
Hi there, What are your thoughts on cross-model relations? Is this something that is compatible with the current design philosophy of Juju 2.0 or am I not understanding the model concept? Let's say you have a bunch of separate models with services that you'd like to monitor. Could you have one central monitoring service in a dedicated monitoring model that then has relations to the different models? Or do you need to deploy a monitoring charm in each model and then aggregate the results? Any thoughts or ideas on how to approach this? Thanks, Sandor -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
