[13:41] <lazyPower> rick_h_: ping
[13:42] <rick_h_> lazyPower: pong
[13:42] <lazyPower> Greetings, are we doing some post processing on bundle ingests? I see a big diff between whats in repo vs whats in the store:  https://api.jujucharms.com/charmstore/v4/~kubernetes/bundle/kubernetes-cluster-2/archive/bundle.yaml http://bazaar.launchpad.net/~kubernetes/charms/bundles/kubernetes-cluster/bundle/view/head:/bundles.yaml   
[13:43] <lazyPower> namely the num_units on subordinates which will cause a failed deployment :(
[13:43] <rick_h_> lazyPower: looking
[13:46] <rick_h_> lazyPower: how's the deployment being done? 
[13:46] <lazyPower> rick_h_: clicking "add to canvas" on the demo site
[13:46] <rick_h_> lazyPower: right...ok. filing bugs. when the bundle is transposed to the new format that's getting added and it shouldn't. 
[13:47] <rick_h_> rogpeppe: urulama ^
[13:47] <lazyPower> ack. I figured it was something new - thanks for taking a look
[13:47] <rick_h_> urulama: that came up during the roadshow with sabdfl, breaking the demos. 
[13:47] <rick_h_> urulama: It appears to be that transpose of .orig to bundle.yaml
[13:47] <urulama> rick_h_: great!
[13:48] <rick_h_> urulama: filing a bug on the charmstore atm, will be high priority since all the tools were updated to use the bundle.yaml vs the orig so it's broken by default for everyone
[13:49] <rick_h_> lazyPower: https://github.com/juju/charmstore/issues/358 will track there
[13:50] <lazyPower> Thanks rick! Appreciate the hustle 
[13:53] <rick_h_> lazyPower: sorry we broke that on you. We'll try to get it right asap but will probably be a bit. 
[13:53] <rick_h_> lazyPower: for now, the work around is to get the yaml file https://api.jujucharms.com/charmstore/v4/~kubernetes/bundle/kubernetes-cluster-2/archive/bundles.yaml.orig
[13:53] <rick_h_> lazyPower: and use that directly as it's the correct format/file
[13:53] <lazyPower> i dont think we have a mechanism to do that on the demo site 
[13:54] <rick_h_> lazyPower: not sure if we can go the old drag/drop route or somethin to twist the demo to work asap
[13:54] <rick_h_> lazyPower: right, I mean download the yaml file and go the drag/drop route vs the search/add to demo button. 
[13:55] <urulama_> lazyPower: so, the num_units = 1 is not supposed to be there, right
[13:55] <lazyPower> urulama_: correct
[13:55] <lazyPower> num_units should be blank, as teh charm is a subordinate. Subordinate charms do not allocate machines
[13:55] <rick_h_> urulama: correct, subordinates can't have a num_units as the number is determined by the service they're related to
[13:58] <urulama> lazyPower: do we have a list of bundles that are demoed and need to be fixed?
[13:59] <lazyPower> urulama: i dont, but let me follow up and try to get a list for you
[13:59] <urulama> lazyPower: ty!
[14:39] <rogpeppe> rick_h_: interesting bug, thanks
[14:40] <rogpeppe> rick_h_: i'll just check, but i'm not entirely sure whether the bundle translation code is in a position to know if the charms are subordinates or not
[14:41] <rogpeppe> rick_h_: actually, the better solution is just to not add num_units if it's 1
[14:41] <rick_h_> rogpeppe: true, but we have to find a way. 
[14:41] <rick_h_> rogpeppe: +1
[14:44] <rogpeppe> rick_h_: i think this means we'll need to move to charm.v6
[14:45] <rogpeppe> urulama, mhilton: ^
[14:45] <rick_h_> rogpeppe: wheeeeee
[14:45] <rick_h_> rogpeppe: but why charm if it's doing it in bundle ingestion?
[14:45] <rogpeppe> rick_h_: the charm package does bundles too
[14:45] <rick_h_> rogpeppe: I guess I had hoped it was something in the ingestion/translation code that could be adjusted
[14:45] <rick_h_> rogpeppe: ah, gotcha
[14:45] <rogpeppe> rick_h_: the problem is that the current bundle code treats a missing num_units field as meaning 0
[14:46] <rick_h_> rogpeppe: k
[14:46] <rogpeppe> rick_h_: we *could* interpret 0 as meaning 1, but there's no way to do that and still allow a service with 0 units
[14:47] <rick_h_> rogpeppe: right, and that's a good thing to have 
[14:47] <rogpeppe> rick_h_: yup
[14:48] <rogpeppe> rick_h_: i think this probably also means we need to reingest all bundles
[14:48] <rick_h_> rogpeppe: we'll need some form of migration. Now the migration could check is_subordiante over the api though
[14:48] <rick_h_> rogpeppe: to self-heal vs reingest, but we can see if reingestion has any side effects we don't like
[14:48] <rick_h_> have to think it through
[14:48] <rogpeppe> rick_h_: the migration has to happen inside the charm store.
[14:49] <rick_h_> rogpeppe: it could be an external function? api to just update the bundle.yaml once the charm page upgrade is through.
[14:49] <rick_h_> I don't see why the migration has to happen in the CS?
[14:49] <rogpeppe> rick_h_: i guess if we're happy with it updating the latest revision of the bundle only
[14:49] <urulama> rick_h_: was thinking the same thing ... but then sha is not correct
[14:50] <urulama> rick_h_, rogpeppe: we bump bundle revision
[14:50] <urulama> which should be ok
[14:50] <rick_h_> since the bundle.yaml is not in the source tree we can just bump it
[14:50] <rick_h_> without caring it's not in sync with the original bzr tree
[14:50] <rogpeppe> rick_h_: as a temporary fix, could we just change the deployer to ignore num_units on subordinates?
[14:50] <rick_h_> rogpeppe: deployer, gui, quickstart...
[14:50] <rick_h_> update all the tools vs 1
[14:51] <rick_h_> rogpeppe: we have a work around atm, but the bug remains/needs to be corrected longer term
[14:51] <urulama> +1
[18:16] <lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1446789
[18:16] <mup> Bug #1446789: Exporting an un-committed bundle results in broken bundle <juju-gui:New> <https://launchpad.net/bugs/1446789>
[18:16] <lazyPower> https://bugs.launchpad.net/juju-gui/+bug/1446788
[18:16] <mup> Bug #1446788: Build-a-bundle appears broken in firefox on jujucharms.com <juju-gui:New> <https://launchpad.net/bugs/1446788>
[18:16] <lazyPower> found a couple corner cases
[18:21] <rick_h_> lazyPower: they both seemed to be related to exporting uncomitted?
[18:21] <rick_h_> lazyPower: ok if I combine them?
[18:22] <lazyPower> sure
[18:22] <lazyPower> i dont think one is related to the other though - beleive the behavior of exporting an uncommitted bundle = that format
[18:22] <lazyPower> and the commit button is a side-effect of some recent change according to the console
[18:23] <lazyPower> but i'll follow along in any case and offer re-testing for validation :)
[18:23] <rick_h_> lazyPower: oic, one is pressing the export button and one is hitting the commit button?
[18:23] <lazyPower> correct
[18:23] <mbruzek> rick_h_: correct
[18:23] <lazyPower> i probably worded them poorly - sorry
[18:24] <rick_h_> lazyPower: what's the subordinate?
[18:24] <lazyPower> rick_h_: kubernetes in this case
[18:24] <rick_h_> and the other one is the -master one?
[18:25] <mbruzek> kubernetes-master is a regular one
[18:25] <rick_h_> ok
[18:25] <rick_h_> lazyPower: mbruzek is there a relatoin on the subordinate?
[18:25] <mbruzek> rick_h_: yes
[18:26] <rick_h_> mbruzek: ah ok, had to zoom in ty
[18:32] <rick_h_> mbruzek: lazyPower can you guys add which relations are made so we can dupe/test it out please? I see a couple of options
[18:33] <lazyPower> rick_h_: on 1446788
[18:33] <lazyPower> ?
[18:33] <rick_h_> lazyPower: yes please. something is broken as the changes roll out, and trying to dupe it I see a few diff relations options as I link across
[18:35] <lazyPower> ack, i'm goign to paste a reference bundle that has everything we were attempting in the gui
[18:35] <rick_h_> lazyPower: rgr that'll work ty
[18:36] <lazyPower> updated
[18:36] <rick_h_> <3 ty lazyPower 
[18:36] <mbruzek> Hey rick_h_ we just were able to import that bundle in the GUI demo
[18:37] <mbruzek> But we were not able to "build" that bundle from the GUI demo 
[18:37] <mbruzek> charm by charm
[18:37] <mbruzek> in firefox
[18:37] <rick_h_> mbruzek: right, so when you build a bundle we have to turn things from temp names 'new machine 1' into a real juju name/reference 'machine 13'
[18:37] <rick_h_> and so my guess is that something raced or didn't update properly as the list of changes rolled out
[18:38] <rick_h_> so duping to find out where the service reference got lost
[18:38] <mbruzek> OK
[18:38] <rick_h_> mbruzek: while deploying the bundle bypasses that uncomitted/list of changes work 
[18:38] <mbruzek> rick_h_: When I imported a bundle with series == trusty, when I exported it, all is as expected, EXCEPT the series got converted to precise.
[18:38] <mbruzek> rick_h_: bug or no?
[18:38] <rick_h_> mbruzek: because the demo defaults to being precise for the purpose of the demo
[18:39] <mbruzek> rick_h_: OK
[18:39] <mbruzek> no bug it is, just seems fishy, like the GUI knows better than I do!
[18:39] <rick_h_> it's the fun of riding the fine line of a tool that lives in an environment and one that can be run without
[18:40] <rick_h_> if it was deployed into a real env it would look at what your juju env default is
[18:41] <mbruzek> rick_h_: I was just kidding, understand it is just a demo
[18:41] <rick_h_> mbruzek: all good