bradmis 1.25 and xenial supposed to work?  I filed LP#1557345 because I'm having issues with it deploying to containers00:15
alexisbbradm, it works if lxc is installed00:23
alexisbbut you will not be able to deploy a lxc container on a vanilla xenial image as lxc is not installed by default00:24
bradmalexisb: huh, its installed for me00:24
bradmalexisb: and it doesn't work deploying a container to it00:25
bradmalexisb: 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 bug00:26
menn0davecheney: looking now. was afk for a bit.00:31
menn0davecheney: ship it00:34
menn0gah! nasty horrible import loop00:43
anastasiamac_bradm: could u please add this infor to the bug too?00:51
bradmanastasiamac_: 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 deploy00:53
anastasiamac_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
anastasiamac_bradm: tyvm \o/00:54
bradmanastasiamac_: most of that's already in the bug, but not as concise.00:55
axwwallyworld: give me 15 mins please, just finishing cooking my lunch01:07
wallyworldaxw: talking to anastasiamac_ , will ping when ready01:07
bradmalexisb: I can also confirm a freshly booted environment has lxc installed already when I can log into it, before I try to deploy01:16
alexisbbradm, can you deploy without the --lxc?01:18
alexisbbradm, I am about to eod, but I can raise visibility on the bug tomorrow01:18
bradmalexisb: yes I can, it spins up a new instance.  which is fine, but doesn't work too well with HA openstack01:19
bradmalexisb: 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 openstack01:21
alexisbbradm, ok, I see you added our convo to the bug01:23
bradmalexisb: yup, just to be clear about what's happening.01:23
alexisbI will get the right eyes on the bug tomorrow01:24
bradmexcellent, thanks very much.01:24
davecheneymenn0: so i fixed the lxd reboot tests, and it turns out they don't work01:29
davecheneygithub.com/juju/juju/container/lxd/lxd_go12.go:24: LXD containers not supported in go 1.201:29
davecheneygithub.com/juju/juju/cmd/jujud/reboot/reboot.go:88: failed to get manager for container type lxd01:29
wallyworldaxw: ping whenever you are free, after lunch01:36
axwwallyworld: just cooking, it's only 9:30 :)  I'm free now01:37
axwwallyworld: standup?01:37
natefinch-afkdavecheney: all the lxd stuff should be hidden behind +build !go1.301:40
=== natefinch-afk is now known as natefnich
=== natefnich is now known as natefinch
natefinchdavecheney: which maybe is what you found01:41
=== bruno is now known as Guest32213
=== ses is now known as Guest21273
menn0anastasiamac_: looking at your virttype PR now02:21
anastasiamac_menn0: thnx? :D02:22
natefinchwallyworld: 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:34
wallyworldnatefinch: what does the type do that's not already covered by our existing key-value flags type?02:35
natefinchwallyworld: AFAIK we don't actually have a key-value flags type... there02:35
wallyworldlet me try and find it02:35
natefinchwallyworld: there's the constraints-style keyvalue type, but that is severely restricted as to what keys and values it can support02:36
wallyworldwe have another general one that frank wrote02:36
natefinchwallyworld: there's a storage one02:36
natefinchwallyworld: there's something for bindings02:38
menn0anastasiamac_: review done02:41
anastasiamac_menn0: \o/ thank u - looking02:41
wallyworldnatefinch: yeah, i can't find anything, i may have misremembered what we had02:43
wallyworldjuju/cmd seems a good spot02:43
natefinchwallyworld: there's a few similar things, but nothing quite so straightforward02:43
natefinchwallyworld: cool02:44
wallyworldi could have sworn we have a generic key=value one02:44
wallyworldwe do have one but tit also accepts filenames02:44
wallyworldnot just key values02:44
wallyworldthe filename if specified contains key values02:45
wallyworldanastasiamac_: menn0: providers have a constraints validation interface which they implement - that's where the virt type value needs to be checked02:49
anastasiamac_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
wallyworldprovider dependent, hence the validation done in the provider02:50
anastasiamac_wallyworld: menn0: however, m happy to not do any validation and only do it on a provider side :D02:50
wallyworldeven with arches, validation done one the provider also02:50
wallyworldapart from initial check02:51
anastasiamac_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
anastasiamac_wallyworld: i'll remove todo02:53
wallyworldty :-)02:53
menn0wallyworld, anastasiamac_ : sounds good. I think we were all pretty much on the same page :)02:54
wallyworldin violent agreement :-)02:54
axwanastasiamac_: 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:58
axwanastasiamac_: sorry, I think I just asked the same thing wallyworld did02:59
anastasiamac_axw: sounds good. I've hit merge but will add it now as a separate PR02:59
anastasiamac_although if virt-type is not specified, all will be good03:00
anastasiamac_if it's specified, and virt-type is not supported on clouds, we'd just say that nothing matches specified constraints...03:00
natefinchanyone up for a quick and pretty painless review? http://reviews.vapour.ws/r/4190/03:01
natefinchre: ^  note this is a straight up copy of already-reviewed code in juju-core, just moving it somewhere accessible to other projects.03:06
axwnatefinch: reviewed03:14
hatchwith juju 2.0 I'm seeing some very weird deltas. somehow a unit went from a config-changed hook error, to maintenance, to error03:14
axwanastasiamac_: yep, I think we could just be a bit more helpful and say immediately that virt-type isn't handled by the provider03:14
axwrather than filtering all the things out and saying nothing matches03:14
axwhatch: hook retries maybe?03:15
anastasiamac_axw: sure. if my current PR lands, I'll follow it up (if it fails, i'll amend current)03:15
hatchaxw: would a hook automatically retry?03:15
axwanastasiamac_: thanks03:15
axwhatch: yes, support was added not too long ago to automatically retry failed hooks03:15
natefinchaxw: 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
hatchaxw ohh ok then, this is news to me - that would explain why I was seeing such weird results.03:16
axwnatefinch: fair enough. just keep that code in mind when you do get there03:16
hatchaxw I'm also seeing that the 'juju status' updates quite a bit sooner than the delta stream...is this also possible?03:17
natefinchaxw: definitey, thanks for the pointer. That's really probably the most difficult part, is just the annoying contortions on the command line03:17
axwhatch: possible, yeah. deltas are based of a polling mechanism03:18
axwI forget the period, but it's in the seconds03:18
axw... I think03:18
hatchin this case, it was probably 10s03:18
axwhatch: sounds about right03:18
mupBug #1555355 changed: MachineSerializationSuite.TestAnnotations unit test failure (Go 1.6) <ci> <go1.6> <test-failure> <unit-tests> <juju-core model-migration:In Progress by menno.smits> <https://launchpad.net/bugs/1555355>03:19
mupBug #1557345 opened: xenial juju 1.25.3 unable to deploy to lxc containers <canonical-bootstack> <juju-core:Triaged> <juju-core (Ubuntu):Invalid> <https://launchpad.net/bugs/1557345>03:19
hatchok thanks for confirming - I'm just qa'ing my changes to support the new agent_state er...JujuStatus and WorkloadStatus03:19
hatchthanks axw03:19
axwhatch: no worries03:19
natefinchlol, landing stuff outside of juju/juju is so much easier.  CI runs in like 30 seconds rather than 30 minutes03:19
natefinchaxw: I'm a dip: http://reviews.vapour.ws/r/4191/03:25
axwnatefinch: heh, oops :)03:26
menn0davecheney: this is much better: http://reviews.vapour.ws/r/4185/03:33
menn0davecheney: PTAL03:33
mupBug #1557345 changed: xenial juju 1.25.3 unable to deploy to lxc containers <canonical-bootstack> <lxc> <xenial> <juju-core:Invalid> <juju-core 1.25:Triaged by anastasia-macmood> <juju-core (Ubuntu):Invalid> <https://launchpad.net/bugs/1557345>04:01
wallyworldaxw: i've also added support for setting allowed values to accommodate the "algorithm" attribute in joyent config http://reviews.vapour.ws/r/4171/04:05
axwwallyworld: cool, looks good. I was wondering whether we can determine the algorithm from the key...04:07
axwwallyworld: is it ready for re-review now then?04:07
wallyworldaxw: yeah, why not04:07
wallyworldaxw: i realised i no longer need to pass authtpye to finalise, i'll remove that04:09
axwwallyworld: thanks, was about to comment04:09
davecheneymenn0: looking04:10
wallyworldand an import fix04:11
davecheneymenn0: https://github.com/juju/juju/pull/474904:19
davecheneycould you check again04:19
davecheneyi had to skip the test if built with go 1.204:19
axwwallyworld: reviewed04:20
davecheneybecause lxd compiles on go 1.2, but doesn't actually work04:20
davecheneywhich i'm not sure is helping04:20
wallyworldaxw: i didn't know about strictfieldmap, i'll use that04:21
wallyworldfile attr may still be interesting though04:21
menn0davecheney: looking04:21
axwwallyworld: file attr?04:22
wallyworldaxw: 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:23
axwwallyworld: there will be two fields in the checker04:24
axwwallyworld: foo and foo-file04:24
axwwallyworld: both marked non-mandatory04:25
menn0davecheney: still ship it04:25
wallyworldaxw: i'll look at it - tests as written won't pass at the moment i think04:26
axwwallyworld: okey dokey04:26
wallyworldas they don't construct a schema containing foo-file04:26
wallyworldaxw: and joyent schema won't pass either - so i'll need to inject any file attributes into the schema04:27
axwwallyworld: I'm saying they already are added to the environschema04:28
axwwallyworld: look at schemaChecker(), search for "(file)"04:28
wallyworldas yes04:28
wallyworldah yes04:28
wallyworldso they are04:28
menn0davecheney: the reason for the blank lines was to separate the test setup, from the call being tested , and then the test asserts04:29
menn0davecheney: but whatever :)04:29
davecheneymeh, your call04:33
natefinchblank lines matter?04:34
anastasiamac_menn0: axw: black-listing virt-type as constraint for all providers http://reviews.vapour.ws/r/4192/05:04
axwanastasiamac_: I'm a bit confused about the comment in ec2. are we using the virt-type constraint in ec2?05:06
axwdoesn't look like it05:06
anastasiamac_axw: no we are not05:07
anastasiamac_it's not in the code.05:07
axwanastasiamac_: ok, then it should be in unsupported constraints05:07
anastasiamac_axw: i'll remove the comment but wanted 2nd pair of eyes to confirm that m not imagining things05:07
anastasiamac_axw: yep. i'll remove the comment now that u agree.05:08
axwanastasiamac_: yeah, I guess we'll want to expose it sooner or later (choose pv/hvm), but we should reject if we're not using it05:08
axwanastasiamac_: thanks05:08
mupBug #1557874 opened: juju behaviour in multi-hypervisor ec2 clouds <juju-core:New> <juju-core 2.0:New> <https://launchpad.net/bugs/1557874>05:31
jamwallyworld: with all the CLI changes, is there a way to upload tools for multiple versions anymore?05:39
jamspecifically, I want to test the LXD provider on Trusty hosting an extra unit on Xenial05:39
jambut I need to have tools in state for Trusty and Xenail05:39
wallyworldjam: 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 look05:40
jamwallyworld: 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, IIRC05:41
jambut I want both Trusty and Xenial, not just one or the other.05:41
wallyworldjam: bootstraa-series is new - it could just be that uploadtools doesn't account for it05:42
wallyworldin fact, i bet that is the case05:42
jamwallyworld: sure, but I still want both :)05:42
wallyworldso should be a simple fix05:42
wallyworldyes, both need to be accounted for05:42
jamwallyworld: right, I'm looking for the old "--upload-series trusty,xenial" that we used to have05:43
jamwallyworld: or even just some other command that lets me push a binary as the right tools for the series05:43
jamit doesn't have to be all munged in one thing, just a way to have compiled tools for 2 series05:43
wallyworldi 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.005:45
axwjam: when you upload for one series, the server explodes that into all series for the same OS05:50
axwjam, 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
wallyworldi think that sounds ok05:52
jamaxw: what happens when the macaroon expires? It just does an extra login step?05:52
jamrequires you to enter your password again?05:52
wallyworldwill prompt05:52
axwjam: yup05:52
jamonline having to open a web browser every hour sounds very bad05:52
wallyworld24h i ok though right?05:53
jamwallyworld: how often do you like to 2-factor auth?05:53
jameven 1/day is pretty hard05:53
axwheh :)05:53
wallyworldfair point05:53
jamwallyworld: 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
mupBug #1557470 changed: juju reads from wrong streams.canonical.com location <simplestreams> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1557470>05:55
jamUbuntu SSO does some things about remembering your login for a while so it can recognize you05:55
jamif we have something like that05:55
axwjam: isn't that just the same? a time based token?05:56
jamaxw: 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 timeout05:57
jamwe are just checking that they really are still valid, the *real* timeout is SSO05:57
jamFor Local, we'd like something akin to that.05:57
jamWhere we can issue a challenge+reauth at any time, but the *user* is in control of how ofter the real reauth happens.05:57
jamI may not be clear05:57
jamssh-agent is the thing that says how often I need to login05:58
jamnot "ssh $MYHOST"05:58
axwjam: ok, understand05:58
jamI don't know if we have something tasteful here.05:58
jamaxw: its the sort of thing we may want a knob on the server for05:58
jamso my cruddy sites I just set to never expire05:59
wallyworldjam: this is for a local controller without sso or an external identity manager05:59
jamand the Production servers expire daily05:59
wallyworldwithout sso or an external identity manager, we just use username/password as set on the controller for that user05:59
wallyworldand we use a macaroon (time based) to avoid re-authenticating each time06:00
jamwallyworld: 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
wallyworldauthentication is done by controller06:00
axwjam: that sounds sane. I'll implement without that first, then add config for timeout06:00
wallyworldright, but we need a balance between what we have today and being secure06:00
jamwallyworld: maybe. passwords that people can remember are rarely actually secure, which means you actually use a password manager06:01
jamwhich means yet again the thing that actually decides how often you "auth" is something else.06:01
jam(LastPass, your custom gpg encrypted secrets file, etc)06:02
wallyworldindeed, i use one for github and when that times out on the cli, it's trivial to paste in the pw again06:02
wallyworld2 clicks in my browser plugin and paste06:02
jamwallyworld: 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
jamlikely it means them using weaker passwords that are easier to enter06:04
jamultimately being weaker security06:04
wallyworldsure, we just need to decide what "all the time" is in order to piss people off. 1day, 1 week, 1 month?06:05
jamwallyworld: 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
jamI'm just thinking through the space06:05
wallyworldi agree a short time is bad. i just think it should be finite06:06
jamwallyworld: flip side, what happens if you forget your password?06:06
jamWhat is our password recovery mechanism06:06
wallyworldnothing (yet). that is a currrent limitation06:06
jamI'm still one "sudo foo" away from being root06:06
jamI just hesitate to say "you must remember a password you set" and then not give a way to recover.06:07
jambut if the recovery mechanism is weaker than the password, we haven't added security.06:07
jammaybe 1/day is reasonable.06:07
wallyworldrecovery is definitely on the todo list06:07
jamas it at least makes you think about it.06:07
jamwallyworld: I have a strong feeling that local passords actually don't make sense.06:07
wallyworldmaybe 1 week or 1 month even. i have no firm view on how long, happy to let others decide06:07
jamwallyworld: well 1 month is just saying "forget about this until 1 month later when you won't remember it"06:08
jamI'm worried that its the same problem as you may not do "juju foo" for a month06:08
jamregardless of the password timeout being shorter06:08
wallyworldwell, i can't remember my gh password :-)06:08
jamwallyworld: yeah, I have several 16 char random passwords I can't remember at all.06:09
jambut those integrate with Firefox06:09
wallyworldnot the gh cli06:09
wallyworldbut really easy still06:09
wallyworldit comes down to i guess, how to we stop unauthorised people from loggin in to your controller06:09
jam*today* we have a token on disk06:10
wallyworldyou mean the ca cert?06:10
jamI mean the password in ~/.juju/environments/ENV.jenv06:10
wallyworldthat' s not there anymore, nor is most of bootstrap config, i'd need to double check what we do now06:11
axwwallyworld: the password for admin@local in accounts.yaml is what was admin-secret06:11
wallyworldi didn't thinl client login needed anything more than the ca cert06:12
wallyworldah right06:12
jamwallyworld: ~/.local/share/juju/accounts.yaml06:12
axwwallyworld: it needs a username and password. ca-cert is just for verifying the server's identity06:12
wallyworldi forgot06:12
wallyworldbrain too full06:12
jamI think the statement from tim was that "If you have the cloud credentials you can get in as ADMIN"06:14
jamwhich is. ok, fine. I can spend the money on the cloud, I can get into the env. Maybe not perfect, but something.06:14
jamI have $root$ on my local machine, is that enough?06:14
axwjam: ideally, although you could just as easily throw away your SSH keys06:14
axwwell maybe not *just* as easily :)06:15
axwjam: 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 password06:15
axwand any admin can change anyone elses password06:15
jamaxw: so a unix socket is how LXD does it06:16
jamso certainly there is precedent.06:16
jammight even be how mongo does as well?06:16
axwjam: 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:17
jamaxw: and certainly we have to consider that we can't be more secure in Juju than someone who can access our DB06:19
jamthey can just set the password there.06:19
* axw nods06:19
axwjam: speaking of, we should probably disallow sharing admin models with non-admins :)06:20
axwotherwise I'll just "juju deploy backdoor --to 0"06:20
jamaxw: 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:27
axwjam: ok, thanks06:28
jamcherylj: 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
jamso we have some visibility, but not a huge amount.07:06
jamwallyworld: on the downside, "juju status-history" is filled with 100 "downloading image 98%" messages.07:06
wallyworldoh joy07:06
jamwallyworld: so its super nice to see the progress in status07:07
jambut it is yet-another status-history message07:07
jamwhy hasn't my machine started yet? Because the image copy is only 70% done. great07:07
wallyworldwe should make that more usable07:07
wallyworldwanna file a bug?07:07
jamwallyworld: 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
wallyworldboth :-)07:08
jamwallyworld: what is the map in SetInstanceStatus for? I haven't seen anywhere that it ever gets set.07:14
jamIs it set from "status-set" in charm hooks?07:14
wallyworldjam: it accounds for the fact that we may want to pass some arbitary data, like for other status07:14
wallyworldwe could pass in the download percentage or something07:15
wallyworldor time remaining07:15
jamwallyworld: we can, but if nothing is touching it, exposing it, does it actually do anything?07:15
jamI guess the API would expose it?07:15
wallyworldyeah eg for juju status07:16
wallyworldthe yaml output has omitempty07:16
wallyworldthat's the way it works for normal status, i assume it's the same here07:16
jamso it is shown just not in the default format.07:16
wallyworldit's been a while since i sw the code07:16
wallyworldyes, not sown in tabular07:17
wallyworldtabular is more of a summary07:17
jamwallyworld: bugs filed07:20
wallyworldi'll try and get them done this week07:21
wallyworldthere's a similar bug about status-history spam07:21
wallyworldfor update-status calls07:21
mupBug #1557914 opened: "juju status" doesn't show machine-status messages by default <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1557914>07:22
mupBug #1557918 opened: "juju status-history" doesn't include the concept of progress messages <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1557918>07:22
jamwallyworld: yeah, it certainly feels similar to the update-status issue07:28
jamwallyworld: I wonder if a flag like "current-only" would be relevant.07:29
jamThis is a message that should be displayed, but doesn't need to be logged.07:29
wallyworldyeah, i was wondering if we needed to do that07:29
wallyworldthere's an argument though that we should store everything and filter on display07:29
jamwallyworld: that's ok, but not showing by default is the important bit.07:30
jamso that you can get the interesting bits07:30
jamwallyworld: I thought the status-history collection only stored a limited set of history, though.07:30
jamdoes it store everything always?07:30
wallyworldit's capped07:30
jamright, so that's a reason to elide them07:31
jamcause otherwise 100 "I'm almost there" messages end up pushing out the real content.07:31
wallyworlddepends on the size but yeah07:31
mupBug #1557914 changed: "juju status" doesn't show machine-status messages by default <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1557914>07:31
mupBug #1557918 changed: "juju status-history" doesn't include the concept of progress messages <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1557918>07:31
wallyworldjam: i do like the idea of a "don't log this flag". but william afaik against throwing away data07:32
wallyworldeg who cares if we ran the update status hook 100 times07:32
jamwallyworld: 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
jamI can hypothesize it, at least.07:33
jamBut *nobody* cares about something that happens more than 10-ish time07:33
jamother than gathering stats about it07:34
jamyou just can't think about it07:34
jam100 messages saying "copying"07:34
jamdid you notice it was 99 and 73% wasn't there? :)07:34
mupBug #1557914 opened: "juju status" doesn't show machine-status messages by default <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1557914>07:40
mupBug #1557918 opened: "juju status-history" doesn't include the concept of progress messages <observability> <juju-core:Triaged> <https://launchpad.net/bugs/1557918>07:40
wallyworldaxw: 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 map08:14
axwwallyworld: ok08:15
=== Guest32213 is now known as BrunoR
voidspacedimitern: frobware: stdup?10:01
perrito666wallyworld: jam reading your comment last night10:09
perrito666why dont we grow a loglevel-sh attr to status?10:10
perrito666morning all btw10:10
mupBug #1557993 opened: Can't create lxc containers with 1.25.4 and MAAS 1.9 and xenial <cross-team-kanban> <landscape> <juju-core:New> <https://launchpad.net/bugs/1557993>10:20
axwwallyworld: 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 logins10:24
perrito666axw: congrats btw10:32
jamperrito666: you mean for status-history ? yeah something like that seems valid.10:37
perrito666jam: 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 value10:39
perrito666default loglevel should be the one that gets stored in history10:39
jamperrito666: the caveat here is that we want it shown in the "juju status" content, because it is currently active dataa10:39
jamhowever, once it has expired, it isn't really worth hanging onto it/showing it by default10:40
jamwhich is a bit different interprentation of log level, where log level is not-shown-at-all10:40
perrito666jam: you mean you want to set the status and then have it dissapear?10:40
jamperrito666: I mean that when you do "juju status 0/lxd/0" you want to see "copying image: 25%"10:40
jambut when you do "juju status-history --type machine 0/lxd/0" you don't really want to see 100 lines of "copying image: 1-100%"10:41
perrito666yeah, I think we are on the same page then :)10:42
perrito666currently you call setStatus and that sets the current status and tries to push it to the history bucket too10:43
perrito666loglevel (or a better name for it) would determine if it gets pushed to history10:44
voidspacedimitern: I think I found it10:50
voidspacedimitern: the test server doesn't add interfaces to the node when you call start (a post) only on get10:51
dimiternvoidspace, ah, there it is then :) good catch10:51
voidspacedimitern: well, we'll see...10:52
wallyworldaxw: sounds awesome10:57
voidspacedimitern: yes, seems to be it11:01
voidspacedimitern: that brings me down to 23 failures, but looks like many of those have the same cause but need fixing separately11:02
dimiternvoidspace, nice - what sort of failures remain?11:03
voidspacein fact 12 of them11:03
voidspacea couple of "acces to address maas.testing.invalid not allowed11:03
voidspacebecause creating a NewEnviron actually hits the api now (to check version) which it didn't used to11:03
voidspaceso those I can fix by patching out GetCapabilities (done in other places already)11:03
voidspacea couple of bad requests which are odd but shouldn't be too hard11:04
voidspaceand a couple of 404s (also odd)11:04
voidspaceand a few "failed to allocate address"11:04
voidspaceso about four different failure cases across 23 tests11:04
voidspaceah, some of the 400s are for missing subnets11:05
voidspaceall to do with test setup I expect11:05
dimiterneven better then! we'll fix the test server11:05
voidspaceyep, I'll have a PR for this fix shortly11:05
voidspacedimitern: https://github.com/juju/gomaasapi/pull/911:26
dimiternvoidspace, LGTM11:27
voidspacedimitern: thanks11:27
voidspacethat was quick!11:27
dimiternvoidspace, I know that code all too well - it was a source of frustration :)11:28
frobwarevoidspace, dimitern: of course let's not update any dependencies.tsv in maas-spaces2... please... :)11:29
voidspacefrobware: this is needed only for my branch11:30
voidspacefrobware: I'll update dependencies there, there maybe more fixes first anyway11:30
voidspace(this is the drop-maas-1.8 branch)11:30
frobwarevoidspace: yep, just wanted to ensure we don't perturb what we have in m-spaces2. Really would like to see that branch merged today/tomorrow...11:31
voidspacewell, my branch maybe ready to land in that timeframe...11:31
voidspacewe'll do a separate CI run on this branch first though11:32
voidspacedimitern: is it correct that MAAS 1.9 supports storage, so we don't need the checks for storage support in the provider?11:34
dimiternvoidspace, I believe so - axw / wallyworld can confirm?11:35
voidspacedimitern: well, the error string is returned if the volumes aren't returned - so we still need to check that11:35
voidspaceso I think I'll leave the check and the test in place11:36
wallyworldmaas 1.9 does support storage11:36
voidspacewallyworld: thanks11:36
voidspacemaybe I should change the error message11:36
dimiternvoidspace, perhaps the test server is overly assumptive there11:37
frobwarewallyworld: ever tried backup/restore recently on maas?11:37
voidspace dimitern this is juju code11:37
voidspacedimitern: it checks the number of returned volumes and if it doesn't match expected it reports that the version of MAAS doesn't support storage11:37
dimiternvoidspace, ah, is this around select/startNode ?11:37
voidspacedimitern: I don't think we should drop that check11:37
frobwarewas trying backup/restore http://pastebin.ubuntu.com/15400937/11:37
voidspacedimitern: yeah, in startNode11:37
frobwareI could be driving this the wrong way though11:38
dimiternvoidspace, because volumes are only returned in the result of selectNode (or selectNode / acquireNode), not in the result of startNode ?11:38
voidspacedimitern: this is existing code, I'm only looking at the text of the error message :-)11:39
dimiternvoidspace, which test is that?11:41
voidspacedimitern: TestStartInstanceUnsupportedStorage11:42
voidspacedimitern: I've changed the error text to report that the incorrect number of storage volumes were returned.11:42
voidspacedimitern: instead of complaining about MAAS version11:42
voidspacedimitern: I think getting back the wrong number of volumes should still be an error11:42
dimiternvoidspace, yeah it looks like the error message is wrong11:42
dimiternvoidspace, but resultVolumes it returned by maasInstance.volumes11:43
dimiternvoidspace, and if you look at the comment around line 960 in environ.go...11:43
voidspaceyeah, I see it11:44
dimiternvoidspace, it matters which maasObject we're embedding in a maasInstance, and subsequently reading the volumes from that embedded maasObject11:44
voidspaceI'm not touching any of that11:44
dimiternvoidspace, so error message could be better indeed11:45
dimiternvoidspace, it's not about supporting spaces11:45
dimiternvoidspace, s/spaces/storage/ :)11:45
voidspacedown to 21 failures11:45
voidspaceyep, error message changed11:45
dimiternstorage code was done earlier than the spaces support, maybe even before the capability for storage was in place11:46
voidspaceI think it was being worked on when I joined11:49
frobwaredimitern: re: backup/restore, there's something similar and already reported. bug #155480711:49
mupBug #1554807: juju backups restore makes no sense <juju-core:Triaged> <https://launchpad.net/bugs/1554807>11:49
voidspacedown to 14 failures11:49
dimiterna nice title indeed :D11:49
frobwaredimitern: not sure it helps me with triaging "functional-backup-restore"11:50
dimiternfrobware, after rebasing and enabling multi-bridge creation my branch still seems to work \o/11:51
dimiternfrobware, will push and then go on with the mediawiki demo11:52
dimiternfrobware, or should I wait?11:52
frobwaredimitern: the mediawiki demo doesn't take too long to run, perhaps try that first.11:55
dimiternfrobware, +111:55
frobwaremgz: you about?11:56
fwereadeOMFG, I have been hammering on this test for *hours*, and it turns out the reason the agent isn't running the model workers it "should"? I didn't give it JobManageModel >_<12:07
jamfwereade: ouch12:27
jamwhy aren't these things starting, its right here...12:27
fwereadejam, at least the universe makes sense again :)12:27
mupBug #1557993 changed: Can't create lxc containers with 1.25.4 and MAAS 1.9 and xenial <cross-team-kanban> <landscape> <juju-core:New> <https://launchpad.net/bugs/1557993>12:50
mupBug #1558061 opened: LXD machine-status stays in "allocating". <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1558061>12:50
mupBug #1558061 changed: LXD machine-status stays in "allocating". <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1558061>12:56
mupBug #1557993 opened: Can't create lxc containers with 1.25.4 and MAAS 1.9 and xenial <cross-team-kanban> <landscape> <juju-core:New> <https://launchpad.net/bugs/1557993>12:56
mupBug #1557993 changed: Can't create lxc containers with 1.25.4 and MAAS 1.9 and xenial <cross-team-kanban> <landscape> <juju-core:New> <https://launchpad.net/bugs/1557993>13:08
mupBug #1558061 opened: LXD machine-status stays in "allocating". <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1558061>13:08
mupBug # changed: 1466100, 1498086, 1498094, 1499501, 1506869, 1506881, 1521217, 1528971, 154044713:50
mupBug #1558078 opened: help text for juju remove ssh key needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1558078>13:50
mupBug # changed: 1459298, 1463904, 1464665, 148250214:05
mupBug #1558087 opened: TestInvalidFileFormat fails on windows because of / <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core model-acls:Triaged> <https://launchpad.net/bugs/1558087>14:05
natefinchrogpeppe2: So, charmrepo depends on charmstore (for tests), and charmstore depends on charm repo.  This makes updating dependencies.tsv.... complicated.14:35
rogpeppe2natefinch: yes, it is awkward14:35
rogpeppe2natefinch: but it is possible14:35
rogpeppe2natefinch: i haven't thought of a better approach yet, unfortunately14:36
natefinchrogpeppe2: I think in order to update charmrepo to use a new version of charmstore, I'm going to need to update charmstore to use a new version of (at least) charm.v614:36
rogpeppe2natefinch: i've already fixed charmrepo to use a new version of charmstore14:36
rogpeppe2natefinch: what's the actual problem you're having?14:37
natefinchrogpeppe2: sorry, I missed your comment at the end of the PR saying you already updated the deps.  I had tried updating the deps, but I think I just got them into a bad state, which is why I was having problems.14:38
natefinchrogpeppe2: there's actually no problem, using the deps in charmrepo, the tests run fine with changes you suggested14:38
rogpeppe2natefinch: try fetch origin and rebase and see how things go14:38
natefinchrogpeppe2: yeah, just did14:38
rogpeppe2natefinch: the problem was just that the tests assumed the old charmstore semantics14:39
natefinchrogpeppe2: right14:39
rogpeppe2natefinch: BTW my most recent thinking is that the server side should include tests against the client package, with only some minimal unit tests in the client package itself.14:39
natefinchrogpeppe2: I have an interesting video I watched recently, which you'll probably totally disagree with.  It's a talk titled Integrated Tests Are A Scam - https://vimeo.com/8053353614:46
rogpeppe2natefinch: i saw your tweet and started watching, but then thought i should probably do it outside work time :)14:46
rogpeppe2natefinch: i'm interested to see what he has to say14:47
natefinchrogpeppe2: yes, probably wise :)14:47
=== rogpeppe2 is now known as rogpeppe
mgzfrobware: so, run today on maas-spaces2 looks good14:54
mgzhas only failures from ci changes to ha test14:54
mupBug #1459300 opened: Failed to query drive template: unexpected EOF <ci> <cloudsigma-provider> <juju-core:Triaged> <juju-core 1.25:Fix Released> <https://launchpad.net/bugs/1459300>14:56
frobwarecherylj: ^^14:56
cheryljmgz: what CI changes have been made?14:57
mgzwell, I assume it's that, could also be master that maas-spaces2 merged in being bad14:58
mgzeither way, it's not a maas-spaces problem14:58
frobwaremgz: could the reports include the commit IDs of any CI repos so that we could determine when things are change?15:01
katcoericsnow: hey15:03
ericsnowkatco: hi15:03
katcoericsnow: i'm working on performance reviews right now, but i read through your comments on my merge15:04
mgzfrobware: some jobs to include that, but not all I think15:04
ericsnowkatco: k15:04
katcoericsnow: i agree merges shouldn't refactor code. a lot of that came over from main, and i had to change some things to get it to compile15:04
ericsnowkatco: ah, I was wondering if that was the case15:04
katcoericsnow: maybe TAL at master and see if you would have done things differently? specifically for store.go15:05
ericsnowkatco: probably https://github.com/juju/juju/pull/462315:05
katcoericsnow: yes, exactly that15:05
ericsnowkatco: I'll take another look15:05
katcoericsnow: so anyway, with that context, lmk if that changes your review. it was not my intent to change things. i tried to keep the changes minimal15:06
ericsnowkatco: you bet15:06
katcoericsnow: ta15:06
natefinchericsnow, rick_h__: for charm publish --resource .... are we supporting bundles?  seems like if we are, we need the change how we specify resource names, to something like --resource service:resourcename-rev15:32
ericsnownatefinch, rick_h__: I recall that we weren't going to support deploying bundles with --resource args, but I don't know that we discussed publish15:33
natefinchericsnow, rick_h__, katco: yeah, I was worried we'd forgotten about that.  Seems like we kind of need to support it, otherwise bundles can't be published with charms that use resources15:35
ericsnownatefinch: the bundle metadata is what defines which resources go with each service; bundles themselves do not have resources15:37
ericsnownatefinch: so publishing a bundle with --resource doesn't have the same meaning15:37
natefinchericsnow: oh, hmm... right, so we're actually putting the specific resource revision right in the bundle15:38
ericsnownatefinch: correct15:38
natefinchericsnow: ok, that's what I was forgetting.  so, I think we don't need to support --resource on publish for bundles, since by definition, the resource revisions are already defined15:38
natefinchericsnow: good :)15:38
rick_h__natefinch: bundles don't have resources, charms do, so don't think we've got anything that does publishing15:38
ericsnownatefinch: in effect we're using the bundle to publish the revision set for each service rather than publishing that revision set directly15:39
natefinchericsnow: exactly15:39
natefinchrick_h__: yeah, I just confused myself, since I'm writing the CLI to publish with --resource flag, but the same command does bundles and charms15:40
natefinchrick_h__: I'd actually already written the "you can't do that" path... but then second guessed myself15:40
alexisbperrito666, sorry was running late15:41
alexisbon the hangoutnow15:41
katcosinzui: hey, is the curse here from bugs brought in from master? http://reports.vapour.ws/releases/375515:50
sinzuikatco: we are discussing the nature of restore failing. We suspect the issue really is in master, in which case, we have a blocker15:51
katcosinzui: ah ok =/15:51
katcosinzui: we're running out of time to land this branch... is there anything at all i can do to help?15:51
voidspacedimitern: ping15:57
natefinchOMG, my editor is converting tabs to spaces in a .tsv file :/15:58
dimiternvoidspace, pong16:01
voidspacedimitern: do you know about the maas provider and device hostnames16:01
voidspacedimitern: there is a comment in newDevice about working round the testservice requiring a hostname16:01
voidspacedimitern: and then it calls NewDeviceParams that *does not* fill in a hostname16:02
voidspacedimitern: (and so tests fail)16:02
voidspaceI can patch out NewDeviceParams to provide a hostname in the tests - but I'm going to delete that comment16:02
voidspaceor I can fix the test server to not require a hostname and to generate a random one16:02
voidspace 16:03
dimiternvoidspace, yeah, that workaround was needed because testserver required hostname to be set16:03
voidspaceI know, however the code that has that comment doesn't do it16:03
voidspaceit doesn't workaround it16:03
voidspaceso the comment is "wrong", not because the workaround isn't needed but because that code doesn't do it!16:03
dimiternvoidspace, newdeviceparams is there only to make testing the device creation a bit less awkward16:04
voidspacedimitern: ah, ok16:04
voidspacedimitern: I'll make the comment a bit more obvious16:04
dimiternvoidspace, production code does not need it otherwise16:04
voidspacethe comment just confused me16:05
dimiternvoidspace, sorry about that :/16:06
ericsnownatefinch: "internal" tests have yet again bitten me :(16:36
natefinchericsnow: doh, sorry to hear that.  How so?16:38
ericsnownatefinch: fixing a test causes an import cycle16:38
natefinchericsnow: that indicates a problem with package boundaries or the tests, generally...16:39
natefinchericsnow: though I know sometimes with our infrastructure it is unavoidable16:39
ericsnownatefinch: exacto16:39
natefinchericsnow: (though it still indicates a problem, it's often a problem that cannot be easily fixed)16:40
ericsnownatefinch: right16:40
mupBug #1558158 opened: Restore fails with no instances found <backup-restore> <blocker> <ci> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1558158>17:03
=== alexisb is now known as alexisb-afk
voidspacedimitern: sooo, we now allocate addresses using claim_sticky_ip on the device and release through the standard ip address release api17:14
voidspacedimitern: which I assume works fine in production - but doesn't work at all on the test server, they're not connected17:15
voidspacedimitern: so that requires a test server change to look on devices when releasing addresses17:15
voidspaceat the moment it 404s17:15
ericsnownatefinch, katco: PTAL: https://github.com/juju/charm/pull/200  and  https://github.com/juju/bundlechanges/pull/1917:21
ericsnownatefinch, katco: ...and https://github.com/juju/juju/pull/475817:22
natefinchheh, I was just PR 200 in the charmstore client repo17:23
ericsnownatefinch: solidarity!17:23
dimiternvoidspace, that's ok though, as we'll be using a different approach to release addresses and the AC code will go away as implemented atm17:23
natefinchyou know, sometimes I think Google has it right with a monorepo :/17:23
voidspacedimitern: yeah, but for the current tests to pass I still need to fix the test server, not difficult though17:52
voidspaceright, EOD - off to visit my Mum in hospital17:54
voidspacesee you tomorrow all17:54
mupBug #1558185 opened: juju 2 status shows machine as pending but charm is installing <juju-core:New> <https://launchpad.net/bugs/1558185>17:57
mupBug #1558191 opened: TestConstraintsValidatorUnsupported fails on go 1.5+ <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1558191>17:57
=== natefinch is now known as natefinch-lunch
=== alexisb-afk is now known as alexisb
mupBug #1558185 changed: juju 2 status shows machine as pending but charm is installing <juju-core:New> <https://launchpad.net/bugs/1558185>18:09
mupBug #1558191 changed: TestConstraintsValidatorUnsupported fails on go 1.5+ <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1558191>18:09
mupBug #1558185 opened: juju 2 status shows machine as pending but charm is installing <juju-core:New> <https://launchpad.net/bugs/1558185>18:12
mupBug #1558191 opened: TestConstraintsValidatorUnsupported fails on go 1.5+ <ci> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1558191>18:12
perrito666ashipika: you where looking for me a few days ago?18:19
frobwareanybody doing `add machine lxd:0' at the moment with xenial?18:22
frobwareI see: "Creating container: Error adding alias ubuntu-xenial: not found"18:22
alexisbjam, tych0 ?? ^^18:23
frobwarealexisb, jam, tych0, cherylj: status output, http://pastebin.ubuntu.com/15403438/18:27
frobwarealexisb, jam, tych0, cherylj: current workaround is to 'lxd-images import ubuntu --alias ubuntu-xenial xenial'18:46
frobwareon the host18:46
alexisbfrobware, great, can you please capture info in a bug18:46
katconatefinch-lunch: still at lunch? :) how's your card going?18:50
frobwarealexisb: https://bugs.launchpad.net/juju-core/+bug/155822318:52
mupBug #1558223: add-machine lxd:0 provisioning error: "Error adding alias ubuntu-xenial: not found" <juju-core:New> <https://launchpad.net/bugs/1558223>18:52
alexisbthank you18:53
mupBug #1558223 opened: add-machine lxd:0 provisioning error: "Error adding alias ubuntu-xenial: not found" <juju-core:New> <https://launchpad.net/bugs/1558223>19:00
=== natefinch-lunch is now known as natefinch
natefinchkatco: it was a late lunch :)   Was spending time mid-day working on code review comments from roger19:09
mupBug #1558223 changed: add-machine lxd:0 provisioning error: "Error adding alias ubuntu-xenial: not found" <juju-core:New> <https://launchpad.net/bugs/1558223>19:09
natefinchkatco: the card is going fairly smoothly... although I wanted to talk to people about the user-experience for charm push --resource19:10
katconatefinch: we're running out of time for that. i'd say push forward with what's already defined and we can circle back iff we have the time19:11
katconatefinch: keep in mind... day after tomorrow is our deadline19:11
natefinchkatco: that's fine.  mostly just wanted people to be aware that charm push --resource is just going to be syntactic sugar around charm push + charm push-resource (i.e. they're separate calls to the charmstore)19:12
mupBug #1558223 opened: add-machine lxd:0 provisioning error: "Error adding alias ubuntu-xenial: not found" <juju-core:New> <https://launchpad.net/bugs/1558223>19:13
katconatefinch: what's your eta for the remainder of the work?19:13
natefinchkatco: I can get the current review comments finished and charm push --resource proposed today, but there's no one from the UI team to review the latter until tomorrow morning19:14
katconatefinch: i think rick_h__ believes in some kind of "code fairy" ;)19:15
katcowho might merge for us19:15
ericsnowkatco: didn't happen last time I needed the code fairy :)19:15
natefinchkatco: as long as the code fairly also keeps roger from strangling us ;)19:15
katcoericsnow: you must not really believe19:15
katcoericsnow: clap harder!19:15
rick_h__katco: :p can always asj for a merge command if review is ok19:16
katconatefinch: yeah, i'd just advise you to pick your battles here this close to a deadline19:16
natefinchkatco: definitely trying to go with the flow to just get'er'dun19:16
katcorick_h__: i think the issue is more that we don't have final sign-off from someone in the ui team19:16
urulamaalso, we're tagging CS with v4.5 today, release tomorrow, so, em, have that in mind :)19:17
katcorick_h__: if only someone were around who used to work closely with the ui team and had the authority to sign off. and loved campers and photography.19:17
natefinchbecause they like to "sleep" at "night"19:17
rick_h__katco: understand.19:17
katcourulama: grats on impending release! :D19:17
urulamacs-client is part of that for the moment19:18
urulamaso, em, all PRs that are not needed for that release will not be landed anyway19:18
urulama(as i suspect they don't have the equivalent functionality covered in the uitests)19:18
katcourulama: as long as we can get the changes in by friday, we're fine19:19
urulamaand i apologise, the fairies were kidnapped by en evil witch from the south19:19
urulamakatco: np, it's unlocked as soon as it get's tested and tagged19:20
katcourulama: cool. well gl to your team19:20
mupBug #1558232 opened: ERROR cannot obtain bootstrap information: Get Unable to connect to: <juju-core:New> <https://launchpad.net/bugs/1558232>19:25
urulamanatefinch, katco: wait ... charm push --resource? what's with charm attach-resource?19:25
katcourulama: change in direction from mark19:25
katcourulama: he wants push-resource to be attach-resource19:25
natefinchurulama: and charm push --resource is just a way to skip a step and do it all at once19:26
natefinchurulama: so push up the charm and the resources for it19:26
urulamawas aware of attach-resource, not about charm push --resource ;)19:26
urulamaok, sgtm19:26
urulamanatefinch: is this your PR? https://github.com/CanonicalLtd/charmstore-client/pull/20019:28
urulamanatefinch: i mean, the one you want to land?19:28
natefinchurulama: yes19:29
natefinchurulama: though it needs a few suggestions from code reviews implemented19:30
natefinchwhich is what I'm doing now :)19:32
urulamaok, if you don't get review tonight, i'll point them to it in the morning19:32
rick_h__katco: just attach, no -resource19:32
natefinchurulama: thanks19:33
katcorick_h__: what happened to the whole 2.0 <verb>-<noun> edict?19:33
niedbalskiperrito666, http://paste.ubuntu.com/15403845/ , I can't bootstrap on lxd using master/head. Any known issues?19:33
rick_h__katco: it went with deploy, bootstrap, and such.19:33
rick_h__katco: i'm not 100% on it but i pushed attaxh-resource and was shot down.19:34
katcorick_h__: hm. ok. natefinch ^^^19:34
natefinchrick_h__: so, juju attach django website=./site.zip ?19:34
perrito666niedbalski: I honestly dont know19:34
rick_h__natefinch: yes19:35
natefinchrogpeppe: okie dokie19:35
natefinchrick_h__: ok :)19:35
* urulama thinks you've awaken the dragon 19:35
* natefinch ducks19:36
* rogpeppe swoops in19:36
* rogpeppe ignores the puny humans19:36
alexisbrick_h__, are there other places we would use the word "attach"19:38
alexisbI see danger in leaving it just attach with out the -resource19:39
katcoalexisb: rick_h__: what we've been doing is having <verb>-<noun> with an alias of <verb> if there's not conflict19:40
alexisbwell <none?19:40
natefinchkatco: or <noun> in the case of resources :)19:40
natefinchaka list-resources19:40
alexisbso for example list-storage is the same as storage19:40
katcoalexisb: natefinch: ah, yes.19:41
natefinchkatco: at least we're consistently inconsistent ;)19:41
alexisbbut rick_h__ is right that there are cases where we use just the verb19:41
alexisblike bootstrap19:41
katcoalexisb: i think the case there is that they are fundamental juju concepts, not substrates19:41
alexisbbut bootstrap is boothstrap - one case19:41
rick_h__alexisb: right, I tried to argue against but we had some verb patterns and mark was taken with the idea of "email attachments"19:42
rick_h__alexisb: the only other thing I could think for 'attach' was attach a storage device, or some sort of device19:43
rick_h__alexisb: but we don't use it currently and then if attach is established in this fashion the others will have to be something else19:43
frobwaretych0: ping19:47
katcorick_h__: i think i understand where mark is coming from, but i'm struggling with this: what delineates commands that should be <verb>-<noun> from those that should just be <verb>?19:47
rick_h__katco: well there's the ambigious vs non-cases19:47
rick_h__katco: any verb that can apply to more than one think (list-) rightly needs to be more to it19:47
alexisbwe may not need them now but we could later19:49
katcorick_h__: does that make it true that we can't have any other attach commands until a 3.0 to not break backwards compatibility?19:49
rick_h__attach-storage was the only one I was worried about. I don't think of attach in the network space or in models19:49
urulamabut those are not for charm management, right19:49
katcorick_h__: alexisb: yeah, this ^^^19:49
katcourulama: there is a juju attach as well19:49
rick_h__katco: no, it just means they'd need to be attach-XX worst case, and it'll be confusing so we'd look for a different work19:49
katcorick_h__: i think that's a different way saying "can't have any other attach commands"19:52
rick_h__katco: :)19:52
katcorick_h__: when the team heard attach, the first thing we thought of was storage19:53
ericsnowrick_h__: aren't we going to be doing unit-shared filesystems or something like that?19:53
rick_h__ericsnow: yes, shared filesystems19:53
rick_h__ericsnow: but what's to say that's not 'mount' or the like?19:53
ericsnowrick_h__: "attach" would make much more sense there19:53
rick_h__ericsnow: it's just hard to not use something because you *might* use it later. There's some cases but there's options.19:53
* rick_h__ is trying to look at the commands/think through19:54
ericsnowrick_h__: if I see "juju attach" I am not going  have enough context to know what that is19:54
rick_h__ericsnow: it's because resources are new19:54
rick_h__ericsnow: as natefinch's command shows, it's more obvious with the full command19:54
katcorick_h__: that is chicken and egg though ;)19:54
ericsnowrick_h__: at long as "attach-resource" is a valid command19:55
katcorick_h__: you would only have the full command if you knew what attach was19:55
mupBug #1558239 opened: [LXD provider] Cannot bootstrap using Xenial container <docteam> <juju-core:New> <https://launchpad.net/bugs/1558239>19:55
natefinchcan we still have attach-resource as an alias?19:55
natefinchor vice versa19:55
katconatefinch: that's backwards imo19:55
natefinchI want attach-resource in juju help commands19:55
natefinchI guess that's attach-resource with attach as an alias19:55
natefinchthat way if you want to upload a resource, you do juju help commands, and it's obvious19:56
rick_h__the issue is the only aliases now tend to be the list-XXXX ones.19:56
rick_h__we've killed off most other aliases, there's a couple that need cleanup still. /me tries to find the list from before19:56
ericsnowrick_h__: FWIW, the obvious command is "juju upload-resource"19:56
natefinch^^^^ +10019:56
natefinchbut I'm not Mark :)19:56
rick_h__ericsnow: heh, yea that didn't work either.19:57
rick_h__ericsnow: natefinch katco so an alias is a no go. It'll be a precedent setter in that sense. THe other ones are either due to list- or plurals.19:57
* rick_h__ has to hop on a call, but I think we have to go with attach for now and we'll suffer the consequences later. attach-resources is too long, and attach hasn't been used in storage/networking to date and I think we'll have other options when/if we get there. 19:58
rick_h__and when I'm wrong, everyone gets free sprint beverages and gets to say "I told you!" :)19:59
natefinchrick_h__: I'm just sad that juju help commands | grep resource  is not gonna show the very first command you'd want to use with a resource19:59
natefinchrick_h__: I guess that's not true... the description will probably use the word resource19:59
ericsnownatefinch: +119:59
rick_h__natefinch: sure it will, juju help commands has a text string on it that'll say resource in the string19:59
rick_h__natefinch: I thought of that and went and checked it in another terminal here :)20:00
natefinchattach     uploads a resource to the controller/charm store  :/20:00
natefinchrick_h__: me too ;)20:00
natefinchheh... actually juju help commands | grep resource shows some ambiguous usage of the word resources20:01
natefinchdestroy-controller     terminate all machines and other associated resources for the juju controller20:02
rick_h__natefinch: yea, should clean that up20:02
* natefinch adds a line to an export_test.go and feels shame20:03
tych0frobware: pong20:06
frobwaretych0: I was looking at juju/worker/provisioner/lxd-broker.go and noticed this:20:10
frobwarefunc (broker *lxdBroker) StartInstance(args environs.StartInstanceParams) (*environs.StartInstanceResult, error) {20:10
frobwareif args.InstanceConfig.HasNetworks() {20:10
frobwarereturn nil, errors.New("starting lxd containers with networks is not supported yet")20:10
frobwaretych0: how significant is that?20:11
tych0frobware: i don't know :)20:11
tych0frobware: what is a "network" in this context?20:11
frobwaretych0: I think this is a red-herring as I know you can have multiple networks in a profile - this looks juju-only to me right now20:12
frobwaretych0: where networks in multiple interfaces20:13
frobwaretych0: don't worry about this ... since my original ping I don't think is a genuine problem on the lxd side of things.20:14
tych0frobware: oh, i see20:35
tych0you mean like juju isn't rendering things to LXD?20:36
frobwaretych0: yes, but a known issue. that's up next. I was just walking through the details and saw that comment.20:36
tych0ok, cool20:37
tych0if you have any questions about how to do the actual translation, let me know20:37
=== natefinch is now known as natefinch-afk
mupBug #1542206 opened: space discovery still in progress <ci> <juju-core:Triaged> <juju-core maas-spaces2:Fix Released> <https://launchpad.net/bugs/1542206>21:28
mupBug #1542206 changed: space discovery still in progress <ci> <juju-core:Triaged> <juju-core maas-spaces2:Fix Released> <https://launchpad.net/bugs/1542206>21:34
mupBug #1542206 opened: space discovery still in progress <ci> <juju-core:Triaged> <juju-core maas-spaces2:Fix Released> <https://launchpad.net/bugs/1542206>21:37
mupBug #1548813 changed: maas-spaces2 bootstrap failure unrecognised signature  <ci> <maas-provider> <juju-core:Invalid> <juju-core maas-spaces2:Fix Released by mfoord> <https://launchpad.net/bugs/1548813>22:07
mupBug #1554584 changed: TestAddLinkLayerDevicesInvalidParentName in maas-spaces2 fails on windows <ci> <test-failure> <windows> <juju-core:Invalid> <juju-core maas-spaces2:Fix Released by dimitern> <https://launchpad.net/bugs/1554584>22:07
mupBug #1556116 changed: TestDeployBundleMachinesUnitsPlacement mismatch <ci> <gccgo> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Invalid> <juju-core maas-spaces2:Fix Released by frobware> <https://launchpad.net/bugs/1556116>22:07
anastasiamac_cmars: master is blocked waiting for a fix to 1558087. I saw ur comment on the bug saying that u r waiting for master to b unblocked..23:03
anastasiamac_cmars: could u plz try Fixes-bug blah merge message to land ur fix?23:03
menn0cmars: great that rog has seen the same bakery issue23:04
anastasiamac_cmars: actually - never mind \o/23:21
davecheneyping, https://github.com/juju/juju/pull/4749 needs a second review23:49
perrito666davecheney: ship it23:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!