| === 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 | ||
| lazyPower | rick_h_: ping | 13:41 |
|---|---|---|
| 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:42 |
| lazyPower | namely the num_units on subordinates which will cause a failed deployment :( | 13:43 |
| rick_h_ | lazyPower: looking | 13:43 |
| 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:46 |
| 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:47 |
| 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:48 |
| rick_h_ | lazyPower: https://github.com/juju/charmstore/issues/358 will track there | 13:49 |
| lazyPower | Thanks rick! Appreciate the hustle | 13:50 |
| 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:53 |
| 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:54 |
| 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:55 |
| === urulama_ is now known as urulama | ||
| urulama | lazyPower: do we have a list of bundles that are demoed and need to be fixed? | 13:58 |
| lazyPower | urulama: i dont, but let me follow up and try to get a list for you | 13:59 |
| urulama | lazyPower: ty! | 13:59 |
| rogpeppe | rick_h_: interesting bug, thanks | 14:39 |
| 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:40 |
| 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:41 |
| rogpeppe | rick_h_: i think this means we'll need to move to charm.v6 | 14:44 |
| 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:45 |
| 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:46 |
| rick_h_ | rogpeppe: right, and that's a good thing to have | 14:47 |
| rogpeppe | rick_h_: yup | 14:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| rick_h_ | rogpeppe: we have a work around atm, but the bug remains/needs to be corrected longer term | 14:51 |
| urulama | +1 | 14:51 |
| 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:16 |
| rick_h_ | lazyPower: they both seemed to be related to exporting uncomitted? | 18:21 |
| rick_h_ | lazyPower: ok if I combine them? | 18:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| rick_h_ | mbruzek: ah ok, had to zoom in ty | 18:26 |
| 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:32 |
| 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:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| rick_h_ | if it was deployed into a real env it would look at what your juju env default is | 18:40 |
| mbruzek | rick_h_: I was just kidding, understand it is just a demo | 18:41 |
| rick_h_ | mbruzek: all good | 18:41 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!