[00:18] wallyworld: does anything need to change in core for the addition of resources to the bundle metadata? [00:19] ericsnow: the native bundle deployment code i would expect [00:19] there will be changes to upstream repos bundlechanges and charm as well [00:20] wallyworld: where is the native bundle deployment code? are you talking about cmd/juju/service/bundle.go? [00:20] yeah [00:20] wallyworld: k === natefinch-afk is now known as natefinch [01:33] The program 'i' is currently not installed. You can install it by typing: [01:33] sudo apt-get install iprint [01:33] who does shit like this ?!? seriously [01:33] \o/ well that's a milestone. I just triggered a migration and the model was successfully serialised and imported into the target controller. [01:33] still lots to do though [01:36] menn0: nice! [01:36] w00t [01:36] next big milestone is to get the agents to switch over to the target controller [01:38] menn0: that should be the easy part, right? [01:42] natefinch: maybe slightly easier... [02:01] wallyworld: http://reviews.vapour.ws/r/4163/diff/ [02:02] looking [02:02] wallyworld: no test, because it involves the filesystem + raciness. could test if we moved setting current controller to jujuclient, but I think that's not a worthwhile use of time right now [02:03] axw: could you add a todo before landing? [02:04] menn0: nice work :) is model migration doing any per-provider post-migration steps? something I brought up with thumper before, is that the hosted models in azure use resources in the controller resource group [02:04] menn0: so if they're moved to a separate controller, each controller will need to run some code to move things about [02:04] wallyworld: sure [02:05] axw: yep, that's been thought of (as per your conversation with thumper) [02:05] axw: I can't remember if it's in place yet (I *think* it is) but it's definitely getting done [02:05] menn0: cool [02:05] menn0: BTW, there's a new "controller-uuid" config attr that applies to all providers now [02:06] fairly new [02:06] Bug #1557102 changed: Cannot unregister from a controller

[02:06] Bug #1557124 changed: Controller is orphaned for remotely registered user

[02:06] axw: what's that for? [02:07] menn0: it's used by azure only atm. azure needs the uuid to identify the controller resource group [02:11] axw: ok cool. [02:32] mna, github.com/juju/cmd has a ton of assumptions about how it'll be used that make it really ugly to unit test [02:39] Bug #1557216 opened: MADE-model-worker stale master

[02:39] Bug #1557254 opened: Move current-controller management to jujuclient

[02:39] Bug #1557264 opened: feature-resources is too stale to test

[02:55] axw: do you have a minute to discuss add-credentials? standup hangout? [02:55] wallyworld: ok, just getting a drink, brt [03:10] can someone tell me I'm doing something wrong here, please? trying to do a juju deploy --to lxc:# I get an error [03:10] ERROR adding new machine to host unit "ubuntu/0": cannot add a new machine: machine 0 cannot host lxc containers [03:10] this is using xenial with juju 1.25.3 on canonistack-lcy02, but the same thing happens with maas [03:12] wallyworld: actually, USSO probably doesn't fit into accounts.yaml. they're not controller-specific. [03:12] wallyworld: unless we store things not keyed by controller in there too? [03:12] axw: i was thinking we might [03:12] if it is juju related [03:13] easier to manage for the user, less droppings all over their machine [03:13] wallyworld: it's a bit overloaded though. an account currently means "a user in a controller" [03:13] fair point [03:13] axw: i think we need to see what the total surface area of this stuff is going to be and make a call when we know fully what we're dealing with [03:45] wallyworld, hey, thanks for the reviews on 4131. if you're ok with http://reviews.vapour.ws/r/4131/diff/6-8/, i'll go ahead and land it in model-acls [03:45] pushed those after your last review [03:46] wallyworld, also, is there a good shining example of a BaseSuite test that sets up an APICaller for api client tests I could cheat off of? [03:47] cmars: one quick thing that i see - can we code isGreaterAccess() to do the right thing with read/write/admin upfront? [03:47] should be minimal extra effort [03:47] cmars: with the apicaller thing - i thought the tests were all correctly set up and you simply needed s/JujuConnSuite/BaseSuite . if not then leave for another pr [03:48] wallyworld, i'm hesitant to actually define the ModelWriteAccess until we actually implement it [03:48] wallyworld, however, i think we're forward compatible with such a change when we're ready to make it [03:48] wallyworld, ^^ state.ModelWriteAccess, that it [03:49] wallyworld, i'd like the state to reflect reality, which is, you're either read-only, or full-blown admin [03:49] wallyworld, that way, when we do add more nuanced access values, they match existing state [03:49] make sense? [03:50] cmars: sort of. so right now, if we happen to save "AccessWrite" in to state for a user. that isGreaterAccess() will fail if new access is "admin" [03:50] isn;t that a trap we can easily avoid? [03:52] wallyworld, do you mean if we added state.ModelWriteAccess? because right now, that value is not defined in state. [03:52] wallyworld, the state package doesn't give callers the language to phrase such a condition (unless you went and casted arbitrary strings to state.ModelAccess) [03:54] wallyworld, i think when we do make the distinction between "write" and "admin", we'll need to then improve the logic in the apiserver/modelaccess [03:54] ok. fair enough. maybe a todo next to where the constants are defined that if a new one is added, gp and update isGreaterAccess()? i'll leave to you to do or not [03:54] wallyworld, +1 for a TODO, i was on the fence about that [03:55] cmars: for the api example, cmd/juju/storage/add__test.go (assuming you can't just drop JujuConnSuite for BaseSuite with no other changes). if it's not that easy change, do in another pr so as not to block this work [04:05] wallyworld, my command tests use mocks like that, but I need to mock an apiserver to test the api client. [04:06] cmars: ah, right sorry, let me get another example [04:07] cmars: see "apiCaller := basetesting.APICallerFunc(" in juju/api/storage/client_test.go [04:09] wallyworld, awesome. yep, that's what I needed! [04:10] great :-) [04:10] go and cargo cult that sucker [04:37] wallyworld: got a minute? [04:38] sure [04:39] wallyworld: I was looking at the channel code... it still looks like roger & co are ignoring the CharmRepo wrapper, so channels aren't getting added to those interfaces [04:40] wallyworld: for example: https://github.com/juju/charmrepo/pull/71/files [04:40] looking [04:42] Bug #1557302 opened: juju and jujud have grown to >100MB [04:43] natefinch: it may be time to pull CharmStore into core and look at what's needed moving forward - maybe we only need the extra header attrs it allows us to add when querying revision information; maybe we use csclient directly for most everything else? [04:43] maybe we extra the caching stuff and use where needed [04:43] extract [04:44] separate to the use of the client itself [04:45] wallyworld: I actually like the wrapper, so the command code doesn't have raw calls to client.Put(some_Url) in it... so those are all consolidated in the helper library [04:46] wallyworld: I'm fine if csclient is that wrapper... I just don't want to ever see wallyworld: I shouldn't ever see client.Put("/"+id.Path()+"/publish", val) outside one API wrapper library... [04:46] oops, ignore that second wallyworld in the middle.. copy paste error :) [04:47] np, agree with not using the low level stuff directly [04:47] so i guess core is the only place using the CharmStore wrapper [04:48] hence it's going to be up to us to maintain it. it would be easier to do that if it were in core [04:50] it seems wise to have it outside of core, in case other tools want to use the same cache... however, maybe we should be focusing on putting non-caching commands right on csclient [04:52] natefinch: depends on the semantics i think. do you have a list of the commands we need to add that core needs? [04:54] wallyworld: ListResource, GetResource, UploadResource... and I made a Publish method so the CLI code wouldn't have to hardcode the url in it. [04:57] natefinch: so comapring what's there on csclient.Client for charms - we have UploadCharm() and UploadBundle(). I guess we use Meta() for a list type operation? and Get(path) for getting charms? [04:58] actually GetArchive() [04:58] is used to get a charm i think [04:58] either a charm or bundle [04:58] yeah [04:58] natefinch: so adding thise resource methods to client seems ok doesn't it [04:59] wallyworld: yep [04:59] ok, sgtm [04:59] wallyworld: ok, cool [04:59] thanks for thinking it through [04:59] wallyworld: np [05:15] ok, I'm done. g'night all [07:21] axw: ping? [07:22] menn0: pong [07:22] axw: would you mind taking a looking at this one? http://reviews.vapour.ws/r/4169/ [07:22] axw: it's trivial [07:23] sure [07:23] axw: and should help get a bless for the MADE-state-workers branc [07:24] menn0: LGTM [07:24] axw: thanks [08:33] mgz: ping, are those errors spurious? http://reports.vapour.ws/releases/3751 [08:33] mgz: (and morning) [09:10] Bug #1557380 opened: help text for juju add-ssh-key needs improving

[09:17] dimitern: ping, 1:1? Can skip if you're busy and sync later. I'm currently merging master again. [09:21] frobware, hey, sorry got carried away [09:21] frobware, but I'm close to getting multi-nic working [09:23] dimitern: then I will NOT disturb you. \o/ :) [09:27] :) cheers [10:10] morning o/ [10:18] frobware: actually, I have coffee and some motivation - will crack on now and take a break later [10:19] frobware: need to make a decision how to have the gomaasapi test server support 1.x *and* 2.x [10:19] frobware: obviously the urls have the api version in them and the test server does have a version field [10:19] frobware: but in terms of code structure [10:20] frobware: branching inside every method isn't ideal but maybe the path of least resistance [10:20] frobware: changing the server to an interface and having two implementations would be painful as the server have lots of fields and they would all need accessor methods [10:32] voidspace: at first blush having a branch seems easier, at least initially. You can always revise a little as you see how things pan out. [10:33] frobware: heh, so the first problem is the change to the capabilities output [10:33] frobware: but calling "version" from the maas command line is broken (I've filed a bug) [10:34] frobware: so having to write gomaasapi code to see the output of the version api call (that gets us the capabilities) [10:34] voidspace: sweet [10:38] frobware: dimitern: so, if we're dropping support for maas < 1.9 there are two choices [10:39] frobware: dimitern: detect the unsupported version early and error out [10:39] frobware: dimitern: or just assume we're on a supported version [10:39] frobware: dimitern: I assume the first option is preferable [10:39] voidspace, I think we should report an error [10:39] dimitern: yep [10:39] voidspace: as 1.8 is around, drop out early. [10:39] yeah, cool [10:40] dimitern: so, supportsDevices, supportsStaticIPs and supportsNetworkDeploymentUbuntu can all go away [10:40] and NewEnviron can just do a version check [10:41] frobware: it looks like it might be cleaner to do that first [10:42] voidspace, yeah - either NewEnviron or even at lower level - getMAASClient [10:43] dimitern: that method just returns the client, which is created in SetConfig, which is called from NewEnviron [10:44] dimitern: and NewEnviron already does the capabilities checks [10:44] dimitern: so replacing the capabilities checks with a version check in NewEnviron seems sensible [10:46] voidspace, sounds good, yeah [10:46] dimitern: the client does need to change as we need to switch between 1.0 api and 2.0 api depending on maas version [10:49] dimitern: hah, however - you need to know the maas api version in order to be able to ask maas which version it is... [10:49] dimitern: if you call /api/1.0/version/ on a 2.0 server you get "null" back [10:50] dimitern: shall I report a bug for that do you think? they ought to have an api version independent version endpoint [10:56] voidspace, yes please, that should be a bug - i.e. maas should report a sensible error for /api/1.0/ requests [11:34] Bug #1557470 opened: juju reads from wrong streams.canonical.com location

[11:37] dimitern: frobware: old code removed, 50 additions and 653 deletions [11:37] dimitern: frobware: it compiles, but tests need checking & fixing [11:37] satisfying though [11:38] https://github.com/juju/juju/compare/maas-spaces2...voidspace:drop-maas-1.8?expand=1 [11:38] voidspace: nice [11:46] Bug #1557470 changed: juju reads from wrong streams.canonical.com location

[11:49] voidspace, nice, but that's going into a feature branch first, right? [11:50] dimitern: why not land it? [11:50] dimitern: long lived feature branches are a pain [11:51] voidspace, well, there's a lot to clean up, but doing now will make my life a little hell :/ [11:51] with all the changes I'm making for multi-nic [11:51] dimitern: so you'd rather make my life hell merging yours instead... [11:52] voidspace, nope, I'd rather drop the legacy code later and just disable it for now ? [11:52] if your changes conflict there's hell for someone... [11:54] voidspace, I will happily deal with the conflicts, just if possible I'd like to do that next week [11:54] dimitern: fine [11:54] I don't mind dealing with them either :-) [11:54] someone has to do them [11:54] it should just be deleting more code [11:54] dimitern: I really loathe long lived feature branches though and it has become our standard way of working [11:55] down to 38 test failures :-/ [11:55] 108 were panicing a minute ago, so that is progress [11:55] Bug #1557470 opened: juju reads from wrong streams.canonical.com location

[11:58] dimitern: how close are you to maas-spaces2 tip? (on your feature branch) [11:59] dimitern: seem to have lots of unit test failures today [11:59] dimitern: and the last CI run was way worse than I expected [12:00] frobware, not so close anymore [12:01] frobware, 5 days behind [12:01] dimitern: which coincides with when I started merging master. hmm. [12:15] dimitern, voidspace: I think we'll need to set 'juju_bridge_all_interfaces=1' to 0 in maas-spaces2. We made this 0 on master to make tests pass, but they will of course continue to fail on maas-spaces2. Can I suggest that if you need multiple bridges you set this explicitly in your feature branch until we have everything in place. [12:16] frobware, sounds good [12:29] dimitern, voidspace: http://reviews.vapour.ws/r/4172/ [12:29] hopefully as easy as it gets [12:29] frobware, LGTM [12:31] dimitern: would you please merge my goose package? I lack super powers [12:32] perrito666, doesn't $$merge$$ work there? [12:40] Bug #1556483 changed: ERROR invalid config: no addresses match [12:41] dimitern: iirc, last time I tried to merge the bot did not respond to me [12:48] perrito666, now it did - but the tests failed [12:49] * perrito666 goes check what happened [13:04] dimitern, voidspace: master merge, http://reviews.vapour.ws/r/4173/ [13:13] frobware, looks good [13:13] dimitern: thanks for the review [13:14] dimitern: so, devices... next :) [13:15] frobware, I have lxc working locally [13:15] well a bit unstable and only with lxc-clone: false, but still [13:16] dimitern: sounds interesting; want to sync before I go grab some lunch? [13:16] one more live test and I'm pushing what I have to my PoC branch [13:16] frobware, sure [13:18] frobware, standup HO [13:18] omw [13:54] dimitern: well, that's weird. the master merge was quite flaky running the unit tests locally, but passed first time on the CI machines. [13:55] frobware, I guess CI is rock solid then :) [13:56] dimitern: brings new meaning to "Ship It!" [13:57] :D [13:59] Bug #1557540 opened: Missing help for payloads [14:10] dimitern: would you give me another little push? :) I still lack the credentials to command merge bot (the error was because the patch was against liberty but proposed against v1, I fixed that) [14:11] Bug #1557540 changed: Missing help for payloads [14:13] perrito666, sure - done [14:13] tx [14:17] Bug #1557540 opened: Missing help for payloads [14:21] natefinch: ericsnow: hey [14:22] katco: yo [14:22] katco: we should get together and point those cards in our iteration backlog [14:23] ericsnow: yes, unfortunately i cannot talk still [14:23] katco: :( [14:24] ericsnow: natefinch: also, unfortunately mark did not like push-resources. he wants it to be "attach-resources" [14:24] frobware, pushed the changes so far - https://github.com/juju/juju/compare/maas-spaces2...dimitern:maas-spaces2-multi-nic-lxc [14:24] frobware, lxc now works [14:24] katco: k [14:24] frobware, tried with 2 on the same machine, now will try a few more [14:25] dimitern: will take a look in a bit, just looking at the brokeness of maas-spaces2 [14:26] dimitern: but really cool though! \o/ [14:27] frobware, yeah :) \o/ [14:28] frobware, there's 2m delay at boot due to the cloud-init-nonet :/ but otherwise seems to work once only the primary NIC has a gateway set in both /e/n/i and lxc.conf [14:29] dimitern: very nice. congrats! [14:30] frobware, thanks :) we all deserve a pat on the back [14:30] katco: lol.. well, at least command name changes are trivial [14:30] natefinch: yeah [14:30] frobware, I'll start splitting of chunks of that branch and propose them against maas-spaces2 [14:31] dimitern: are you considering just the state changes, or more? [14:31] katco: are you tackling merging master into feature-resources? (bug #1557264) [14:31] Bug #1557264: feature-resources is too stale to test

[14:32] ericsnow: i can definitely take care of that [14:32] frobware, state changes definitely, and some stuff in networkingcommon [14:32] katco: suh-weet [14:32] frobware, but the other bits need better testing [14:33] rick_h__: so i think the last loose-end on resources is the progress indicator for fetching resources [14:33] katco: ok, did you look at the current output locations and see if we can fit anything in place on the existing tabular output? [14:34] katco, natefinch: FYI, http://reviews.vapour.ws/r/4160/ [14:35] rick_h__: we talked about maybe having it under "juju list-resources --details" [14:36] rick_h__: probably not in an existing column, but maybe a new section [14:36] katco: do you have sample output we can peek at please? [14:36] rick_h__: let me cook one up [14:37] katco: ty [14:44] alexisb: see progress on multi-NIC from dimitern ^^ [14:44] rick_h__: possibly this: http://pastebin.ubuntu.com/15392044/ [14:46] voidspace: this looks so much better now "has interface addresses: [local-cloud:10.17.20.215@default(id:0) local-cloud:192.168.10.102@internal(id:1) local-cloud:192.168.12.102@db(id:3) local-cloud:192.168.11.102@public(id:2)" - thanks! [14:46] dimitern, very very cool! [14:47] alexisb, cheers :) === urulama_ is now known as urulama [14:52] katco: looking [14:53] katco: can we also track upload progress on local ones? [14:54] rick_h__: isn't that kind of strange since the CLI will block when uploading? [14:54] rick_h__: you'd have to flip to a new terminal and do a watch [14:54] it's a lot easier than tracking progress on unit downloads [14:55] katco: I assume he just means have the CLI output progress indications while it blocks [14:55] katco: thoughts on http://paste.ubuntu.com/15392141/ [14:55] natefinch: no, I mean if I were in another terminal or another user I'd see that status [14:55] rick_h__: ah i didn't think about the multi-user implications [14:56] rick_h__: what happens when we do "deploy --resources"? does that status show up as well? [14:56] rick_h__: personally, I would find it very weird for other people to be notified when you're uploading a file. systems don't generally do that... it's just either not there or it's there [14:56] rick_h__: urulama, hatch, perrito666: for instance, this is the current unit info from master's megawatcher: http://pastebin.com/U51reeY4 (just FYI) [14:56] natefinch: but that's what I'm asking, if you do it when getting a file from a remote location, why not a local location? [14:57] natefinch: it's kind of the same thing to a second user "this thing is updating and in progress..." [14:57] rick_h__: urulama, hatch, perrito666: so I guess we'll need to fetch what we need from AgentStatus and WorkloadStatus [14:57] rick_h__: you would still see the download progress for a local resource... the upload is to the controller, not individual units [14:57] perrito666: is AgentStatus going to be renamed there as well? [14:57] rick_h__: so you wouldn't see an upload progress, but you would still see a download progress [14:57] katco: ok, so download would be from the controller down, fiar enough [14:58] frankban: gimme a moment and ill be with you [14:58] katco: ok, what are folk's thoughts on the in-line? [14:58] rick_h__: there's two different transfers, from charmstore/local to controller, and from controller to unit. I had only been thinking of updates on the latter. [14:58] rick_h__: the "REVISION" heading seems kind of strange to me now [14:58] katco: yea, it says it's downloading rev9, we know that ahead of time right? [14:58] rick_h__: as in "what revision? downloading" [14:58] ditto... it's already overloaded [14:59] rick_h__: yes, through the same mechanism we'll have to provide progress [14:59] rick_h__: we first know about the metadata: rev, size, fingerprint, and then we download [14:59] katco: right, ok so it's not completely out of place and why I made sure ot keep the revision info in the fetching messagfe [14:59] rick_h__: the thing is, then you lose information about what that unit is actually running right now, since it's not running 9 right now, it's running whatever it downloaded previously [15:00] natefinch: true, but it's for some download window of time. Is it significant? [15:00] natefinch: and I'd expect the yaml/json status to be full details [15:00] rick_h__: is the progress indicator significant, by that measure? :) [15:00] natefinch: e.g. different fields [15:01] rick_h__: also keep in mind it'll be this for downloading uploaded resources: http://paste.ubuntu.com/15392199/ [15:02] natefinch: rgr, /me goes into call will slow down replies [15:02] rick_h__: personally, I find it really hard to read having all that extra data embedded in that column. I'd much rather have a separate section like katco proposed [15:02] so first of all, frankban hatch urulama https://github.com/juju/juju/blob/juju-1.26-alpha1/state/status_model.go#L272 [15:03] that was the old translate function [15:04] frankban: urulama, hatch second, the change of agent-status -> juju-status is meant to be only a presentation thing, just user facing, internally we still hold the names that make sense for the internal juju terminology, so my first intuition would be to say that it will remain agent-status unless someone disagrees [15:05] perrito666: I don't really understand the 'juju-status' key in UnitStatus but ok :) [15:06] perrito666: cool, I agree [15:06] the logic doesn't 'look too complex so that's good :D [15:07] rogpeppe1: I see a lot of calls like client.Put("/"+id.Path()+"/meta/perm/read", []string{params.Everyone, id.User}) ... how come you guys aren't wrapping that stuff in helper methods on charmrepo/csclient.Client? [15:07] perrito666: but FYI in the current master mega-watcher units have AgentStatus and WorkloadStatus, machines have JujuStatus and MachineStatus :-) [15:07] natefinch: we could do, yeah [15:07] perrito666: so is this going to stay like that? [15:08] hatch: so, the differentiation between juju-status and workload-status is because the former shows information about the juju agent and the later about the charm [15:08] natefinch: feel free to add PutId, SetPerm etc [15:08] frankban: aghh, then expect it to change to juju-status wil be consistent there [15:09] perrito666: for beta3? and what about Workload vs Machine? [15:09] natefinch: it's always a trade-off between adding useful methods and adding a helper method for every single endpoint in the store [15:09] natefinch: i'm not sure the maintenance burden of the latter is worth it [15:10] frankban: workload and machine remain the same, agent changes to juju, hopefully in a couple of hours tops [15:10] rogpeppe1: I would call a helper for every single endpoint in the store useful :) As someone writing a CLI client, I really don't ever want to have to know what HTTP method I should be using.. someone should have wrapped that stuff away in a helper library, IMO. [15:10] natefinch: especially given the way that so much of this stuff can be combined in arbitrary ways with the bulk endpoints [15:10] perrito666: ok so units will have JujuStatus and WorkloadStatus, machines will have JujuStatus and MachineStatus? [15:11] natefinch: the way i look at it is the HTTP API really is the API - the client library is a thin (and not opaque) layer above it [15:13] correct [15:13] perrito666: ok, do you also have the conversions functions used for StatusInfo and StatusData? [15:13] natefinch: my issue is that the other sectino isn't meaningful without trying to match unit/resource name in the first section so I find it hard to process. [15:15] frankban: passthrough unless there is error in workload status, there we would show the error message in info iirc [15:15] but I dont recall where it was [15:15] rogpeppe1: I see what you're saying... but I think the client code is a lot easier to read and understand when I see client.Publish(id, channels, resources) rather than client.Put("/"+id.Path()+"/publish", params.PublishRequest{Channels: channels, Resources:resources}) === mhilton-lunch is now known as mhilton [15:16] natefinch: as i said, it's a trade-off [15:16] natefinch: there are hundreds of endpoints [15:16] natefinch: well... lots anyway [15:16] natefinch: and thousands of potential combinations [15:16] perrito666: so StatusInfo was the error message and StatusData is current WorkloadStatus? [15:18] natefinch: ok, so 60+ endpoints [15:18] natefinch: i think that having a reasonable grasp of the HTTP API saves quite a bit of work overall [15:19] perrito666: so I think old StatusInfo was WorkloadStatus.Message [15:19] frankban: the exact name was StatusInfo ? [15:19] rogpeppe1: maybe for you, not so much for me ;) [15:19] perrito666: and old StatusData was AgentStatus.Data [15:20] frankban: so, now I remember [15:20] StatusData was AgentStatus.Data [15:20] perrito666: I think the old logic is in https://github.com/juju/juju/blob/juju-1.26-alpha1/state/allwatcher.go#L294 [15:20] StatusInfo was AgentStatus.Message [15:21] natefinch: come on, that call isn't hugely much more verbose than client.SetPerm(id, channels, resources) [15:21] frankban: yes, that was the conversion done, when error we did something different otherwise we would just agentStatus fields [15:21] perrito666: I see, let me try to formalize that [15:23] natefinch: katco http://paste.ubuntu.com/15392403/ please [15:23] natefinch: katco I think that's the best of both worlds as close as I can think up atm [15:26] Bug # changed: 1553298, 1553299, 1553303, 1553308 [15:27] katco, natefinch, rick_h__: perhaps we can go with something in the middle: http://pastebin.ubuntu.com/15392433/ [15:28] ericsnow: the thing is the extra column that comes/goes I think is bad for cli imo. Maybe I'm wrong on that front. [15:28] rick_h__: i agree [15:28] ericsnow: and I do think that the YAML has to have the data spelled out as it's machine data [15:28] rick_h__: I'd agree if we expected folks to be parsing the tabular output [15:29] ericsnow: right, but some folks will do simple "status | grep | xxx" [15:29] ericsnow: vs parsing the yaml/json [15:29] ericsnow: it's some ux principal i can't remember: don't have elements of the ui appear/disappear based on state [15:29]