[00:00] bdx: okay, so this is for getting users to connect to a juju environment [00:00] not like setting them in a charm [00:01] bdx: you could just gpg encrypt the environment.yaml files and ship them to users ;) [00:12] marcoceppi: so yea...what I decided on for the time being was to extract the secrets from environments.yaml and in environments/.jenv and add them to our hiera secrets (how we puppet secrets using gpg), then add the different juju environments.jenvs and environment.yaml as templates that get the secrets from hiera ....these will get puppeted into each users ~/.juju [00:12] sounds good [00:13] bdx: the way user credentials are managed in juju 2.0 should help this a bit. I think we'll talk more about it at the Summit if you're interested [00:14] marcoceppi: haha...if I'm interested.... I can't wait man! [00:14] bdx: I think you' [00:14] re going to like what we're cooking up for 2.0! [00:17] marcoceppi: bdx juat got off the phone with the folks doong that work [00:17] marcoceppi: I'm pumped for 2.0 and I don't even know any details :-) [00:18] marcoceppi: bdx we'll support both externalnauth files and per user juju credentials that'll fix this up for 16.04 [00:18] rick_h_: awesome! we should have a "juju 2.0 features" talk at the Summit [00:19] sharing a model won't need anything but a one liner with a one time password to share out [00:19] I know I'm excited about it and a lot of us are looking forward to it [00:19] marcoceppi: definitely [00:20] bdx: so sorry to hear the problem you're having but also happy it's something we care a lot about fixing and a team is doing right niw [00:20] now [00:21] rick_h_: very exciting! .... I want feature set 2.0 NOW! [00:21] :-) [00:21] bdx: there's a 1.26-alpha3 out now, and a 2.0-alpha1 coming out in a few weeks, check the list for details [00:21] always [00:21] (1.26-alpha3 is basically 2.0-alpha0) [00:22] bdx: we'll have bit in the 2.0 alphas starting after the new year so keep an eyenout and give things a try [00:22] bdx: feedback isnalways great to have early and often [00:23] I've started the DHC conversion ....converted the staging version of 1 of 6 of our web applications to be juju deployed.... http://paste.ubuntu.com/14133640/ [00:24] bdx: epic [00:24] now I just need to figure out the fine details of how I will be sharing it throught our environment between devs and whatnot [00:24] getting it dialed [00:25] rick_h_: ^^I'm your man [00:25] bdx: let us know if we can help with access stuff. fwiw, there is some early user control stuff in 1.25 that might help `juju help user` [00:25] at least, I think that's in 1.25 [00:25] but 2.0 will make it stupid simple to have users connect to an environment [00:26] uggggh .... 2.0 is dropping alongside xenial? [00:28] marcoceppi, rick_h_: 2.0-alpha1 will have support for externalnauth files and per user juju credentials ? [00:29] * marcoceppi chceks his crystal ball [00:32] * marcoceppi has no idea [00:32] haha no worries [00:33] I'll be keeping an eye out [00:33] very exciting none the less [00:33] bdx: I think alexisb or rick_h_ were going to publish a roadmap to the list, I think there's still some finalizations being made as to what the plan will be between now and April [00:33] bdx: and yes, the plan is to have Juju 2.0 in Xenial and then backported to trusty [00:33] Thats great! [00:37] I have 2 lxd stacks in the testlab running on wily atm [00:38] bdx: awesome! [00:38] I just did my first lxd deploy [00:41] bdx: probably not that early. The work is just starting and the first work is some stuff around providing ootb cloud definitions [00:41] rick_h_: ok, I'll be looking out! [00:41] bdx: the goal is to split the cloud definitions/files from the user credentials from the actual juju user [00:42] bdx: e.g. if I bootstrap and share with you then you don't need anything to do with the cloud or how to connect to it, juju knows that [00:42] bdx: you just need to know how to auth to juju itself ans ask it to do things [00:42] bdx: so the work will start on the cloud end and the sharing part will be later on top of that [00:43] rick_h_: that makes total sense.... considering what I just went through sorting the secrets, and determining which ones are pertinent to the user, and which to the environment.... that seems like a grand solution [00:44] bdx: glad to hear it [00:45] rick_h_, marcoceppi: thanks for the great info! I'll be in touch! [05:24] Someone was talking in here (I think) a while back about bootstrapping into LXC/LXD containers on MAAS-deployed nodes. Can that person or persons ping me when they're around? === dpm is now known as dpm-afk [09:29] I'm doing an upgrade test of juju charms and openstack today, is there any documentation on the best ordering for the upgrades? [10:02] dweaver`: wish you a lot, a lot of luck [10:03] Walex2, Yeah, thanks for that ;) [10:08] +1 [10:09] everything i've seen just says to "update the release name in the charm" :| [10:09] dweaver`: if you don't mind me asking, you using network bonds? [10:14] Bofu2U, no, relatively simple openstack deployment on about 6 machines, using 3 networks, but dedicated NICs (manually configured outside of MAAS and Juju). [10:15] ah ok [10:15] yeah I'm trying to get my interfaces file to work but having some trouble because of tagged/untagged on bridges through a bond [10:16] Just interested if anyone has a service upgrade ordering, I've seen some articles, but with Juju charms the process is slightly different. [10:18] I'm going to try: Rabbit, Mysql, Keystone, Glance, Cinder, Neutron-Api, Neutron-gateway, Nova-C-C, Nova-compute, ceilometer, heat. Anyone disagree or know any better order, do let me know, otherwise, I'll probably publish the results at some point. === dpm-afk is now known as dpm [10:52] dweaver`: that's as good an order as any === Spads_ is now known as Spads === rvba` is now known as rvba === scuttle` is now known as scuttle|afk [13:08] jog_: ping? [13:26] marcoceppi, Thanks Marco, We're testing that order now. Upgrade is going OK, with several bugs in non-openstack charms, such as Mysql, Mongodb and Ceph, only 1 bug so far with the openstack charms, minor bug in neutron-api. I'll submit all the bugs when we're done. [14:40] dweaver`: at our site we have found that OpenStack is amazingly buggy, and Juju is slightly better. So I wish you a lot of luck with OpenStack :-) [14:57] dweaver`: I just started rewriting the mongodb charm for xenial, what problems did you run into? [15:01] marcoceppi, When changing the source to the next cloud archive it did not update the apt sources file, hence there was no upgrade. [15:02] dweaver`: which mongodb version were you expecting to get from cloud archive? [15:04] marcoceppi, then there seems to be possibly another issue, which I would have to confirm, that when packages are updated there is an "apt-get install PACKAGE" which installs the latest package version, but only that package version, I don't think this mattered with mongodb, but it did with mysql as it just updated the mysql-server metapackage and not the mysql-server-5.5 package. [15:04] dweaver`: ah, yeah [15:05] dweaver`: the MySQL charm is next on my charms to rewrite [15:09] Mmike, we were using trusty juno cloud archive and upgrading to kilo cloud archive. The mongodb version we ended up with was 1:2.4.9-1ubuntu2. [15:09] not sure if the version actually changed [15:14] So, is mongodb in the cloud archive? [15:19] Well, clearly not, now I check, which makes MongoDB outside the updates of the cloud archive and the setting "source" in the charm is misleading. However, changing the source from juno to kilo cloud archive was not honoured. And I saw similar behaviour with the ceph charm too, so not sure until I can isolate the logs if these are related or not. [15:22] Should juju 1.24.7 be able to connect to a vsphere environment? I following the manual and don't succeed? Can someone lend me a hand? [15:24] When bootstrapping I currently receive the following error: "failed to create new client: Post https://myuser:mypassword@172.20.13.140/sdk: dial tcp: unknown port tcp/Hv" [15:24] I'm just following juju docs, so what am I missing here? [15:29] alias_: not sure, but could it be you need to include the port for your vSphere API server? [15:30] marcoceppi: It's just 443 but I'll give it a shot === jog_ is now known as jog === scuttle|afk is now known as scuttlemonkey === blahdeblah_ is now known as blahdeblah