[11:48] <rick_h_> morning
[13:32] <frankban> guihelp: I need reviews + QA for a quick branch: https://github.com/juju/juju-gui/pull/626
[13:32] <kadams54> frankban: checking
[13:32] <frankban> ty
[13:55] <kadams54> guihelp: I need a QA on a WIP: https://github.com/juju/juju-gui/pull/625 - no need for a review yet.
[13:55] <rick_h_> frankban: able to peek at ^ ?
[14:05] <frankban> rick_h_: sure
[14:32] <rick_h_> hatch: around?
[14:32] <hatch> yeah sorry just having technical issues 
[14:32] <hatch> almost back up
[14:32] <rick_h_> hatch: oh party
[14:33] <hatch> apple quality and all that
[14:33] <rick_h_> hah
[14:34] <hatch> ok good enough
[14:34] <hatch> wassssuuupppp:
[14:34] <hatch> ?
[14:34] <rick_h_> hatch: I want demo url calls to the gui from your branch to put into the card to update the storefront
[14:34] <rick_h_> hatch: and then wondered if your branch was ok to land then?
[14:34] <hatch> I am still fighting with some tests but the code is stable
[14:35] <rick_h_> hatch: ok, can you give me a sample bundle and charm url to put into the card for the other guys?
[14:35] <hatch> so we could land it as is
[14:35] <hatch> yup
[14:35] <hatch> sec
[14:35] <rick_h_> nah, tests need love too. Take your time
[14:35] <rick_h_> just want to make sure I've got the work laid out 
[14:35] <hatch> ?text=apache&deploy-target=bundle:elasticsearch/15/cluster
[14:35] <hatch> ?deploy-target=cs:precise/apache2-25
[14:36] <hatch> the first one shows that it's also functional with other query params
[14:36] <hatch> top one bundle, second charm
[14:37] <rick_h_> ty much
[14:48] <kadams54> frankban: thanks for the QA!
[14:48] <frankban> kadams54: np, looking at the code now
[14:52] <rick_h_> jujugui call in 10 kanban please
[14:54] <jcastro> rick_h_, 
[14:54] <rick_h_> jcastro: party
[14:54] <jcastro> for tags, in the metadata.yaml, is it "tag: foo, bar, baz" or "tags: foo, bar, baz"
[14:54] <jcastro> writing up the docs for tags now
[14:54] <rick_h_> jcastro: exact same as categories
[14:54] <rick_h_> just s/categories/tags
[14:54] <jcastro> ok but tags with an s right
[14:54]  * rick_h_ double checks
[14:54] <jcastro> that's what I wanted to doublecheck
[14:55] <rick_h_> jcastro: yes, with an s
[14:58] <jcastro> how do you want people to define multiple ones
[14:58] <jcastro> commas or a list like we do with categories?
[14:58] <rick_h_> a list is great
[14:59] <jcastro> ok, one more question, how do I explain freeform?
[14:59] <jcastro> do I say "also feel free to just make up your own but these are the default ones" or something?
[14:59] <rick_h_> I thought we weren't doing freeform atm
[14:59] <rick_h_> just starting with the white listed set and others would be ignored
[15:00] <jcastro> ok
[16:39] <hatch> how the heck do I change the time in Ubuntu? lol When I change it in the time control panel it never changes it just stays at the old value
[17:25] <hatch> Webstorm 9 sure has some awesome looking features for FE/js dev
[17:25] <hatch> not sure I want yet another IDE
[17:25] <hatch> though
[17:35] <hatch> oh our test suite
[17:35] <hatch> AssertionError: expected { opt1: 'opt1default' } to equal { opt1: 'opt1default' }
[18:30] <rharper> Hi Folks,  I heard that there was a tool that would take a bundle yaml file and generate a png juju-gui style with the charm icons and relations  -- anyone here heard of that ?
[18:37] <rick_h_> rharper: https://github.com/juju/jujusvg is the work in progress. It's not 100% ready yet
[18:38] <rharper> rick_h_: cool, thanks!
[18:38] <rick_h_> rharper: but it's what we want to build out to do that
[19:15] <marcoceppi> rick_h_: tags. Are they going to be in metadata or only in the charm store?
[19:16] <rick_h_> marcoceppi: in the metadata
[19:16] <rick_h_> marcoceppi: s/categories/tags in the metadata done
[19:16] <marcoceppi> why
[19:16] <rick_h_> marcoceppi: well, except for the list of tags we support
[19:16] <rick_h_> marcoceppi: huh?
[19:16] <marcoceppi> well, if it's living in the metadata why even bother renaming
[19:17] <marcoceppi> secondly, it totally shouldn't live in the metadata at all, to add a new tag I have to rev the charm
[19:17] <marcoceppi> seems so silly
[19:17] <rick_h_> because it's added to bundles and the naming in the UI is tags now so the idea is to use a consistent term from UI, bundle.yaml, and metadata.yaml
[19:17] <rick_h_> marcoceppi: ok, but when you fork a charm does a tag still apply?
[19:17] <rick_h_> marcoceppi: so when you fork/push we want those to carry through so having them in the metadata makes sense
[19:17] <marcoceppi> I was hoping we could use tags for additionaly bits
[19:18] <rick_h_> 'additionaly bits'?
[19:18] <marcoceppi> additional bits
[19:18] <marcoceppi> god I wish I can remember who I was talking to who said this was going to live in store
[19:18] <rick_h_> marcoceppi: so tags turn into clickable searches in the UI
[19:19] <rick_h_> marcoceppi: so the idea is tags are a more fleshed out category idea that's limited at first to a sec of approved 'searches' and over time we'd allow more freeform when we can help guide users like stackoverflow tags
[19:19] <rick_h_>  s/sec/set
[19:19] <rick_h_> I'm not sure what 'additional bits' you were thinking?
[19:19] <marcoceppi> right, so tags and question edits are decoupled
[19:20] <marcoceppi> editing a tag on a question does not rev the question
[19:20] <rick_h_> marcoceppi: understood, but you also don't fork a question and want to keep the tags on the followup
[19:20] <rick_h_> marcoceppi: I can see it both ways, the way we're going for helps one case vs the other. 
[19:20] <rick_h_> marcoceppi: we can look at adding tags as live updatable metadata, we've got longer term plans for that, description/etc in the future
[19:20] <rick_h_> marcoceppi: but for now, they're in the metadata.yaml
[19:21] <marcoceppi> had I known this was the course of action I would have been more vocal about it earlier
[19:21] <marcoceppi> oh well.
[19:22] <rick_h_> marcoceppi: sorry man, we can look at things after the fact, but days before launch is a bit short to rethink it. 
[19:23] <rick_h_> marcoceppi: if there's a communication lesson we can learn from this please let me know. 
[19:23] <marcoceppi> I know it is, I'm just sad I misunderstood the change
[19:23] <marcoceppi> and wanted to clarify before making changes to charm proof
[19:33] <jrwren> marcoceppi: was it me? an admin can put any metadata one wants in the store in a place we call extra-info
[19:42] <rharper> rick_h_: looking at the jujusvg repo,  I need to write out that simple go program from the readme to have it generate the svg?
[19:44] <rick_h_> Makyo: can you help rharper put together a quick something to try out using the jujusvg stuff? ^
[19:45] <Makyo> rharper, correct.  jujusvg is meant to be a library - something can read a bundle and pass it to NewFromBundle and receive an SVG in return.
[19:46] <rick_h_> Makyo: I've rharper it's not quite ready yet as a cli tool, but if you can help him put together a pastebin script with a couple of steps to try it out that'd be great. 
[19:46] <rharper> yeah, that'd be very helpful
[19:47] <Makyo> rharper, rick_h_ Sure, let me pull something together real quick.
[19:48]  * rick_h_ goes afk for a bit
[19:56] <hatch> jujugui looking for reviews and qa on https://github.com/juju/juju-gui/pull/624 thanks
[20:19] <Makyo> rharper, https://gist.github.com/makyo/3a5e4428dc2351115a26 I've pulled together a sample program that uses the jujusvg library and a sample bundle that you can run that program on.  You should be able to type `go get -u -v -t github.com/juju/jujusvg/...` then `go run 00-svg-test.go` and as long as bundle.yaml is in the same directory, it should build the SVG for you.
[20:20] <rharper> Makyo: very coo;
[20:22] <hatch> Makyo:  got a second to join a chat?
[20:22] <Makyo> rharper, the readme on jujusvg is out of date, it appears.  I'll update that.
[20:22] <Makyo> hatch, surew
[20:22] <hatch> in standup
[20:23] <rharper> Makyo: yeah, was just hacking through that looking at the svgjuju test.go 
[20:23] <rharper> when I put my openstack bundle through it, it says, at least one service must be specified ... any idea what that means?
[20:24] <rharper> Makyo: this is my bundle: http://paste.ubuntu.com/8631892/
[20:27] <Makyo> rharper, it looks like this was generated by hand, or at least without the GUI.  Since it does not have position annotations, jujusvg will, by default, stack the services on top of each other.  The GUI uses a circle-packing algorithm to position services without position annotations, but jujusvg doesn't yet know how to do that
[20:27] <rharper> Makyo: ok, I have another that I exported fro juju gui and it says the same thing
[20:28] <rharper> http://paste.ubuntu.com/8631918/
[20:29] <rharper> Makyo: that last one, I can export from gui, import back into gui fine, but running on the svg tool says
[20:29] <rharper> 2014/10/22 15:29:25 Error generating canvas: cannot verify bundle: at least one service must be specified
[20:31] <Makyo> rharper, ahah, there is work currently in the GUI to export a bundle without the old "basket" syntax.  You can fix that simply in the bundle.yaml file by removing the top-level yaml node (env-export) and dedenting everything once below it.  There's a sea-change on how bundles are handled throughout the juju ecosystem
[20:31] <rharper> ok, lemme try that
[20:33] <rharper> Makyo: that fixed it, but the icons aren't there (viewing svg via eog) 
[20:33] <rharper> just the lines
[20:34] <Makyo> rharper, try with $BROWSER; the svg renders the icons as images with references as URLs, so it will only work with internet-aware viewers
[20:34] <rharper> yeah, I see that
[20:34] <rharper> interesting
[20:34] <Makyo> In the future, we may include the icon SVGs when possible as SVG <ref>s, though that will make for a very big SVG
[20:34] <rharper> Makyo: nice
[20:35] <rharper> any way to get the service name too ?
[20:36] <Makyo> rharper, not yet, unfortunately.  jujusvg is pretty new.
[20:36] <rharper> ok
[20:39] <rharper> Makyo: yeah, would be nice to have it handle the current jujugui export (ie, throw away the top level to find services), write the service name;  and since I'm asking for ponies, emit out a png so I can put these in slides and other stuff showing the bundles off.
[20:39] <rharper> Makyo: thank you for putting that together quickly, that helps
[20:39] <hatch> PONIES!!!
[20:40]  * hatch might land an easter egg in the GUI in which a pony walks across the screen 
[20:40] <Makyo> rharper, np.  For the first part, jujugui will start exporting the new format $soon (hatch, right?), and the PNG work will be coming up $later, as we'll be adding the ability to email a bundle with a preview png
[20:40] <rharper> very nice
[20:41] <hatch> Makyo: there is a new export format? :)
[20:41] <Makyo> hatch, I thought that was part of the work for Ben, may be wrong.
[20:41] <Makyo> I'll go back to my code cage, if so.
[20:42] <hatch> Makyo: ohh that was to support multiple relation endpoints on a single endpoint
[20:42]  * Makyo goes back to code cage u.u
[20:42] <hatch> lol
[20:42] <Makyo> hatch, just means getting rid of the 'env-export' top level YAML node
[20:43] <hatch> ohh - yeah i'd love to get rid of that
[21:23] <hatch> jujugui I stll need some reviews and qa on https://github.com/juju/juju-gui/pull/624 
[21:59] <huwshimi> Morning
[23:31] <rick_h_> morning huwshimi 
[23:31] <huwshimi> rick_h_: Hey :)