axwwallyworld: can you please create the feature branch? I don't have permissions to00:41
wallyworldah, ok00:41
wallyworldaxw: there now00:44
axwwallyworld: ta00:44
axwwallyworld: I'll land the branch you LGTMd there, then propose the next one against it00:45
mupBug #1550074 opened: ec2/ebs: ListVolumes should not return root volumes <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1550074>00:58
wallyworldaxw: when you're free could you look at http://reviews.vapour.ws/r/3971/01:09
axwwallyworld: ok, looking01:10
menn0axw: ping01:36
axwmenn0: pong01:36
menn0axw: in b16d1e85879d1cccb38a860b04c65125b87567f1 you made ConnectionInfoForName private (in cmd/modelcmd)01:37
menn0in a feature branch I'm using it01:37
menn0for the "juju migrate" command01:37
menn0any problems with exporting it again?01:38
axwmenn0: all those old things are going away. what're you using it for?01:38
axwmenn0: can you point me at the migrate code?01:38
menn0axw: ok, if there's a better way01:38
menn0axw: I need to get the API server and auth details for the controller to migrate a model to01:38
* menn0 digs up a link01:39
menn0axw: https://github.com/juju/juju/blob/model-migration-control/cmd/juju/commands/migrate.go#L8701:39
axwmenn0: sorry got called downstairs, one moment01:43
axwmenn0: something like this: http://paste.ubuntu.com/15202778/01:50
axwmenn0: configstore will be going away, so best not to revive the old method01:51
menn0axw: tyvm, this looks great01:52
menn0axw: I'll update the migrate command01:52
menn0axw: I knew this stuff was changing but it hadn't when I wrote it01:52
axwmenn0: yup, such is life with feature branches :)01:52
menn0axw: yep, they are are a double edged sword01:53
menn0axw: am I right in thinking that the store can be easily swapped out for testing? it looks that way from what I can see.01:54
axwmenn0: yes, c.SetClientStore before wrapping the command01:54
axwmenn0: the Init method will only set the default store if one hasn't been set already01:54
menn0axw: that's what I was looking at. perfect.01:55
anastasiamacyep, menn0. axw and wallyworld r pretty awesome \o/01:55
axwmenn0: also note that SetModelName and SetControllerName return an errors now, didn't before - in case you use that anywhere01:55
menn0ok great01:56
axwI should probably document how it works and send that out01:56
menn0axw: looks like ModelByName doesn't need AccountName01:59
axwmenn0: you may need to rebase01:59
menn0axw: I just rebased this branch to the latest blessed master01:59
menn0has it changed since?01:59
axwmenn0: 3 days ago02:00
menn0axw: probably just after then02:00
menn0axw: this branch will be around for a while yet so I'll get right up to tip02:00
axwwallyworld: my desktop keeps rebooting. need to run tests, will be off for a while03:04
menn0axw: thanks for your help earlier, the migrate command is working again.04:13
axwmenn0: great, np04:13
menn0axw: I wonder if MemStore should have some extra methods to make it easier to set up test configs.04:14
menn0axw: I had to make about 6 calls to set up a workable config for the migrate command04:14
menn0axw: and it took a while to figure out how to do it right04:14
axwmenn0: do you have something in mind? you can initialise the maps directly04:15
axwmenn0: I agree it's a bit tedious - initialising maps directly is a bit better, but still a bit verbose04:15
menn0axw: I was thinking some sort of call which sets up a model, controller and account all at once04:16
davecheneycan I get a review on this one please04:16
menn0axw: it's fine the way it is04:16
davecheneyfor whatever reason the bot has decided to ignore it04:16
menn0axw: just wondering if it could be better04:16
menn0I didn't even consider fiddling with the maps directly so i'm not sure how that would have looked04:16
axwmenn0: yeah, I think it can. something along the lines of testing/factory might be nice04:17
menn0axw: yeah, that style of helper might be nice04:17
menn0axw: not urgent though04:17
menn0davecheney: LGTM04:17
wallyworldaxw: depending on how far you get before eod with the default host model, can you push up something even if wip so it can be landed into feature branch and i can take over when you're gone?04:51
axwwallyworld: yup. just finished adding --default-model, still need to write tests04:52
wallyworldawesome, ta04:52
axwwallyworld: actually I think I'm going to have to rework things a bit, so we know what the UUID of the hosted model is up front05:11
axwwallyworld: needed so I can set the current model from the CLI without waiting for completion05:12
wallyworldthat doesn't surprise me05:12
axwanyway, will send you a link when I'm done05:12
wallyworldaxw: ok, i am off to meet anastasia for 1:1 and then to soccer but will be back later05:12
axwwallyworld: I might reappropriate "uuid" in the initial config for the hosted model, and add a new "controller-uuid" attribute05:12
axwwallyworld: later05:12
wallyworldcontroller-uuid is more explicit05:12
jammgz: sinzui: If I accidentally submitted a merge request but the branch was targetting the wrong branch, I want to cancel the merge job so it doesn't waste time.06:13
jamhow do I determine which merge job it is?06:13
jamWhen I go to the juju-ci page, I can see the pending request, but I can't see any of the details06:13
jamlike right now, there are 2 pending jobs, I have no way to distinguish them.06:14
davecheneyjam: best i know how to do is to open each of them06:19
davecheneyscroll down to the output06:20
davecheneyand then look at the branch06:20
davecheneysory, that won't work if they haven't started to run yet06:20
jammenn0: frobware: I updated my LXD branch to Skip() one of the tests that I know is not very nice (talks to LXD on your running machine and starts containers), and fixed newInstanceSummary to actually parse Mem correctly.09:10
jamericsnow: I also responded to your review feedback. Hopefully someone feels its good enough to at least land on the feature branch.09:11
jamtych0: ^^ branch updated09:16
frobwarejam: merging upstream/master was an intentional thing?09:25
jamfrobware: well, I do intend to keep up to date with master, yes.09:43
jamfrobware: just shouldn't have happened as part of the review.09:43
jamSo I landed master into the target branch directly, so now the diff is nice again.09:43
jamfrobware: I just misunderstood one of your comments. You said "this is missing a parameter" meaning the Print statement, but I read it as the network.Address()09:44
jamso I thought I was out of date with master.09:44
jam(which I was rather far behind)09:44
dooferladfrobware, dimitern, voidspace: https://plus.google.com/hangouts/_/canonical.com/sapphire10:01
voidspacedooferlad: sorry, got lost in code10:01
voidspacedooferlad: omw10:01
* fwereade_ popping out for a bit, bbl10:02
mgzjam: the only way to see which build is which that I know is by hover on *the main page* which is generally full of bundle test junk10:31
mgzbut you can see which job is which and cancel from there10:31
jammgz: the lines and lines of "charm-bundle-test-aws"10:32
mgzyeah, it's joy10:32
jamthere appears to be about 100 lines there.10:32
jammgz: did you see my email about setting up a CI test from one of the current LXD tests?10:34
mgzjam: yeah, it seems like a good idea10:34
voidspaceoh the irony: Test killed with quit: ran too long. github.com/juju/juju/worker/terminationworker10:35
voidspacedimitern: frobware: dooferlad: http://reviews.vapour.ws/r/3981/10:48
dimiternvoidspace, looking10:53
dimiternvoidspace, reviewed11:00
voidspacedimitern: I've fixed two of the issues and replied to the other two - I think we should drop the issue about providerId conversion and I am reluctant to include spaces with no subnets11:23
voidspacedimitern: how about we skip them for now and revisit that if it becomes a practical issue anyone cares about11:24
voidspacedimitern: I think including them is dangerous11:24
dimiternvoidspace, that's fine - added a comment11:30
voidspacedimitern: thanks11:31
dimiternvoidspace, frobware, dooferlad, please have a look http://reviews.vapour.ws/r/3972/11:35
dimiternvoidspace, frobware, dooferlad, and this is the straw-man proposal for addresses - http://paste.ubuntu.com/15204914/ (we should decide on the doc / collection / state type names - singular and plural)11:37
dooferladdimitern: what is the urgency on having a discussion around that?11:38
dimiterndooferlad, because that's what I'm about to start implementing11:38
dooferladdimitern: That clears that up :-)11:39
dimitern:) cheers11:39
dimiternif we don't reach consensus though, I can switch to doing the Machine.UpdateLinkLayerDevices() instead11:39
frobwaredimitern: ignore my comment about empty ops - just looked again and makes perfect sense.11:42
frobwaredimitern: rule 1, don't be blocked. :)11:42
dimiternfrobware, :) cheers, I still replied though, as it's a fair question11:44
dooferladdimitern: I can't think of any more information that we need for an ipAddressDoc. +111:47
dimiterndooferlad, sweet, thanks!11:48
frobwaredimitern: Did we settle on DNSSearchDomains for DNSDomains?11:52
frobwaredimitern: type 'IPAddressConfigMethod' is missing loopback.11:53
dimiternfrobware, good point - will rename DNSDomains to DNSSearchDomains11:54
dimiternfrobware, as for loopbacks.. the config type is still static I think (actually always static)11:55
frobwaredimitern: iface lo inet loopback11:55
dimiternfrobware, but the "loopback" part is the device type11:56
frobwaredimitern: don't believe so.11:56
frobwaredimitern: given the number of args in 'iface', it is the config method,11:56
dimiternfrobware, loopback devices have no options to set11:57
dimiternfrobware, so it can't have an address - it's always 127/811:57
frobwaredimitern: but things like "address" are iface options. the way I read interfaces(5) loopback is the config method.11:58
dimiternfrobware, hmm.. well if we use config type loopback that actually solves the minor inconsistency with what SubnetID to use for
frobwaredimitern: if you read through the manpage it talks about 'auto' method, then 'loopback', 'static', 'dhcp, 'manual' (in that order).12:00
dimiternfrobware, so, good idea - LoopbackIPAddress type does not accept a SubnetID or GatewayAddress12:00
dimiterns/does not/won't/12:00
frobwaredimitern: ooh, and in the xenial manpage there is also 'v4tunnel' method.12:01
frobwaredimitern: and '6to4'.12:01
frobware(I'll stop now.)12:01
dimiternfrobware, there are other methods I know - but we shouldn't worry about them yet I think12:01
frobwaredimitern: agreed. but if we wanted to faithfully generate /e/n/i then I think we should cover loopback. that's been around a while now. :)12:02
dimiternfrobware, I have a cunning plan to support pptp/tun devices at some point as devices with 2 parents or something like that12:02
dimiternfrobware, yeah, agreed - for completeness sake loopback devices and their addresses should be represented in the model12:03
dooferladdimitern: reviewed http://reviews.vapour.ws/r/3972/ - basically it is really close to being generic and I provide, what I think, is a simple suggestion to make it generic without having to change the rest of your code.12:04
frobwaredimitern: the 'ipAddressDoc' comment could also include an example; might clear up what we mean by link-layer network device.12:04
dimiterndooferlad, thanks, I'll respond shortly12:05
dooferladdimitern: I am about to get some lunch. No big rush.12:06
* dooferlad goes for lunch12:06
frobwaredimitern: other than that, but dooferlad, voidspace should take a quick pass once these ^^ changes are done.12:06
mupBug #1550306 opened: 1.25.3 can't bootstrap xenial environments <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1550306>12:06
frobwaredimitern: other than that LGTM12:06
dimiternfrobware, thanks! voidspace, dooferlad: here's an up-to-date paste  http://paste.ubuntu.com/15205049/12:11
frobwaredimitern: do we need to handle unknown?12:19
frobwaredimitern: if so, how and when do we get into that state?12:20
dimiternfrobware, no, like with devices it will be rejected if trying to add it12:20
frobwaredimitern: if that's the case why do we need the unknown type?12:23
dimiternfrobware, good question - it looks like we don't anymore (remember my earlier comments about possibly allowing unknown devices/addresses for containers before we know their real type? well I guess that's no longer relevant)12:25
dimiternso I'll do a follow-up after finishing the addresses (without UnknowIPAddress ) to remove UnknownDevice as well12:26
frobwaredimitern: great, thx. removing code always a bonus.12:27
* frobware lunches12:27
mupBug #1550338 opened: destroy-controller reports warning endlessly <juju-core:New> <https://launchpad.net/bugs/1550338>13:15
mupBug #1550338 changed: destroy-controller reports warning endlessly <juju-core:New> <juju-core 2.0:New> <https://launchpad.net/bugs/1550338>13:45
tych0jam: cool. do you need anythingn from me right now?14:28
natefinchericsnow, katco: upgrade-charm --resources is ready for review14:46
ericsnownatefinch: k14:46
natefinchericsnow: is that poller merge PR ready for review? I could do that next14:55
ericsnownatefinch: yes and that would be great14:56
voidspacedimitern: ping15:12
dimiternvoidspace, pong15:12
voidspacedimitern: so I'm looking at bindings in the provisioner15:13
voidspacedimitern: EndpointBindings15:13
voidspacedimitern: do they need to be names or ids?15:13
voidspacedimitern:  they come from state and are supplied originally as space names15:13
voidspacedimitern: so I'm hoping they'll just be stored as names, so there's no work to do there15:14
voidspaceunless we've translated into juju names and need to go back into maas names (which will be redundant once maas is fixed)15:14
voidspacedimitern: I think bindings for startMachine needs to be names not ids, right? (that's the one place we use names - and they can be validated at the time they're specified)15:15
dimiternvoidspace, let's have a quick HO ?15:16
voidspacedimitern: ok15:16
voidspacedimitern: https://plus.google.com/hangouts/_/canonical.com/sapphire?authuser=0&hceid=Y2Fub25pY2FsLmNvbV9pYTY3ZTFhN2hqbTFlNnMzcjJsaWQ5bmhzNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29t.cktt9qpgdt7im58l9qt9ianpag15:16
natefinchericsnow: gah.... we really gotta get the charmstore stuff going... all this fake stuff and todos is wicked distracting during code review (not your fault).15:54
ericsnownatefinch: agreed!15:54
katcoericsnow: natefinch: this iteration! :)15:55
natefinchkatco: yeah :)15:55
dooferladdimitern: why do we expect bindings to be an empty string if unspecified? Don't we cope with the key/value pair not being populated?15:58
dooferladdimitern: ref: juju/deploy.go getEffectiveBindingsForCharmMeta15:58
katconatefinch: you get a ship it!15:59
katcoericsnow: and you ghet a ship it!15:59
* ericsnow is gonna cry15:59
ericsnowkatco: thanks15:59
dimiterndooferlad, exactly because there were not specified - so we don't pretend they're not by storing a made-up default16:00
dimiterns/there were/they were/16:01
dooferladdimitern: why not just store nothing16:01
dimiterndooferlad, because the endpoints exist anyway - regardless whether we bound them or not16:01
dooferladdimitern: sure, the endpoints exist, but we have no need to store something. Not storing something makes as much sense as an empty string.16:02
dooferladdimitern: we still will be doing v, ok := binding[endpoint] style accesses, right?16:03
dimiterndooferlad, well, it's also because storing them makes it easier to read them back for network-get16:03
dimiterndooferlad, the list of all endpoints depends on the charm used by the service, same as for settings16:04
dooferladdimitern: But bindings aren't endpoints. Endpoints exist without them.16:04
dimiterndooferlad, let me double take it then - why do you think storing them is wrong?16:05
natefinchkatco: thanks16:05
katconatefinch: ty for getting that proposed so quickly. love how simple it is!16:06
dooferladdimitern: If we have to validate if a space is valid after we get it out of the binding map, that just adds work.16:07
natefinchkatco: yeah, I was super happy with how it went... other than having to change 1000 tests.. but now that the methods take configuration structs, that shouldn't need to happen again next time we add a parameter.16:09
natefinchkatco: I almost wish Go had optional arguments, just to avoid churn like this.16:10
katconatefinch: it goes against their simplicity > ease philosophy, but i agree. i really miss optional args16:11
dimiterndooferlad, it will be valid once stored, as it's validated beforehand; if it's empty - nothing to validate16:11
katconatefinch: keyword args are even better16:12
katconatefinch: but i suppose passing in a struct is roughly equivalent. just less syntactic sugar16:12
natefinchkatco: yeah, I loved it when C# added named arguments.  Just make function calls so much more clear... no more doSomething(true, true, false, 3)16:12
dooferladdimitern: you still have to check if it is empty. You can't just iterate over the map. You need to iterate and check for empty. Then you need to see if non-empty stuff is valid.16:12
katconatefinch: i wish it could be smart enough to see that it takes a struct Foo, and then you could just do Bar({Baz: "whee"})16:12
dimiterndooferlad, which part of the code are you talking about?16:13
katconatefinch: that syntax doesn't look horrible16:13
katconatefinch: but still boilerplate to create arg structs16:13
dimiterndooferlad, deploy-time validation for bindings?16:13
dooferladjuju/deploy.go getEffectiveBindingsForCharmMeta adds the spaces.16:14
ericsnownatefinch, katco: I'm going to hold my tongue :P16:14
dooferladI bumped into this because tests had changed and I hadn't understood what was happening when I merged, so didn't pick up the expected empty strings.16:14
dooferladso failures happened.16:14
dooferladonce I dug into it, it seemed reasonable to ask why we changed the behaviour.16:15
katcoericsnow: ok, cool... btw, just totally off topic: python sucks!16:15
dooferladdimitern: ^^16:15
ericsnowkatco: apparently you *still* haven't tried it (just this once, everyone is doing it)16:15
katcoericsnow: haha16:15
dimiterndooferlad, well, the initial behavior which assumed they're never empty complicated the case where they were not specified by the user16:15
natefinchkatco: eliding the struct name in the function call would seem to be a pretty valid feature...16:16
dimiterndooferlad, so instead of inventing a sane default, we not don't store them16:16
katcoericsnow: honestly i have likely been ruined by CL. python is fine, but i've already gotten the "lightweight and flying feeling" from CL, and i prefer lispy syntax (my gawd it's full of parens!)16:16
* natefinch shudders16:16
dooferladdimitern: but we are storing an invalid value16:16
dimiterndooferlad, it sounds reasonable to not store them unless they're explicitly specified by the user16:17
ericsnowkatco: yeah, but you use/live in emacs16:17
katcoericsnow: (sheds a tear) i am more emacs now than not.16:17
dooferladdimitern: that is what I thought :-)16:17
dimiterndooferlad, but to do that some refactoring is in order16:18
katcoericsnow: but vim has a perfectly fine para-edit mode. makes editing sexps very easy16:18
dooferladdimitern: before I rebased on maas-space2 I was working quite happily not storing bindings that weren't specified.16:19
dimiterndooferlad, the changes that made unspecified bindings stored as empty is on master as well16:20
dooferladdimitern: yea, I was working off a really old maas-spaces.16:21
dimiterndooferlad, ah, well ;)16:21
natefinchwhy do we pass UUIDs around as strings?16:21
dimiterndooferlad, anyway, I'm happy to continue the discussion over the ML or something, but I really need to go out now16:21
dooferladdimitern: sure. Have a good weekend!16:21
dimiterndooferlad, likewise ;)16:22
frobwarekatco: did you ever dabble with Clojure?16:35
katcofrobware: dabbled *very* briefly16:35
frobwarekatco: likewise, but circa 200916:35
natefinchI've heard horror stories about Clojure... where the smartest guy in the company can write code that no one but him understands....16:36
natefinch(or her)16:36
katconatefinch: really? i've never heard that... it's hard to think why that would be the case16:37
natefinchkatco: when I get some time I'll see if I can dredge up the article.... something about obscure parts of the language and complicated mathematical constructs.... I think it wasn't impossible for others to understand, it just took a lot of time to understand like one line of code.16:38
katconatefinch: that sounds more like haskell16:38
frobwarekatco: bingo!16:38
* katco admits haskel is on her list of languages to learn16:39
frobwarekatco: talk to john wiegley, he does a lot of elisp/lisp/haskell.16:40
katcofrobware: of ledger-cli.org fame?16:41
frobwarekatco: yep.16:41
frobwarekatco: also now emacs maintainer16:41
katcofrobware: ah yes, forgot about that16:41
katcofrobware: what do you mean talk to him? "hey i'm random internet person #434562. i like lisp! hi!"16:42
mupBug #434562: phpmyadmin error <apport-package> <i386> <phpmyadmin (Ubuntu):New> <https://launchpad.net/bugs/434562>16:42
frobwarekatco: for john that would work. :)16:42
katcolol mup... that wasn't a bug number16:42
katcofrobware: i'm actually trying to migrate to ledger for personal finance16:42
katcofrobware: but stumbling a bit on getting the data out of my banks in a cron job16:42
frobwarekatco: I signed up recently with yodlee to do it MY way... :)16:43
frobwarekatco: yodlee provide a rest api to your bank account, complete with aggregation.16:43
katcoi am checking this out16:43
katcofrobware: i have to admit, part of the reason to switch to ledger was so that my financial life isn't aggregated into 1 spot on someone else's server16:44
frobwarekatco: well, that was my weekend hack. I'll let you know if it a) actually happens and b) is really viable. I so so hope it is...16:44
katcofrobware: awesome... lmk for sure :)16:45
frobwarekatco: burning bushes always gets in the way of real work. :-D16:45
katcofrobware: not aware of that phrase... what does it mean?16:46
frobwarekatco: there's always something more important that the most important thing you're working on. and when you get there it wasn't the great fire of london, just some small incidental problem, hence the bush...16:46
ericsnownatefinch: ship-it16:48
=== tvansteenburgh1 is now known as tvansteenburgh
natefinchericsnow: thanks.  Almost done reviewing yours.16:53
=== Makyo_ is now known as Makyo
=== alexisb is now known as alexisb-afk
natefinchkatco, ericsnow: we should have a conversation about returning interfaces at some point, since it has come up a few times.17:23
ericsnownatefinch: +117:24
katconatefinch: ericsnow: agreed17:24
=== lazypower_ is now known as lazyPower
natefinchericsnow: good point about making the arg struct change separate from the functional change.... I was thinking that since I'd have to change each callsite anyway, I might as well do them at the same time... but if I did the arg struct change first, then the functional change wouldn't need to touch any of those lines.... ahh well, I'll do it next time.17:27
ericsnownatefinch: no worries :)17:28
* natefinch lunches17:30
=== natefinch is now known as natefinch-lunch
=== _stowa_ is now known as _stowa
evilnickveitchdoes anyone know what is replacing the 'upload-tools' command?18:20
evilnickveitchit seems to be on the list of things to be deprecated, but it isn't clear to me how the functionality will be replaced18:21
evilnickveitchsorry ^ i meant sync-tools18:25
=== natefinch-lunch is now known as natefinch
katcoericsnow: hey you know how yesterday you were saying the endpoints for getting a charm shouldn't include version/archo?18:46
ericsnowkatco: yep18:46
katcoericsnow: i think it needs to include arch for sure since there may be different versions for arch (think jre)18:47
katcoericsnow: and version... how will old versions of charms pull down their coupled resources?18:47
katcoericsnow: we need a version concept i think18:47
ericsnowkatco: the mandate was that each arch would have its own resource name18:47
natefinchkatco: charms, AFAIK, have no concept of arch18:47
=== ses is now known as Guest76207
katcoericsnow: ah ok, missed that one18:47
natefinchkatco: it's unfortunate, but that is the way they exist now... they only care about series, which is honestly backwards of the way I would have done it.18:48
katconatefinch: yeah, i guess apt takes care of most of that, but seems like it should be a 1st-order concept18:48
katcoericsnow: and version? i think we need that18:48
ericsnowkatco: as to version, that corresponds with resource revision (hence the "comment" info we have punted on)18:49
katcoericsnow: right, so s/version/revision/g... w/e. i think the concept needs to be there18:50
ericsnowkatco: I thought it is18:50
katcoericsnow: it is... but i thought yesterday you said it didn't need to be18:50
ericsnowkatco: no, we don't need "version", we still need revision18:51
natefinchgah... if we can avoid having both version and revision, let's do that, because, geez that is confusing18:51
katcoericsnow: i'm not sure what the diff. is lol, but at any rate it's called revision in the spec18:51
natefinch^^^^^ exactly18:51
katcothat's what i needed to know... revisions stays in18:52
ericsnowkatco: I thought there was a "version" field in the API stuff18:52
katcoericsnow: not that i can see. the variable is revision, but when discussed it's called version18:52
ericsnowkatco: my point is that we can update the API spec to look like this: "GET id/resources/name" and "GET id/resources/name-2"18:53
katcoericsnow: bc afaict that's the same damn concept18:53
ericsnowkatco: yeah, I was wrong :)18:53
katcoericsnow: i think we still need revision18:53
katcoericsnow: for reasons i highlighted prior18:54
ericsnowkatco: I agree18:54
ericsnowkatco: its the "-2" in the example I gave18:54
ericsnowkatco: in the current spec it's the "[-revision]" part18:54
katcoericsnow: and actually... the current api spec says that id refers to the charm... does id represent a specific rev of the charm?18:55
ericsnowkatco: it must18:55
katcoericsnow: if that's the case, then we don't need rev18:55
katcoericsnow: because it will already narrow the scope of the resource to that rev of the charm, and thus use the correct rev of resource automatically18:56
ericsnowkatco: [-revision] is the resource revision, not the charm revision18:56
katcoericsnow: but the two are coupled18:56
katcoericsnow: new rev of resource implies new rev of charm18:56
ericsnowkatco: ah, right18:56
ericsnowkatco: the only catch is that you can change the resource revision for a given charm revision18:57
katcoericsnow: can you? that contradicts the edict that charms and resources are coupled18:57
ericsnowkatco: my understanding is that the tuple of (charm rev, resource rev...) is the identifier18:59
natefinchyeah, there's a line in the spec that mentioned you can change the revision of a resource for a revision of the charm19:00
natefinchthere is now a higher-order meta-revision for the charmRev+resourcesRev that we don't reallyhave a name for and doesn't have an identifier... which seems bad19:00
ericsnowkatco: BTW, if the API should support charm IDs that don't have a revision then [-revision] (for the resource) *is* necessary (a point you were making)19:01
ericsnowkatco: I have a feeling that we'll have to support that19:01
ericsnownatefinch: yeah, that19:01
katcois this confusing to anyone else?19:02
natefinchkatco: I had the exact same confusion which I brought up with Rick... because it seemed logical to increment the charmrev when we changed resources... but the charmrev is just for the charm code19:02
ericsnowkatco: uh, yeah :/19:02
natefinchhelp us rick_h_, you're our only hope19:02
katcoericsnow: natefinch: i mean i get it now that it's been explained... but man... i feel like we have this conversation *every* *time*19:02
natefinchkatco: yep19:03
ericsnowkatco: I was just thinking that19:03
natefinchkatco: and if the developers on the project have this confusion, what about users?19:03
katconatefinch: yes, this.19:03
ericsnownatefinch: they only need to know that they can change a resource revision for a given charm revision19:03
natefinchericsnow: right, but when Bill says "hey, my MySql charm seems broken" and Laura asks "Oh, what version are you running?" ... how is he going to answer that?19:04
ericsnownatefinch: yep19:05
ericsnownatefinch: not ideal19:05
katconatefinch: it does seem broken to not rev the charm when you rev a resource19:05
katconatefinch: effectively that's a new build19:05
ericsnowkatco: identifying your configuration19:06
katconatefinch: unless you looks at it like a shared lib which -- as long as it's revving a minor version -- can be swapped out19:06
natefinchkatco: I think we just need the higher-order concept.  It's very useful to know that between these two charm revisions, nothing in the code of the charm has changed19:06
katconatefinch: i agree19:06
ericsnownatefinch: I'd say that revving the charm with a resource change would do it19:07
natefinchkatco: if we had a charm-overall-revision, which always got bumped if anything changed, then at least people could just say "I am running mysql v1.2" and that would relate to a single charm-code-rev and resources-revs19:07
ericsnowkatco: yeah, though it may make sense to call that the charm revision and call what that is currently something like "charm info revision"19:09
katconatefinch: ericsnow: i dunno. why introduce a new concept? why not just have the charm version rev anytime anything with it changes?19:11
=== alexisb-afk is now known as alexisb
katconatefinch: ericsnow: any time a piece changes, the whole has changed19:11
ericsnowkatco: to distinguish between the-charm-changed and a-resource-changed19:11
natefinchwe should discuss with jam and rick_h_ when they're available. I'm sure they have a reason why it is how it is.19:12
katconatefinch: i think we're too close to change anything really, but would be interesting to discuss at any rate19:12
ericsnowkatco: we've definitely implemented the feature with the understanding that resource revisions are not fixed for a charm revision19:14
ericsnow(though the resource names *are* by virtue of the metadata.yaml)19:14
natefinchalso, keep in mind, you can always upload different bytes for the resources... and then what?  Now you have mysql 1.2, except one of the resources is differnt.19:15
natefinchgiven that, I think having an overall revision that makes any sense is not possible19:16
natefinchwhich sucks... but also doesn't mean someone can't come up with a name for the concept of the tuple of charm-code-rev + resources-revs19:18
natefinchpreferably without using the word tuple19:18
ericsnownatefinch: are you saying that the resource file for a given resource revision may change?19:19
natefinchkatco, ericsnow: BOOM! 5 more points for this iteration19:19
ericsnownatefinch: sweet!!!19:19
katconatefinch: duuuuuud! you rock!19:19
katconatefinch: you just got us a high score on points for an iteration :D19:20
katconatefinch: AND pushed our projected delivery to not just the xenial release, but the FFE deadline19:20
natefinchkatco, ericsnow: https://www.youtube.com/watch?v=l0e8ZMVqVCc&t=8219:22
katconatefinch: wtg crash override19:23
natefinchericsnow: no no... I'm saying that we can't have an overall revision for a charm, because any time you upload a resource, it would invalidate that overall revision,and now you're just on some-custom-revision for your overall-revision of the charm19:24
natefinchericsnow: I was just thinking about the conversation between Bill and Laura... sure, if Bill hasn't uploaded anythnig, he could say he's on mysql 1.2, but as soon as he uploads a custom resource, he has to fall back to talking about charm-code-rev + resource-rev19:25
ericsnownatefinch: right, it's a mess19:26
* natefinch puts on the Hackers soundtrack19:26
ericsnoweither way19:26
katconatefinch: such a good soundtrack19:27
natefinchkatco: yeah, really awesome soundtrack19:27
natefinchwe should merge master if we can... the tests keep popping up that annoying browser thingy19:29
katconatefinch: i can take care of that19:29
natefinchthen we can get our latest goodness into peoples' hands19:29
natefinch(after merging into master)19:30
katcosinzui: will ci run on feature-resources this weekend?20:21
sinzuikatco: No. CI doesn't test branches on weekends because all resources are used for repeatability and reliability trests20:22
katcosinzui: do you think we could get a bless before EoD? that way we can merge into master before EoD20:23
sinzuikatco: no, lxd is not testing that will take us to about the time branch testing will stop20:24
katcosinzui: ah ok20:24
sinzuikatco: maybe I want to disable weakend tests.20:24
sinzuikatco: your branch and others might test if I can disable or jut run the minimum set of tests20:24
katcosinzui: well, just lmk so i know when we can merge into master20:25
sinzuiokay katco.20:26
katcoericsnow: natefinch: don't forget to email me your 360 picks20:29
ericsnowkatco: k20:30
perrito666ohh picks20:30
natefinchkatco: oops20:30
perrito666I read pics20:30
natefinchthat is a lot of pics20:30
natefinchhope you like pics of my kids20:30
katcoperrito666: >.<20:30
natefinchkatco: I'm definitely not choosing ericsnow ;)20:30
ericsnownatefinch: me either :)20:31
katconatefinch: i've heard of this ericsnow guy. kind of a wild card? really loud? works out of a secret room?20:31
natefinchkatco: drinks like a fish, too20:31
katconatefinch: yeah... that's the one20:31
perrito666ericsnow: I prefer your previous background, looked more conspiracy theorist20:31
ericsnowperrito666: sometimes I miss that closet, but I get over it a few seconds later :)20:32
natefinchericsnow: aren't you behind a secret door, now?20:33
katconatefinch: ^^^ "secret room"20:33
ericsnownatefinch: of course not, that's ridiculous!20:33
natefinchkatco: I just meant, secret door >> closet20:33
katcohis house is practically the size of a super-villain's secret island20:33
natefinch^ this is true20:33
katcospeaks parseltongue20:34
katcoit's legit. ericsnow is an evil character20:34
ericsnowkatco: I wish none of you had found out; was starting to like you20:35
perrito666ericsnow: was definitely more evil character when we had standup in the mornings with wild hair and the creepy basement background20:35
* ericsnow flips some switches20:35
* natefinch would quit with some mysterious message... but sometimes it takes xchat 5+ minutes to log back in :/20:37
katconatefinch: you need a bouncer my friend20:37
perrito666or, to learn /leave or /part20:38
natefinchaww... learning...20:38
perrito666natefinch: btw, there is something wrong with your xchat, I presume it is the fact that you use xchat instead of hexchat20:38
natefinchperrito666: it seems to slowly be getting better... maybe it was just a head cold20:46
perrito666natefinch: but seriously, hexchat is a fork of xchat with better maintenance20:47
natefinchperrito666: I'm all for that20:47
natefinchperrito666: of course that requires me figuring out what my password is for the canonical servers20:52
perrito666natefinch: xchat2 stores it in plaintext, obviously20:55
natefinchperrito666: lol20:55
natefinchperrito666: so it does.  Nice20:56
perrito666well, I dont know if nice is the word I would use20:59
=== natefinch_ is now known as natefinch
natefinchperrito666, I was being sarcastic21:01
perrito666natefinch: irc lacks sarcasm21:01
natefinchwell, seems to work, and logged right in21:01
natefinchperrito666: I think irc lacks non-sarcasm21:02
natefinchperrito666: thanks... that was pretty painless, and I'm happy to be on a better maintained product.21:05
perrito666happy to help21:10
perrito666while I was using it I found it to be very nice21:10
katcoericsnow: standup time21:31
katcoericsnow: ping?21:37
rick_h_natefinch: just walked in from the airport21:50
rick_h_natefinch: what's the fire?21:51
katcorick_h_: no fire, just friday silliness21:51
rick_h_ah then wheeeeee21:51
katcorick_h_: you can travel in peace :)21:51
rick_h_travel done, now for snow shoveling21:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!