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