=== lp|conference is now known as lazyPower === alexpilotti_ is now known as alexpilotti [18:25] How do I get bundles from the charm store [18:25] api* [18:26] https://api.jujucharms.com/v4/openstack-telemetry/31/archive/bundle.yaml doesn't seem to work? [18:26] no alterations seemt to work either [18:27] go damnit [18:27] https://api.jujucharms.com/v4/bundle/openstack-telemetry-31/archive/bundle.yaml [18:28] why is this `juju quickstart openstack-telemetry/31` not `juju quickstart openstack-telemetry-31` [18:39] marcoceppi: because we're working on making the commands match the urls. We can't do it fully with juju deploy until juju 2.0 [18:40] marcoceppi: so there's a mix of -rev vs /rev in things that are 'old juju' vs 'future juju' [18:40] rick_h_: so which URL will be the one we use? [18:40] marcoceppi: /revision [18:40] marcoceppi: the direction we have is name [18:40] name/series [18:40] name/series/revision [18:40] because this seems like an API thing, I'd expect openstack-telemetry/31/acrhi/.. [18:41] the revision will be diff for series [18:41] e.g. only 5th one in ubuntu but 10th one in windows [18:41] marcoceppi: so it's restful resource where each /segment/ adds another layer of specificity [18:41] well series is a charm notion, not really a bundle issue [18:42] marcoceppi: true enough, sorry I read "acrhi/" as 'architecture' [18:42] right, but the URL in quickstart is a / but the api is a - [18:42] marcoceppi: yes, the api was made to work with current juju, quickstart is trying to set the tone for the forward looking when we moved to new bundles. [18:42] marcoceppi: honestly, if I had my way the api would be / as well [18:42] marcoceppi: but I lost that battle and it'll change in v5 when we get juju 2.0 [18:42] wish it was the same as the / [18:43] I've got to write a lot of additional code to support this now :( [18:43] marcoceppi: how so? [18:43] marcoceppi: what are you up to, maybe there's an easier way to handle it? [18:43] well there's like 20 diffrent bundle urls that could exist [18:43] marcoceppi: from where? [18:43] bundle: was used at one point, then cs:bundle/name-rev now there's just bundlename/rev [18:44] We're adding support to Google's PerfKit to be able to deploy benchmark bases with Juju [18:44] marcoceppi: what are you testing/checking this in? [18:45] marcoceppi: so you're checking for a user input to see if that's a bundle string? [18:45] yes [18:46] * rick_h_ looks at code real quick [18:46] I've got a few bugs to file against the store page, if I try to highlight just the URL portions it highlights the entire quickstart string which is annoying from a user perspective, but that's just a ux papercut [18:49] marcoceppi: k, what you're doing is done here: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/quickstart/models/bundles.py#L121 [18:49] marcoceppi: not sure if it's feasible to reuse that or not directly, but that handles the different cases for users in our use [18:50] rick_h_: thanks [18:50] marcoceppi: https://github.com/juju/juju-bundlelib/blob/master/jujubundlelib/references.py#L47 might be a better more reusable thing [18:50] marcoceppi: you can see that quickstart is using that to help figure stuff out based on hints in the string [18:51] marcoceppi: but I see you pain point there and agree, but the goal is trying to get to just 'juju deploy xxx' and xxx could be openstack-base [18:51] marcoceppi: and everything 'just works' and we're on the road there but we're not able to shift it all at once without juju 2.0 and yet don't want to hold up and stick to the older urls until we get there. [18:51] marcoceppi: if there's somedthing we can do to help make it less painful please let us konw [18:52] rick_h_: having a consistent URL until everything switches would be my +1, tbh [18:52] "this state until juju 2.0" might as well be forever [18:52] marcoceppi: right, but we had to make some changes to get jujucharms.com out the door, and having qujickstart match the site you copied the quickstart command from made sense [18:53] marcoceppi: it's getting closer, we're working on bundles into core right now and by Oct should have juju deploy $quickstart value in there before EOY [18:53] I disagree, but it's subjective [18:53] cool, that's exciting to hear [18:53] marcoceppi: understand [18:54] as soon as bundles can be deployed from juju API, the better [18:54] marcoceppi: yea, the juju-bundlelib is getting prepped for core integration by getting ported to core here: https://github.com/juju/bundlechanges [18:54] marcoceppi: so what we'll be working on is to embed the gui in juju core itself, we need juju core to know how to do a bundle deployment, so juju-bundlelib is going to get integrated into the juju api [18:54] marcoceppi: so I understand your pain, but we are moving forward as best we can. [18:55] rick_h_: are you guys rewriting juju-gui to golang? [18:55] marcoceppi: no, but the juju-gui will be only html/JS/css and all the extra bits will be moved into juju core [18:55] rick_h_: AH, cool, very neat [18:55] marcoceppi: right now the juju gui charm does some things in python (like handle bundles) and those have to diaf [18:55] marcoceppi: so when there's a juju release, it'll have a gui JS that the juju state server can serve out [18:56] marcoceppi: so every juju bootstrap, will have a 'juju gui' cli command that will open the gui on that state server [18:56] sweet, hot, action [18:56] marcoceppi: so honestly, juju-quickstart will probably get deprecated along the way, or at least do a heck of a lot less [18:57] marcoceppi: but fyi, all this will only be v4 bundles so we'll be working on a v3 bundle deprecation notice in the next week here. [18:58] as updating core to support multiple formats/etc is going to be out of scope so we can get it moved forward faster. [18:58] see http://blog.jujugui.org/2015/08/13/bundles-bundles-bundles/ [18:58] rick_h_: sure, we're pretty cool with v4 format. However, what about storage and networking in bundles? [18:59] marcoceppi: good question. No one's currently stepped up to update the format and we're working on porting existing work. Once that's good we can look at expanding it [18:59] marcoceppi: but it'll have to be after we get current stuff working and integrated. [19:00] marcoceppi: once we get it in place I could see getting more core folks involved and maybe making it a requirement for landing new features, but it's not been brought up/etc as we've just started the owrk since annecy [19:00] rick_h_: ack, our team is going to have a big requirement for at least storage soon, as soon as it goes GA [19:01] marcoceppi: yea, understand. Just a case of only so much at a time can be done with the stuff on everyone's plate :/