[01:57] <wallyworld> anastasiamac: pretty please http://reviews.vapour.ws/r/3459/
[02:02] <anastasiamac> wallyworld: looking :D
[02:09] <wallyworld> ty
[02:12] <wallyworld> anastasiamac: commeted
[02:13] <wallyworld> hopefully it makes sense
[02:13] <anastasiamac> wallyworld: looks awesome \o/ thank u - shipited it
[02:13] <anastasiamac> :D
[02:13] <wallyworld> yay :-) ty
[02:33] <menn0> axw: ship it
[02:33] <axw> menn0: cheers
[02:34] <menn0> axw: of course, now I see that wallyworld beat me to it
[02:34] <menn0> oh well... double ship it
[02:34] <axw> :)
[02:50] <wallyworld> anastasiamac: CI should run structured metadata tests shortly, let's keep fingers crossed
[02:52] <wallyworld> axw: anastasiamac: new laptop arrived :-D will be offline for a bit to swap hard drive and stuff
[02:52] <axw> wallyworld: excellent. enjoy
[02:52] <wallyworld> i will :-D
[05:36] <natefinch> axw: are you familiar with this test? https://github.com/juju/juju/blob/controller-rename/featuretests/cmd_juju_controller_test.go#L118
[05:36] <axw> natefinch: nope, maybe waigani or menn0
[05:37] <axw> both of whom are probably EOD now ...
[05:38] <natefinch> weak
[06:32] <waigani> axw hey, sorry I was having dinner
[06:33] <axw> waigani: no problem, I don't think anybody expects you to work through dinner ;)
[06:33] <waigani> heh
[06:34] <waigani> axw is there something up with that test?
[06:35] <axw> waigani: no idea, sorry. all I know is that natefinch wants to know about it :)
[06:35] <waigani> oh right, hehe, I mis read comment - thought you were looking for me
[06:36] <waigani> and he's gone - oh well. tomorrow is another day. He can catch me then.
[07:54] <axw> anastasiamac: FYI, https://github.com/juju/juju/pull/4042
[07:58] <anastasiamac> axw: looking :D
[09:16] <mattyw> good morning juju
[09:20] <TheMue> good morning mattyw
[09:20] <mattyw> TheMue, hey hey! You don't belong here ;)
[09:20] <mattyw> TheMue, happy new year mate, how's it going?
[09:21] <TheMue> mattyw: it's a public channel, I'm still interested, so I never left :)
[09:21] <TheMue> mattyw: happy new year to you too.
[09:22] <mattyw> TheMue, very happy to have you around, how's erlang?
[09:22] <TheMue> mattyw: technology at new job is fine, but the team is totally missing any kind of process or common habbits like iterations, retrospectives, reviews, etc.
[09:23] <TheMue> mattyw: it's a fight to push it into the right direction
[09:23] <mattyw> TheMue, that's awesome - gives means you can implement it the way it should be done :)
[09:23] <TheMue> mattyw: got aware how good we're doing the job here at juju
[09:36] <voidspace> dimitern: you really need to run the git pre-push hooks
[09:36] <voidspace> dimitern: there's a Warningf call with no formatting directive on maas-spaces tip...
[09:37] <dimitern> voidspace, oh is there..
[09:37] <voidspace> dimitern: corrected it in the branch I'm about to merge (the one you reviewed yesterday
[09:37] <voidspace> dimitern: :-p
[09:37] <dimitern> yeah I was meaning to set up the hook
[09:37] <voidspace> :-)
[09:38] <dimitern> at least now with the new laptop I have no excuse like before - everything's much faster
[09:38] <voidspace> cool
[09:39] <voidspace> dimitern: your first comment on this review: http://reviews.vapour.ws/r/3457/
[09:40] <voidspace> dimitern: "please fix the imports grouping" - it looks to me like the grouping is correct
[09:40] <voidspace> dimitern: non juju/juju in one group and juju/juju separately
[09:40] <voidspace> ah
[09:40] <voidspace> dimitern: no - juju/testing is wrong
[09:40] <voidspace> dimitern: never mind
[09:48] <mup> Bug #1531444 opened: azure: add public mapping of series->Publisher:Offering:SKU <juju-core:Triaged> <https://launchpad.net/bugs/1531444>
[09:51] <mup> Bug #1531444 changed: azure: add public mapping of series->Publisher:Offering:SKU <juju-core:Triaged> <https://launchpad.net/bugs/1531444>
[09:53] <dimitern> ah, so I did have pre-push hook, but the symlink was broken in .git/hooks/
[09:53] <voidspace> heh
[09:53] <voidspace> that doesn't help
[09:53] <dimitern> now I have it on and it did catch that warning
[09:54] <mup> Bug #1531444 opened: azure: add public mapping of series->Publisher:Offering:SKU <juju-core:Triaged> <https://launchpad.net/bugs/1531444>
[09:56] <dimitern> voidspace, dooferlad, frobware, when you have some time, I'd appreciate a review on http://reviews.vapour.ws/r/3462/
[09:56] <dimitern> it might be easier to also look at the PR's individual commits
[11:43] <dooferlad> dimitern: https://github.com/juju/charm/pull/186 -- I hope this is what you wanted!
[11:44] <dimitern> dooferlad, cheers, looking
[11:44] <dimitern> uh oh "No description provided."
[11:47]  * dimitern is surprised Storage .. `yaml: ",omitempty"` works for "storage: ..."
[11:47] <dimitern> I thought only bson lowercases the field names
[11:49] <dooferlad> I think json and YAML parses both convert to lowercase on output and interpret lowercase as Title Case on input. Haven't tested it though. Not sure if all-caps becomes all lowercase.
[12:00] <dimitern> dooferlad, reviewed
[12:00] <dimitern> and please, add a PR description
[12:01] <dimitern> e.g. describing the added section with an example YAML excerpt?
[12:03] <dimitern> dooferlad, also, adding cards + PR link for that PR and the following 2 would be great
[12:05] <dooferlad> dimitern: reviewed your pull request. Basically, I am on a TODO needs a bug or card quest at the moment.
[12:05] <jam> axw: are you still around?
[12:05] <jam> I'm running into problems with maas 1.9 and KVM nodes not detecting storage during commissioning
[12:06] <dimitern> dooferlad, fair enough
[12:06] <dooferlad> dimitern: Will catch up with cards later and get a decent description in. Lunch now.
[12:07] <dimitern> dooferlad, sure, np
[12:07] <jam> dimitern: have you seen ^^
[12:08] <voidspace> frobware: dimitern: dooferlad: http://reviews.vapour.ws/r/3463/
[12:09] <dimitern> jam, I'm using KVMs on vmaas 1.9 all the time, and haven't seen that issue (even recently had to recommission all the nodes)
[12:09] <dimitern> voidspace, looking
[12:10] <voidspace> tnx
[12:10] <dimitern> jam, haven't yet tried 1.9.0 though - still on 1.9rc4
[12:12] <jam> k
[12:12] <jam> it might be fine on regular MAAS and it is a problem with storage detection on KVM instances.
[12:14] <dimitern> voidspace, reviewed
[12:14] <voidspace> dimitern: ta
[12:15] <voidspace> dimitern: heh :-)
[12:15] <voidspace> should have done that already
[12:23] <dimitern> :)
[14:05] <dooferlad> dimitern: could you help me out with what I am supposed to be doing next? I am not clear on what the next steps should be. Perhaps a hangout where we spec out some cards?
[14:07] <dimitern> dooferlad, sure, let's HO in like ~20m if you can?
[14:08] <dimitern> I just got some food
[14:08] <dooferlad> dimitern: perfect.
[14:27] <dimitern> dooferlad, hey, I added 2 cards and tried to describe the next steps - can you see if that's enough for you to go on with it?
[14:28] <dooferlad>  dimitern: yep
[14:28] <dimitern> if not, let's HO I guess
[14:34] <dooferlad> dimitern: will have to actually dig into code before I can tell if there is enough info in those cards, but they look good
[14:34] <dimitern> dooferlad, sure
[14:35] <dooferlad> dimitern: if you could mrege my changes (https://github.com/juju/charm/pull/186) that would be great. I don't have write access.
[14:39] <dimitern> dooferlad, I don't either, but mgz confirmed the charm repo is under the merge bot, so $$merge$$ will take care of it ... however - I've added one last comment
[14:48] <dimitern> dooferlad, sorry to be a pest, but "service wordpress wants to bind to endpoint foo to space bar, which isn't defined by the charm" needs rephrasing
[14:48] <dooferlad> dimitern: ok
[14:50] <dimitern> dooferlad, e.g. to `service "wordpress" wants to bind endpoint "foo" to space "bar", which isn't defined by the charm`
[14:50] <dimitern> dooferlad, do you mind doing a follow-up for that?
[14:51] <dimitern> or something like that
[14:51] <dooferlad> dimitern: sure
[14:51] <dimitern> the important bit is to quote names so they stand up in the message
[14:53] <dimitern> dooferlad, maybe even ", but the endpoint is not defined by the charm" ?
[14:54] <dooferlad> dimitern: yea, sounds good]
[14:54] <dimitern> dooferlad, tyvm
[14:57] <dooferlad> dimitern: https://github.com/juju/charm/pull/187
[14:58] <dimitern> dooferlad, reviewed
[14:58] <dooferlad> you and your %q
[14:59] <natefinch> %q is one of my favorite features of Go :)
[15:00] <dimitern> :) it's from experience - looking at MBs of logs and trying to find an issue quickly
[15:00] <perrito666> natefinch: you are happy with little
[15:02] <dimitern> dooferlad, thanks
[15:05] <natefinch> perrito666: sometimes :)
[15:09] <dooferlad> natefinch: try "%# v" some time -- it will blow your mind.
[15:12] <natefinch> dooferlad: oh, I know :)
[15:12] <natefinch> dooferlad: but sometimes it's the little things that are nicest.  Like auto-quoting the parameters in a print string :)
[16:13] <natefinch> cherylj: got a fix for #1529126, I see your name on git blame, care to do a super quick and easy review? http://reviews.vapour.ws/r/3464/diff/#
[16:13] <mup> Bug #1529126: cmdControllerSuite.TestControllerDestroy unittest <ci> <intermittent-failure> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core controller-rename:Triaged by natefinch> <https://launchpad.net/bugs/1529126>
[16:16] <dooferlad> dimitern: https://github.com/juju/bundlechanges/pull/15
[16:17] <dimitern> dooferlad, looking
[16:22] <dimitern> dooferlad, LGTM
[16:24] <cherylj> natefinch: sure, looking now
[16:27] <cherylj> ah, this is the stuff waigani added for the undertaker work he did
[16:29] <voidspace> dimitern: heh, if you rename your maas default space you get warnings from the juju client
[16:29] <voidspace> dimitern: probably on every operation...
[16:29] <voidspace> my default space is not called "default"
[16:30] <natefinch> voidspace: such a noncomformist
[16:30] <voidspace> natefinch: always! :-D
[16:31] <dimitern> :)
[16:49] <dooferlad> mgz: https://github.com/juju/bundlechanges/pull/15 seems to be being ignored by the merge bot. Is it still under bot control?
[16:51] <mgz> still?
[16:51] <mgz> it's the jujugui gating
[16:51] <mgz> not ours
[16:52] <dooferlad> ah, my mistake.
[16:52] <mgz> see the previous prs for how that works
[16:52] <mgz> :shipit: I believe
[16:52] <dooferlad> thought I had seen our bot, but maybe I just have too many github tabs open :-)
[16:57] <dooferlad> mgz: thanks, that was it.
[17:24] <marcoceppi> I need help, upcoming demo to MS about new azure provider today, I can't bootstrap: http://paste.ubuntu.com/14422068/
[17:24] <marcoceppi> 1.26-alpha3-trusty-amd64
[17:29] <marcoceppi> katco: do you know who I could bother about this^?
[17:32] <katco> marcoceppi: hey, let me take a look at the pastebin. unfortunately this is axw's realm i believe
[17:32] <marcoceppi> katco: oh, axw is eod isn't he?
[17:32] <katco> marcoceppi: he's asleep right now (aus)
[17:33] <marcoceppi> yup :(
[17:33] <katco> marcoceppi: as an aside, best thing to do in these situations is ping vanguard in #juju on private network
[17:33] <marcoceppi> I can't get the old provider to give me the right instances and I seem to be having issues creating a networkcontroller
[17:34] <marcoceppi> katco: I think I need to finish reading the instructions
[17:35] <katco> marcoceppi: ok. most interesting thing right now is the final error message. curious if you could manually do a put to this address with correct info: https://management.azure.com/subscriptions/776757db-9bc9-43bc-994e-761d0ce6c309/resourceGroups/juju-azure-west-environment-26ac52cb-0709-424a-891a-0e41adffbb8d/providers/Microsoft.Network/virtualnetworks/juju-internal?api-version=2015-05-01-preview
[17:35] <marcoceppi> katco: I need authorization
[17:35] <katco> marcoceppi: (sad trombone)
[17:35] <marcoceppi> katco: but later in the release notes I notice it mention "registering components"
[17:35] <marcoceppi> and network is one of them
[17:35] <marcoceppi> trying that now
[17:37]  * marcoceppi forces hand onto face
[17:37] <marcoceppi> katco: it's always when I ask for help, that I find the answer, I didn't have networking enabled on my account
[17:38] <katco> marcoceppi: :) not a problem at all
[17:38] <katco> marcoceppi: just glad it's working
[17:47] <frobware> cherylj, can we do a quick HO to verify whether I see IP addrs being released in my 1.8.2 setup
[17:48] <cherylj> frobware: sure:  https://plus.google.com/hangouts/_/canonical.com/maas1-8-2?authuser=0
[18:11] <frobware> cherylj, do we want a separate bug for the lack of gateway?
[18:12] <frobware> cherylj, as you say, bug 1528217 is really about lack of DNS
[18:12] <mup> Bug #1528217: 1.25.2 doesn't set up DNS information with MAAS <blocker> <ci> <maas> <network> <regression> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1528217>
[18:14] <cherylj> frobware: good point.  I'll open one up for you, give me a few
[18:42] <natefinch> ericsnow: in your review tyou say there can only ever be one of a resource, but that seems impossible.  Any time you upload a new revision of a resource, you'll by definition have at least two: the old one, which some of the units will still be using, and the new one, which the units will gradually switch over to.
[18:42] <ericsnow> natefinch: when you upload it replaces the one that was there
[18:43] <natefinch> ericsnow: but units are still using that one
[18:43] <ericsnow> natefinch: ah, right, but that has not been addressed yet in the spec
[18:43] <ericsnow> natefinch: let's keep it simpler for now
[18:45] <natefinch> ericsnow: I guess.  I'd bet money that we'll want the list sorted... and in fact, even in the spec right now, it appears that the resources from the store are sorted to the top, though of course that may just be coincidence.
[18:46] <ericsnow> natefinch: yeah, it may be that the store resources should be shown first
[18:47] <ericsnow> natefinch: for now let's just go unsorted and ask for clarification since it's ambiguous
[18:47] <ericsnow> natefinch: (mostly)
[18:47] <natefinch> ericsnow: that's fine, it's vcs, I can always get the code back.
[18:47] <ericsnow> natefinch: exactly! :)
[18:47] <ericsnow> natefinch: I've done that a time or two :)
[18:48] <natefinch> man I hate that the format framework stuff uses interface{} and then immediately requires you to typeconvert to the since type it must be.
[18:49] <natefinch> s/since/single
[18:57] <natefinch> ericsnow: so about the FormattedCharmResource and FormattedSvcResource - I disagree that they're not structured data.  There's quite a bit of logic in the FormatSvcTabular function that needs to transform the structured data into unstructured text.  It's less true of FormatCharmTabular, but I'd have to be switching over a raw string in FormatSvcTabular for Origin at the very least.  Origin and DataType are enums, even in this data, it's only when t
[18:57] <natefinch> hey're output that we make them into strings.
[18:58] <natefinch> I do 100% agree that the lower() function should be in the formatter, not on the data types, though.
[18:58] <ericsnow> natefinch: I don't think the logic belongs in the outputter
[18:59] <natefinch> ericsnow: isn't that the definition of what it's for?  Take this data and spew it out in a specifc way.
[18:59] <ericsnow> natefinch: its only job it to convert the formatted data into the output we desire
[18:59] <natefinch> yes. we need logic there to know how to merge logical columns into visible columns.
[18:59] <ericsnow> natefinch: it isn't to format the data items, but to present (combine) them in a particular way
[19:00] <natefinch> and we should be basing the logic of how to combine the columns on strongly typed data, not strings that happen to match some other string
[19:01] <ericsnow> natefinch: if the type matters then we should handle it in the formatter
[19:03] <natefinch> The format struct defines the logic columns of data. The outputter uses those to decide how to output the actual columns.  Putting the logic of how to combine the columns in the format struct is mixing concerns.  The format struct shouldn't have logic. That's why I think you were right that the lower() functions belong in the outputter code, not on the struct's data types.
[19:05] <perrito666> marcoceppi: did you ever try to deploy openstack using lxd/lxc only? I recall you where doing something like that
[19:06] <marcoceppi> perrito666: wayne and paige were working on it, I never really got much into it
[19:06] <perrito666> mm, I might try to finish that, I am in need of an openstack
[19:07] <natefinch> I guess the question is, do you want the service resource's wacky revision/timestamp column printed out in json and yaml?  If yes, then it should be in the struct... I don't think it belongs there.
[19:16] <cherylj> alexisb, dimitern, frobware, it is worth noting that master has this problem as well, since the fix for bug #1483879 landed there as well
[19:16] <mup> Bug #1483879: MAAS provider: terminate-machine --force or destroy-environment don't DHCP release container IPs <bug-squad> <destroy-machine> <landscape> <maas-provider>
 <juju-core:Fix Released by dimitern> <juju-core 1.24:Won't Fix> <juju-core 1.25:Fix Released by dimitern> <https://launchpad.net/bugs/1483879>
[19:17] <frobware> cherylj, ack
[19:17] <cherylj> since master is still in devel, we can probably get away with just noting the problem in the release notes.
[19:17] <cherylj> and not back out the fix.
[19:18] <natefinch> cherylj: ping on that review?
[19:18] <cherylj> natefinch: yeah, I'm still looking.  For some reason, I've got a lot of meetings today :)
[19:19] <natefinch> cherylj: no problem, thought maybe you'd just forgotten to hit publish or something. No rush.
[19:20] <cherylj> natefinch: just to sanity check - did you re-run the race check with your changes?
[19:21] <natefinch> cherylj: I did :)  But a very good question to ask.
[19:21] <cherylj> yay!
[19:22] <cherylj> natefinch: shipit!
[19:23] <natefinch> cherylj: yay, thanks! :)
[19:32] <mup> Bug #1531589 opened: debug-log does not work with local provider on xenial + 1.25.0 <juju-core:New> <https://launchpad.net/bugs/1531589>
[19:44] <mup> Bug #1531589 changed: debug-log does not work with local provider on xenial + 1.25.0 <juju-core:New> <https://launchpad.net/bugs/1531589>
[19:47] <mup> Bug #1531589 opened: debug-log does not work with local provider on xenial + 1.25.0 <juju-core:New> <https://launchpad.net/bugs/1531589>
[20:32] <natefinch> ericsnow: made a compromise on the enums - they're string enums now, so I can remove all the BS with making them a stringer and the marshal functions etc.  Really cleans up the code.  I wanted to keep them with specific named values however, so the logic in FormatSvcTabular can switch over real values.  Also, the conversion functions from resource to output is actually fairly valuable buffer to protect us from those values ever changing.
[20:34] <ericsnow> natefinch: how is the matter handled in "juju status"?
[20:35] <natefinch> ericsnow: let me go find the right code under the status component.... OH WAIT.
[20:35] <ericsnow> natefinch: haha
[20:35] <natefinch> ericsnow: which is to say: it'll take me a big to find the right bit of code
[20:35] <natefinch> s/big/bit
[20:36] <ericsnow> natefinch: cmd/juju/status/tabular_output.go
[20:37] <perrito666> natefinch: if it makes you feel better, even if status where a component, it would still suck
[20:39] <natefinch> me: who the heck wrote this?  <git blame>
[20:39] <natefinch> 2a763456 (Eric Snow         2015-07-28 09:41:01 -0600  32)      p := func(values ...interface{}) {
[20:41] <perrito666> * blame is destroying friendships since forever
[20:42] <natefinch> haha
[20:43] <katco> natefinch: =|
[20:43] <natefinch> anyway.... :)
[20:44] <perrito666> wait until it degenerates into blame hunts
[20:44] <natefinch> honestly, I think git blame has like a 30% chance of coming up eric just based on line count alone
[20:45] <perrito666> git blame lies though
[20:45] <natefinch> yeah, true true
[20:45] <perrito666> if eric moved the line it will blame him
[20:45] <natefinch> merges and stuff
[20:46] <natefinch> ericsnow: the answer is... I don't know.  I don't really see any enums in the status structs... but maybe some of them are and I just can't tell because someone made them into raw strings. :D
[20:47] <ericsnow> natefinch: I'm (just) guessing that the formatter did all the work :)
[20:47] <perrito666> I might help you there, what is the problem?
[20:50] <natefinch> perrito666: I have a status struct that has enums, because one of the formatters needs to perform some logic to determine what to output... and I didn't want to have a switch that compared raw strings to some magic values.
[20:52] <natefinch> perrito666: http://reviews.vapour.ws/r/3445/#comment21101
[20:53] <natefinch> perrito666: I've simplified the code somewhat since that, to make Origin and DataType into typed strings, so we can drop the marshal crap.  But eric thinks they should just be raw strings
[20:54] <ericsnow> natefinch: I still think the formatter should be in charge of the logic stuff that outputters need
[20:55] <perrito666> natefinch: I am going to side with eric in this one
[20:55] <perrito666> status is already a nightmare to follow
[20:55] <perrito666> if you add that generate magic, even though it is nice, it will be impossible
[20:55] <natefinch> perrito666: no no... I've simplified it... let me push my changes
[20:56] <ericsnow> natefinch: e.g. the formatter sets a "HasRevisionNumber" field to true
[21:00] <natefinch> ericsnow: I guess if you then mark those as not getting serialized to yaml/json...  just seems like, if you do all that, then the outputter is just determining the column names and what columns to output.... I guess I just expected to separate the data and the view in different spots.  This seems like it's lumping all the views together in with the data.
[21:01] <ericsnow> natefinch: my understanding is that the outputter is just in charge of spitting out the data it's been given (or a subset) in some particular output format
[21:01] <ericsnow> natefinch: the issue here is the "subset" part
[21:02] <ericsnow> natefinch: you're saying that the formatter should render all the info the outputter needs to do its job
[21:02] <ericsnow> natefinch: I agree with that
[21:03] <ericsnow> natefinch: I'm arguing for explicitly providing the info and you are arguing for piggybacking on some of the formatted data (which is reasonable)
[21:05] <ericsnow> natefinch: this is all relative to what we are already doing: check for magic strings in certain fields in the outputter to make the decision
[21:05] <ericsnow> natefinch: I agree that sort of implicit knowledge is problematic
[21:06] <ericsnow> natefinch: so let's make it explicit with extra fields in the formatted data
[21:06] <ericsnow> natefinch: if you are worried about JSON/YAML, then don't export the extra fields
[21:07] <ericsnow> natefinch: if they aren't exported then the marshalers ignore them
[21:07] <natefinch> ericsnow: right...
[21:08] <natefinch> I still think it's merging the views in the wrong spot.... but it sounds like this is just the way they work, so I'll move those tabular columns into nonexported fields in the struct.
[21:09] <ericsnow> natefinch: thanks!
[21:26] <perrito666> the lxd provider works?
[21:26]  * perrito666 does not feel like deploying a full openstack by hand
[21:29] <natefinch> perrito666: yes it works
[21:29] <natefinch> perrito666: it requires a few manual steps right now, which are detailed in the default environments.yaml output
[21:36] <natefinch> perrito666: (a few one-time manual steps)
[21:37] <perrito666> I guess it is behind a flag right?
[21:41] <natefinch> perrito666: you need to compile with go 1.3 or higher
[21:41] <perrito666> 1.5 should be enough
[21:41] <natefinch> perrito666: indeed
[21:42] <natefinch> perrito666: there's no feature flag
[22:20] <perrito666> well, EOD
[22:26] <axw> marcoceppi: are you awake still?
[22:26] <axw> marcoceppi: you need to add features to your account... I think it's in the release notes, lemme check
[22:26] <katco> axw: i think he figured it out
[22:26] <axw> ah
[22:27] <axw> thanks katco
[22:27] <katco> axw: he did indeed have to add a feature to his account
[22:27] <axw> yup, I also needed to keep reading :)
[22:27] <katco> axw: lol!
[23:32] <marcoceppi> axw: yeah, I stopped reading the instructions
[23:32] <marcoceppi> axw: when I finished reading them, I found what I needed
[23:32] <axw> marcoceppi: goodo :)  did it all work ok after that?
[23:33] <marcoceppi> axw: so far so good. I was able to deploy to Standard_D12 instances which the old provider didn't allow
[23:33] <axw> marcoceppi: cool
[23:52] <marcoceppi> axw: I've got a problem
[23:52] <marcoceppi> axw: juju expose with the new ARM doesnt' seem to work
[23:53] <axw> marcoceppi: https://bugs.launchpad.net/juju-core/+bug/1527681
[23:53] <mup> Bug #1527681: azure provider does not appear to be opening ports <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1527681>
[23:53] <marcoceppi> well that puts a damper onthis demo
[23:54] <axw> marcoceppi: can you build off master?
[23:55] <marcoceppi> axw: it takes 20 mins to deploy and I have a demo in 30 :)
[23:55] <marcoceppi> axw: I'm going to poke a few holes manually
[23:55] <axw> marcoceppi: :/
[23:55] <marcoceppi> if I can figure out how
[23:56] <axw> marcoceppi: you'll need to create rules in the network security group
[23:57] <marcoceppi> axw: found them, thanks
[23:57] <marcoceppi> axw: I'll build from master next time