[00:15] is 1.25 and xenial supposed to work? I filed LP#1557345 because I'm having issues with it deploying to containers [00:23] bradm, it works if lxc is installed [00:24] but you will not be able to deploy a lxc container on a vanilla xenial image as lxc is not installed by default [00:24] alexisb: huh, its installed for me [00:25] alexisb: and it doesn't work deploying a container to it [00:26] alexisb: the tl;dr is that I took a working juju environment deploying to canonistack, just changed the default series, did a juju bootstrap and then a juju deploy local:xenial/ubuntu --to lxc:0, and got an error as per my bug [00:31] davecheney: looking now. was afk for a bit. [00:34] davecheney: ship it [00:35] ta [00:43] gah! nasty horrible import loop [00:51] bradm: could u please add this infor to the bug too? [00:53] anastasiamac_: that they're just bootstrapped? sure. I'm testing it out again, will confirm if lxc is installed both before and after I attempt the deploy [00:54] bradm: :D that u "... took a working juju environment deploying to canonistack, just changed the default series, did a juju bootstrap and then a juju deploy local:xenial/ubuntu --to lxc:0, and got an error as per my bug" [00:54] bradm: tyvm \o/ [00:55] anastasiamac_: most of that's already in the bug, but not as concise. [01:07] wallyworld: give me 15 mins please, just finishing cooking my lunch [01:07] axw: talking to anastasiamac_ , will ping when ready [01:16] alexisb: I can also confirm a freshly booted environment has lxc installed already when I can log into it, before I try to deploy [01:18] bradm, can you deploy without the --lxc? [01:18] bradm, I am about to eod, but I can raise visibility on the bug tomorrow [01:19] alexisb: yes I can, it spins up a new instance. which is fine, but doesn't work too well with HA openstack [01:21] alexisb: I think jillr is going to be having a seperate conversation about upgrading juju with cherylj tomorrow, but figuring out what I can do to unblock this would be great - I don't particular care what juju version it is, just that I can deploy to LXCs - this is ultimately to get a deployable xenial with mitaka openstack [01:23] bradm, ok, I see you added our convo to the bug [01:23] alexisb: yup, just to be clear about what's happening. [01:24] I will get the right eyes on the bug tomorrow [01:24] excellent, thanks very much. [01:29] menn0: so i fixed the lxd reboot tests, and it turns out they don't work [01:29] github.com/juju/juju/container/lxd/lxd_go12.go:24: LXD containers not supported in go 1.2 [01:29] github.com/juju/juju/cmd/jujud/reboot/reboot.go:88: failed to get manager for container type lxd [01:29] github.com/juju/juju/cmd/jujud/reboot/reboot.go:134: [01:29] github.com/juju/juju/cmd/jujud/reboot/reboot.go:66: [01:36] axw: ping whenever you are free, after lunch [01:37] wallyworld: just cooking, it's only 9:30 :) I'm free now [01:37] wallyworld: standup? [01:37] sure [01:40] davecheney: all the lxd stuff should be hidden behind +build !go1.3 === natefinch-afk is now known as natefnich === natefnich is now known as natefinch [01:41] davecheney: which maybe is what you found === bruno is now known as Guest32213 === ses is now known as Guest21273 [02:21] anastasiamac_: looking at your virttype PR now [02:22] menn0: thnx? :D [02:34] wallyworld: I have a type that supports gnuflag, for --resource foo=bar --resource baz=bat. I need to use it in juju/juju and also in the charmstore-client. I was thinking of putting that type in github.com/juju/cmd ... since it's a pretty useful type to have around in general. Do you think that's an ok place, and if not, do you have a suggestion for a better place? [02:35] natefinch: what does the type do that's not already covered by our existing key-value flags type? [02:35] wallyworld: AFAIK we don't actually have a key-value flags type... there [02:35] let me try and find it [02:36] wallyworld: there's the constraints-style keyvalue type, but that is severely restricted as to what keys and values it can support [02:36] we have another general one that frank wrote [02:36] wallyworld: there's a storage one [02:38] wallyworld: there's something for bindings [02:41] anastasiamac_: review done [02:41] menn0: \o/ thank u - looking [02:43] natefinch: yeah, i can't find anything, i may have misremembered what we had [02:43] juju/cmd seems a good spot [02:43] wallyworld: there's a few similar things, but nothing quite so straightforward [02:44] wallyworld: cool [02:44] i could have sworn we have a generic key=value one [02:44] we do have one but tit also accepts filenames [02:44] not just key values [02:45] the filename if specified contains key values [02:49] anastasiamac_: menn0: providers have a constraints validation interface which they implement - that's where the virt type value needs to be checked [02:49] yes [02:50] wallyworld: my question here was more along the lines of whether we have a set ofvirt types that we'd accept (like we do with arches) [02:50] provider dependent, hence the validation done in the provider [02:50] wallyworld: menn0: however, m happy to not do any validation and only do it on a provider side :D [02:50] even with arches, validation done one the provider also [02:51] apart from initial check [02:53] wallyworld: agreed... since i saw the initial arch check in constraints/validation, I've added the to-do to confirm that I did not need to do something similar for virttype. [02:53] wallyworld: i'll remove todo [02:53] ty :-) [02:54] wallyworld, anastasiamac_ : sounds good. I think we were all pretty much on the same page :) [02:54] in violent agreement :-) [02:54] :P [02:58] anastasiamac_: did you happen to test with a provider that doesn't support virt-type? I think we need to register unsupported constraints for them all (which is kinda dumb; should be a whitelist I think) [02:59] anastasiamac_: sorry, I think I just asked the same thing wallyworld did [02:59] axw: sounds good. I've hit merge but will add it now as a separate PR [03:00] although if virt-type is not specified, all will be good [03:00] if it's specified, and virt-type is not supported on clouds, we'd just say that nothing matches specified constraints... [03:01] anyone up for a quick and pretty painless review? http://reviews.vapour.ws/r/4190/ [03:06] re: ^ note this is a straight up copy of already-reviewed code in juju-core, just moving it somewhere accessible to other projects. [03:14] natefinch: reviewed [03:14] with juju 2.0 I'm seeing some very weird deltas. somehow a unit went from a config-changed hook error, to maintenance, to error [03:14] anastasiamac_: yep, I think we could just be a bit more helpful and say immediately that virt-type isn't handled by the provider [03:14] rather than filtering all the things out and saying nothing matches [03:15] hatch: hook retries maybe? [03:15] axw: sure. if my current PR lands, I'll follow it up (if it fails, i'll amend current) [03:15] axw: would a hook automatically retry? [03:15] anastasiamac_: thanks [03:15] hatch: yes, support was added not too long ago to automatically retry failed hooks [03:16] axw: interesting point about resources for services in bundles..... it's been on our mind, but we're basically out of time to implement it at this point. [03:16] axw ohh ok then, this is news to me - that would explain why I was seeing such weird results. [03:16] natefinch: fair enough. just keep that code in mind when you do get there [03:17] axw I'm also seeing that the 'juju status' updates quite a bit sooner than the delta stream...is this also possible? [03:17] axw: definitey, thanks for the pointer. That's really probably the most difficult part, is just the annoying contortions on the command line [03:18] hatch: possible, yeah. deltas are based of a polling mechanism [03:18] I forget the period, but it's in the seconds [03:18] ... I think [03:18] in this case, it was probably 10s [03:18] hatch: sounds about right [03:19] Bug #1555355 changed: MachineSerializationSuite.TestAnnotations unit test failure (Go 1.6)

[03:19] Bug #1557345 opened: xenial juju 1.25.3 unable to deploy to lxc containers

[03:19] ok thanks for confirming - I'm just qa'ing my changes to support the new agent_state er...JujuStatus and WorkloadStatus [03:19] thanks axw [03:19] hatch: no worries [03:19] lol, landing stuff outside of juju/juju is so much easier. CI runs in like 30 seconds rather than 30 minutes [03:25] axw: I'm a dip: http://reviews.vapour.ws/r/4191/ [03:26] natefinch: heh, oops :) [03:33] davecheney: this is much better: http://reviews.vapour.ws/r/4185/ [03:33] davecheney: PTAL [04:01] Bug #1557345 changed: xenial juju 1.25.3 unable to deploy to lxc containers

[04:05] axw: i've also added support for setting allowed values to accommodate the "algorithm" attribute in joyent config http://reviews.vapour.ws/r/4171/ [04:07] wallyworld: cool, looks good. I was wondering whether we can determine the algorithm from the key... [04:07] wallyworld: is it ready for re-review now then? [04:07] axw: yeah, why not [04:09] axw: i realised i no longer need to pass authtpye to finalise, i'll remove that [04:09] wallyworld: thanks, was about to comment [04:10] menn0: looking [04:11] and an import fix [04:19] menn0: https://github.com/juju/juju/pull/4749 [04:19] could you check again [04:19] i had to skip the test if built with go 1.2 [04:20] wallyworld: reviewed [04:20] because lxd compiles on go 1.2, but doesn't actually work [04:20] ta [04:20] which i'm not sure is helping [04:21] axw: i didn't know about strictfieldmap, i'll use that [04:21] file attr may still be interesting though [04:21] davecheney: looking [04:22] wallyworld: file attr? [04:23] axw: the schema declares it has an attribute "foo". we then use a map with key "foo-file" which proves the value for "foo". "foo-file" would be declared invalid for a scrict schema map, no? [04:24] s/proves/provides [04:24] wallyworld: there will be two fields in the checker [04:24] wallyworld: foo and foo-file [04:25] wallyworld: both marked non-mandatory [04:25] davecheney: still ship it [04:26] axw: i'll look at it - tests as written won't pass at the moment i think [04:26] wallyworld: okey dokey [04:26] as they don't construct a schema containing foo-file [04:27] axw: and joyent schema won't pass either - so i'll need to inject any file attributes into the schema [04:28] wallyworld: I'm saying they already are added to the environschema [04:28] wallyworld: look at schemaChecker(), search for "(file)" [04:28] as yes [04:28] ah yes [04:28] so they are [04:29] davecheney: the reason for the blank lines was to separate the test setup, from the call being tested , and then the test asserts [04:29] davecheney: but whatever :) [04:33] meh, your call [04:34] blank lines matter? [05:04] menn0: axw: black-listing virt-type as constraint for all providers http://reviews.vapour.ws/r/4192/ [05:06] anastasiamac_: I'm a bit confused about the comment in ec2. are we using the virt-type constraint in ec2? [05:06] doesn't look like it [05:07] axw: no we are not [05:07] it's not in the code. [05:07] anastasiamac_: ok, then it should be in unsupported constraints [05:07] axw: i'll remove the comment but wanted 2nd pair of eyes to confirm that m not imagining things [05:08] axw: yep. i'll remove the comment now that u agree. [05:08] anastasiamac_: yeah, I guess we'll want to expose it sooner or later (choose pv/hvm), but we should reject if we're not using it [05:08] anastasiamac_: thanks [05:31] Bug #1557874 opened: juju behaviour in multi-hypervisor ec2 clouds

[05:39] wallyworld: with all the CLI changes, is there a way to upload tools for multiple versions anymore? [05:39] series [05:39] specifically, I want to test the LXD provider on Trusty hosting an extra unit on Xenial [05:39] but I need to have tools in state for Trusty and Xenail [05:39] Xenial [05:40] jam: i'd have to check - at one point we uploaded tools for the specified series and any lts series automatically, give be a minute to look [05:41] wallyworld: thanks. I found something weird where "juju bootstrap test-lxd --upload-tools --bootstrap-series xenial" didn't work but somehow "--upload-tools --bootstrap-series xenial --config default-series=xenial" did, IIRC [05:41] but I want both Trusty and Xenial, not just one or the other. [05:42] jam: bootstraa-series is new - it could just be that uploadtools doesn't account for it [05:42] in fact, i bet that is the case [05:42] wallyworld: sure, but I still want both :) [05:42] so should be a simple fix [05:42] yes, both need to be accounted for [05:43] wallyworld: right, I'm looking for the old "--upload-series trusty,xenial" that we used to have [05:43] wallyworld: or even just some other command that lets me push a binary as the right tools for the series [05:43] it doesn't have to be all munged in one thing, just a way to have compiled tools for 2 series [05:45] i think so long as it honours bootstrap-series, default-series that will be a start. i can't recall what happened to the "use these series explicitly" bootstrap option, i seem to recall that was deprecated by someone so we removed it for 2.0 [05:50] jam: when you upload for one series, the server explodes that into all series for the same OS [05:52] jam, wallyworld: I'm doing the code to create local-login macaroons now. thoughts on a sensible expiry time? it's 1h for external, but that's too frequent for local I think. maybe 24h? [05:52] i think that sounds ok [05:52] axw: what happens when the macaroon expires? It just does an extra login step? [05:52] requires you to enter your password again? [05:52] yes [05:52] will prompt [05:52] jam: yup [05:52] online having to open a web browser every hour sounds very bad [05:53] 24h i ok though right? [05:53] wallyworld: how often do you like to 2-factor auth? [05:53] even 1/day is pretty hard [05:53] heh :) [05:53] agreed [05:53] fair point [05:55] wallyworld: axw: I set up SSH keys so I don't have to enter my passwords for things, and run an agent so I can enter it on login and forget about it for quite a while. [05:55] Bug #1557470 changed: juju reads from wrong streams.canonical.com location

[05:55] Ubuntu SSO does some things about remembering your login for a while so it can recognize you [05:55] if we have something like that [05:56] jam: isn't that just the same? a time based token? [05:57] axw: so the SSO thing means that it is shared across users. If we're integrating with that such that we don't have to prompt the user as long as their SSO is still valid then that macaroon can be any timeout [05:57] we are just checking that they really are still valid, the *real* timeout is SSO [05:57] For Local, we'd like something akin to that. [05:57] Where we can issue a challenge+reauth at any time, but the *user* is in control of how ofter the real reauth happens. [05:57] I may not be clear [05:58] ssh-agent is the thing that says how often I need to login [05:58] not "ssh $MYHOST" [05:58] jam: ok, understand [05:58] I don't know if we have something tasteful here. [05:58] axw: its the sort of thing we may want a knob on the server for [05:59] so my cruddy sites I just set to never expire [05:59] jam: this is for a local controller without sso or an external identity manager [05:59] and the Production servers expire daily [05:59] without sso or an external identity manager, we just use username/password as set on the controller for that user [06:00] and we use a macaroon (time based) to avoid re-authenticating each time [06:00] wallyworld: sure I understand that bit. but how often do I need to auth to it. *Today* we never have to reauth, and its all local, and its pretty nice. [06:00] authentication is done by controller [06:00] jam: that sounds sane. I'll implement without that first, then add config for timeout [06:00] right, but we need a balance between what we have today and being secure [06:01] wallyworld: maybe. passwords that people can remember are rarely actually secure, which means you actually use a password manager [06:01] which means yet again the thing that actually decides how often you "auth" is something else. [06:02] (LastPass, your custom gpg encrypted secrets file, etc) [06:02] indeed, i use one for github and when that times out on the cli, it's trivial to paste in the pw again [06:02] 2 clicks in my browser plugin and paste [06:04] wallyworld: anyway, I would highly suspect people generating solid passwords for a local controller, which means we're just aggressively pissing them off to pass it in all the time. [06:04] likely it means them using weaker passwords that are easier to enter [06:04] ultimately being weaker security [06:05] sure, we just need to decide what "all the time" is in order to piss people off. 1day, 1 week, 1 month? [06:05] wallyworld: with your browser, if someone can login as you, then they're in. If I can login to my Laptop as Jameinel, I may (may not) need to login to Juju on that machine as well. [06:05] I'm just thinking through the space [06:06] i agree a short time is bad. i just think it should be finite [06:06] wallyworld: flip side, what happens if you forget your password? [06:06] What is our password recovery mechanism [06:06] nothing (yet). that is a currrent limitation [06:06] I'm still one "sudo foo" away from being root [06:07] I just hesitate to say "you must remember a password you set" and then not give a way to recover. [06:07] but if the recovery mechanism is weaker than the password, we haven't added security. [06:07] maybe 1/day is reasonable. [06:07] recovery is definitely on the todo list [06:07] as it at least makes you think about it. [06:07] wallyworld: I have a strong feeling that local passords actually don't make sense. [06:07] maybe 1 week or 1 month even. i have no firm view on how long, happy to let others decide [06:08] wallyworld: well 1 month is just saying "forget about this until 1 month later when you won't remember it" [06:08] I'm worried that its the same problem as you may not do "juju foo" for a month [06:08] regardless of the password timeout being shorter [06:08] well, i can't remember my gh password :-) [06:09] wallyworld: yeah, I have several 16 char random passwords I can't remember at all. [06:09] but those integrate with Firefox [06:09] not the gh cli [06:09] but really easy still [06:09] it comes down to i guess, how to we stop unauthorised people from loggin in to your controller [06:10] *today* we have a token on disk [06:10] you mean the ca cert? [06:10] I mean the password in ~/.juju/environments/ENV.jenv [06:11] that' s not there anymore, nor is most of bootstrap config, i'd need to double check what we do now [06:11] wallyworld: the password for admin@local in accounts.yaml is what was admin-secret [06:12] i didn't thinl client login needed anything more than the ca cert [06:12] ah right [06:12] wallyworld: ~/.local/share/juju/accounts.yaml [06:12] wallyworld: it needs a username and password. ca-cert is just for verifying the server's identity [06:12] i forgot [06:12] brain too full [06:12] heh [06:14] I think the statement from tim was that "If you have the cloud credentials you can get in as ADMIN" [06:14] which is. ok, fine. I can spend the money on the cloud, I can get into the env. Maybe not perfect, but something. [06:14] I have $root$ on my local machine, is that enough? [06:14] jam: ideally, although you could just as easily throw away your SSH keys [06:15] well maybe not *just* as easily :) [06:15] jam: I haven't thought a lot about how to do recovery yet, but was thinking of having a localhost-only interface on the controller machines to do that. if you can ssh into machine-0, then you can fix up your own password [06:15] and any admin can change anyone elses password [06:16] axw: so a unix socket is how LXD does it [06:16] so certainly there is precedent. [06:16] might even be how mongo does as well? [06:17] jam: yep, you have to start mongo in a special way tho IIRC (excluding the first startup, where there's an exception if you have no password set yet) [06:19] axw: and certainly we have to consider that we can't be more secure in Juju than someone who can access our DB [06:19] they can just set the password there. [06:19] * axw nods [06:20] jam: speaking of, we should probably disallow sharing admin models with non-admins :) [06:20] otherwise I'll just "juju deploy backdoor --to 0" [06:27] axw: wallyworld: so if it is "you don't need a password if you're on the machine" and you need to refresh your login 1/day from another machine, we can live with it. I don't think it is quite there overall, but it is probably acceptable. [06:28] jam: ok, thanks [06:29] sgtm [07:06] cherylj: perrito666: if you see this later. With my branch you now see messages if you do "juju status --format=yaml" but machine-status messages aren't shown by default in "juju status" output. [07:06] so we have some visibility, but not a huge amount. [07:06] wallyworld: on the downside, "juju status-history" is filled with 100 "downloading image 98%" messages. [07:06] oh joy [07:07] wallyworld: so its super nice to see the progress in status [07:07] but it is yet-another status-history message [07:07] why hasn't my machine started yet? Because the image copy is only 70% done. great [07:07] we should make that more usable [07:07] wanna file a bug? [07:08] wallyworld: expose status messages in default "juju status" or be able to have a message that gets updated instead of adding yet-another message? [07:08] both :-) [07:14] wallyworld: what is the map in SetInstanceStatus for? I haven't seen anywhere that it ever gets set. [07:14] Is it set from "status-set" in charm hooks? [07:14] jam: it accounds for the fact that we may want to pass some arbitary data, like for other status [07:15] eg [07:15] we could pass in the download percentage or something [07:15] or time remaining [07:15] wallyworld: we can, but if nothing is touching it, exposing it, does it actually do anything? [07:15] I guess the API would expose it? [07:16] yeah eg for juju status [07:16] the yaml output has omitempty [07:16] that's the way it works for normal status, i assume it's the same here [07:16] so it is shown just not in the default format. [07:16] it's been a while since i sw the code [07:17] yes, not sown in tabular [07:17] shown [07:17] tabular is more of a summary [07:20] wallyworld: bugs filed [07:20] ty [07:21] i'll try and get them done this week [07:21] there's a similar bug about status-history spam [07:21] for update-status calls [07:22] Bug #1557914 opened: "juju status" doesn't show machine-status messages by default

[07:22] Bug #1557918 opened: "juju status-history" doesn't include the concept of progress messages

[07:28] wallyworld: yeah, it certainly feels similar to the update-status issue [07:28] yup [07:29] wallyworld: I wonder if a flag like "current-only" would be relevant. [07:29] This is a message that should be displayed, but doesn't need to be logged. [07:29] yeah, i was wondering if we needed to do that [07:29] there's an argument though that we should store everything and filter on display [07:30] wallyworld: that's ok, but not showing by default is the important bit. [07:30] so that you can get the interesting bits [07:30] wallyworld: I thought the status-history collection only stored a limited set of history, though. [07:30] does it store everything always? [07:30] it's capped [07:31] right, so that's a reason to elide them [07:31] cause otherwise 100 "I'm almost there" messages end up pushing out the real content. [07:31] depends on the size but yeah [07:31] Bug #1557914 changed: "juju status" doesn't show machine-status messages by default

[07:31] Bug #1557918 changed: "juju status-history" doesn't include the concept of progress messages

[07:32] jam: i do like the idea of a "don't log this flag". but william afaik against throwing away data [07:32] eg who cares if we ran the update status hook 100 times [07:33] wallyworld: so I can see people wanting to know "when was the last time update-status was run" because something was going wrong there. [07:33] I can hypothesize it, at least. [07:33] But *nobody* cares about something that happens more than 10-ish time [07:34] times [07:34] yes [07:34] other than gathering stats about it [07:34] you just can't think about it [07:34] 100 messages saying "copying" [07:34] did you notice it was 99 and 73% wasn't there? :) [07:40] Bug #1557914 opened: "juju status" doesn't show machine-status messages by default

[07:40] Bug #1557918 opened: "juju status-history" doesn't include the concept of progress messages

[08:14] axw: interactive add credentials done but i need to rework the provider credentials schema because we want the attributes to be ordered, and atm it is a map [08:15] wallyworld: ok === Guest32213 is now known as BrunoR [10:01] dimitern: frobware: stdup? [10:09] wallyworld: jam reading your comment last night [10:10] why dont we grow a loglevel-sh attr to status? [10:10] morning all btw [10:20] Bug #1557993 opened: Can't create lxc containers with 1.25.4 and MAAS 1.9 and xenial

[10:24] wallyworld: it's all very hacky atm, but I've got a "juju login" which will request a macaroon, write it to accounts.yaml, and then use that for future logins [10:32] axw: congrats btw [10:37] perrito666: you mean for status-history ? yeah something like that seems valid. [10:39] jam: well status history its just something that gets created by setstatus so we should add it to status as a whole but that would not hurt since it can just be ignored where it has no value [10:39] default loglevel should be the one that gets stored in history [10:39] perrito666: the caveat here is that we want it shown in the "juju status" content, because it is currently active dataa [10:40] however, once it has expired, it isn't really worth hanging onto it/showing it by default [10:40] which is a bit different interprentation of log level, where log level is not-shown-at-all [10:40] jam: you mean you want to set the status and then have it dissapear? [10:40] perrito666: I mean that when you do "juju status 0/lxd/0" you want to see "copying image: 25%" [10:41]