| anastasiamac | davecheney: r u moaning or is it exclamation? | 00:10 |
|---|---|---|
| * hatch pokes his head in | 00:19 | |
| hatch | marcoceppi: that sounds very odd, can you file an issue with steps to reproduce? | 00:20 |
| davecheney | anastasiamac: 10:52 < marcoceppi> i just realized this whole demo is borked because cabs can't speak 2.0 api | 00:21 |
| hatch | marcoceppi: is this with juju 2.0 or 1.2x? | 00:21 |
| === lazyPower_ is now known as lazyPower | ||
| === lazyPower is now known as lazypwr | ||
| marcoceppi | it's okay, i've become a reluctant expert at demo magic, all is well rick_h__ davecheney | 01:02 |
| marcoceppi | hatch: I can actually reproduce it in 1.25 and released juju gui | 01:02 |
| marcoceppi | as well as 2.0 and ~juju/juju-gui | 01:02 |
| hatch | marcoceppi: yay a repruducable bug :D | 01:02 |
| davecheney | huzzah! | 01:02 |
| hatch | marcoceppi: if you are able to create an issue for it now, I can probably get someone on it tonight | 01:02 |
| hatch | (which would be my preference) :D | 01:04 |
| marcoceppi | hatch: I have to deploy another service | 01:05 |
| hatch | marcoceppi: I just mean file an issue on github with steps for us to reproduce it | 01:06 |
| === lazypwr is now known as lazyPower | ||
| rick_h__ | marcoceppi: glad to hear it | 01:33 |
| rick_h__ | marcoceppi: how did it go? | 01:33 |
| marcoceppi | rick_h__: great | 01:33 |
| rick_h__ | marcoceppi: <3 | 01:33 |
| === lazyPower is now known as lazypwr | ||
| === lazypwr is now known as lazyPower | ||
| mup | Bug #1553059 opened: Help output when killing a `shared model` is incorrect <juju-core:New> <https://launchpad.net/bugs/1553059> | 07:33 |
| === lazyPower is now known as lazypwr | ||
| voidspace | dimitern: frobware: dooferlad: grabbing coffee | 09:59 |
| voidspace | didn't see the time | 09:59 |
| voidspace | be there in 5, sorry | 09:59 |
| dimitern | voidspace, np, omw as well | 09:59 |
| voidspace | right, omw | 10:03 |
| fwereade | voidspace, would particularly appreciate your thoughts on http://reviews.vapour.ws/r/4060/ | 11:12 |
| dimitern | fwereade, cheers btw! I'm having a look and so far it looks great | 11:45 |
| dimitern | fwereade, you've got a review | 12:04 |
| voidspace | fwereade: ok | 12:08 |
| voidspace | fwereade: you've added discoverSpacesComplete as a gate.Lock, but it doesn't appear to be used | 12:27 |
| voidspace | fwereade: is it just there as a reminder, or can it be removed | 12:27 |
| fwereade | voidspace, ...well spotted, that was left over from before | 12:27 |
| fwereade | voidspace, thanks | 12:27 |
| voidspace | fwereade: and TestSpaceDiscoveryRuns is not yet written I assume... | 12:28 |
| fwereade | voidspace, yeah, the trouble there is that the existing tests use patched constructors which don't really work for dep engine workers | 12:29 |
| voidspace | fwereade: will you leave the unlocker in the discoverspaces.Config definition | 12:29 |
| fwereade | voidspace, I should probably just hack a quick patched-ctor test back in and move on, and worry about integrating everything together | 12:29 |
| fwereade | voidspace, I thought I would, since I have tests both with and without it -- easy to drop if we don't need it, but I'd already written the code | 12:30 |
| voidspace | yep | 12:30 |
| voidspace | cool | 12:30 |
| voidspace | fwereade: worker changes look good to me | 12:37 |
| voidspace | fwereade: heh, moving ConvertSpaceName will conflict with my current branch that moves it to network package | 12:44 |
| voidspace | fwereade: ah well... | 12:44 |
| voidspace | it's going away altogether soon as well. | 12:45 |
| fwereade | voidspace, cool | 12:48 |
| voidspace | fwereade: yeah, all LGTM except the unwritten test and the left over gate | 12:51 |
| voidspace | fwereade: thanks for your work here | 12:51 |
| fwereade | voidspace, np, thanks | 12:57 |
| rogpeppe2 | mgz: yo! | 13:10 |
| === rogpeppe2 is now known as rogpeppe | ||
| rogpeppe | mgz: why can't I copy a bzr repo from one place to another and have it work? | 13:10 |
| mgz | rogpeppe: hey | 13:10 |
| rogpeppe | mgz: i get "No repository present" | 13:10 |
| mgz | did yoy not take the .bzr dir with the repo? | 13:10 |
| rogpeppe | mgz: i did | 13:11 |
| rogpeppe | mgz: there's no difference between the dirs (according to diff -r) | 13:11 |
| mgz | do `bzr info -v` will tell you where it is | 13:11 |
| rogpeppe | bzr: bzr: ERROR: No repository present: "file:///home/rog/tomb/" | 13:11 |
| mgz | right, so where was the original? | 13:11 |
| rogpeppe | mgz: in ~/src/go/launchpad.net/tomb | 13:12 |
| rogpeppe | mgz: ah! | 13:12 |
| mgz | the other thing is, you can bzr push from the original location to... more things than you'd expect from other vscs, works to filesystem at least | 13:13 |
| rogpeppe | mgz: i think it must be a cobzr artifact | 13:13 |
| rogpeppe | mgz: i don't have the problem if i branch directly from lp | 13:14 |
| rogpeppe | mgz: odd | 13:14 |
| mgz | rogpeppe: yeah, and you can copy the whole dir structure without needing bzr and that will work too | 13:14 |
| rogpeppe | mgz: that's what i did | 13:15 |
| rogpeppe | mgz: and was expecting to work | 13:15 |
| rogpeppe | mgz: but i needed to run bzr on the result | 13:15 |
| rogpeppe | mgz: (to update deps) | 13:15 |
| mgz | rogpeppe: but if the repo is at say, ~/src/go and the branch is at ~/src/go/launchpad.net/tomb you didn't take the actualy revision history | 13:16 |
| rogpeppe | mgz: no, the repo is in the tomb dir | 13:16 |
| mgz | but I'm not sure how cobzr confuses things exactly | 13:16 |
| rogpeppe | mgz: neither me | 13:18 |
| rogpeppe | mgz: i'm assuming it has an abs path somewhere | 13:18 |
| rogpeppe | mgz: hmm, no, i'm still seeing the issue | 13:21 |
| rogpeppe | mgz: have you got a moment or two to join a hangout? | 13:22 |
| rogpeppe | mgz: 'cos i'm probably being totally stupid | 13:22 |
| mgz | rogpeppe: sure | 13:23 |
| mgz | hm, though if you can just suse a fresh branch that would be fine | 13:24 |
| === lazypwr is now known as lazyPower | ||
| === lazyPower is now known as lazypwr | ||
| === lazypwr is now known as lazyPower | ||
| dimitern | frobware, dooferlad, voidspace, please have a look at http://reviews.vapour.ws/r/4064/ when you can | 15:24 |
| dooferlad | dimitern: swap: http://reviews.vapour.ws/r/4002/ | 15:27 |
| dimitern | dooferlad, looking | 15:28 |
| dooferlad | dimitern: thanks :-) | 15:29 |
| dooferlad | dimitern: were you trying to find out the maximum length of a go function name? | 15:36 |
| natefinch | lol | 15:36 |
| dooferlad | TestAddLinkLayerDevicesRefusesToAddContainerChildDeviceWithNonBridgeParent seems to be winning. | 15:36 |
| katco | ericsnow: natefinch: don't forget to complete your self-reviews + 360s by today | 15:36 |
| alexisb | lol | 15:36 |
| dimitern | dooferlad, yeah, that's the 3rd edition of the name, used to be longer :) | 15:36 |
| dooferlad | dimitern: well, if we didn't use CamelCase it wouldn't fit on a screen | 15:37 |
| natefinch | TestAddLinkLayerDevicesParentNameAsGlobalKeyFailsForContainerIfParentMissing | 15:37 |
| ericsnow | k | 15:37 |
| natefinch | katco: yep | 15:38 |
| cherylj | frobware: ping? | 15:44 |
| natefinch | ericsnow, katco: so, all the helpers for uploading bytes are in the csclient code, probably because UploadCharm etc exist only in csclient. For now I'm just going to put the meat of UploadResource in csclient and lightly wrap it in CharmStore, unless you have another suggestion? | 15:52 |
| katco | natefinch: i think that's fine, but want ericsnow to weigh in as he and wallyworld continued discussing after i had EOD. | 15:53 |
| katco | natefinch: i think wallyworld's main point was just to use the same wrapper that the rest of core code was using | 15:53 |
| katco | natefinch: annnd i think ericsnow just answered your question in email :) | 15:54 |
| ericsnow | natefinch: Ian and I never actually got back together; I had to go before he had time | 15:54 |
| natefinch | ericsnow: ok | 15:56 |
| natefinch | ericsnow: I think we have to include the filename is resource POST (UploadResource), since the charmstore is going to do the same extension matching as the controller | 15:58 |
| natefinch | ericsnow: I presume that'll just be another query parameter | 15:58 |
| ericsnow | natefinch: we'll want to check with the UI team on that; they may not feel the need to be as careful about matching the file types | 15:59 |
| natefinch | ericsnow: I asked rick_h__ yesterday and he said we want to do it :) | 15:59 |
| ericsnow | natefinch: regarding code in charmrepo/csclient that we may need, we'll need to wrap those in the charmrepo package | 15:59 |
| ericsnow | natefinch: k | 16:00 |
| ericsnow | natefinch: I just sent a reply to that email about charmrepo.CharmStore vs. csclient.Client, explaining the intended design a bit more clearly (hopefully :)) | 16:01 |
| natefinch | ericsnow: btw, just edited your Resources in the Charm Store doc... upload charm uses hash=foo for the has, so I changed our hash param name to match | 16:01 |
| dooferlad | frobware, dimitern: https://plus.google.com/hangouts/_/canonical.com/juju-spaces | 16:01 |
| ericsnow | natefinch: thanks for syncing that up with prior art :) | 16:02 |
| voidspace | dimitern: frobware: spaces meeting? | 16:03 |
| === JoseeAntonioR is now known as jose | ||
| dimitern | voidspace, uh sorry, omw | 16:12 |
| dooferlad | dimitern: we stopped. | 16:12 |
| dimitern | dooferlad, why so? | 16:12 |
| dooferlad | dimitern: you and frobware weren't there. voidspace and I didn't have anything to report. | 16:12 |
| dimitern | thedac, ping | 16:12 |
| thedac | dimitern: hey | 16:13 |
| dimitern | thedac, hey, sorry I got distracted - we should do a quick sync up though, if you don't mind | 16:13 |
| thedac | dimitern: Would you be available at the bottom of the hour? | 16:14 |
| thedac | I jumped into another meeting :) | 16:14 |
| dimitern | thedac, yes, let's do it then | 16:14 |
| thedac | sounds good. See you then. | 16:14 |
| dimitern | cheers | 16:14 |
| natefinch | ericsnow: what should upload resource return? The revision? | 16:18 |
| ericsnow | natefinch: yep | 16:18 |
| dimitern | dooferlad, you have a review | 16:28 |
| dooferlad | dimitern: thanks. Nearly done with yours. | 16:29 |
| thedac | dimitern: I am on the hangout now, whenever you are free. | 16:29 |
| dimitern | dooferlad, quite a few issues I'm afraid, but let me know what you think | 16:29 |
| dimitern | thedac, omw | 16:29 |
| === lazyPower is now known as lazypwr | ||
| ericsnow | natefinch: did that make sense about charmrepo.Client vs. csclient.Client? | 16:31 |
| * natefinch rereads | 16:33 | |
| frobware | dimitern, thedac: apologies for missing the call - I have water pouring out of my ceiling(s). :( | 16:33 |
| natefinch | ericsnow: yeah, that's pretty much how I was thinking of it... though sometimes there's not much high level logic to put in charmstore :) | 16:34 |
| frobware | dimitern, thedac: scrolling back - is the meeting on now? | 16:34 |
| dimitern | frobware, yep | 16:34 |
| thedac | frobware: it is | 16:35 |
| ericsnow | natefinch: yeah, that was my objection...which would perhaps be more relevant if we were writing this new :) | 16:35 |
| dimitern | frobware, are you coming as we're about to wrap up? | 16:36 |
| frobware | dimitern: yes, omw. | 16:37 |
| === lazypwr is now known as lazyPower | ||
| === lazyPower is now known as lazypwr | ||
| natefinch | ericsnow: the spec has PUT /id/resources/name/?hash=foo&filename=bar ... just checking that the slash after name is intentional | 16:48 |
| ericsnow | natefinch: not intentional | 16:49 |
| natefinch | ericsnow: ok | 16:49 |
| natefinch | ericsnow: good to know :) | 16:49 |
| ericsnow | natefinch: (copy and paste error) :) | 16:49 |
| natefinch | ericsnow: I'm not exactly sure how much it matters, but since I have to either type it or not, I might as well ask :) | 16:50 |
| ericsnow | natefinch: note that I also added size as a query arg | 16:50 |
| natefinch | ericsnow: do we need size? we have the hash, so we can verify the contents | 16:51 |
| === lazypwr is now known as lazyPower | ||
| katco | natefinch: ericsnow: was just thinking the same thing | 16:51 |
| natefinch | oh, and we already put size in Content-Length | 16:51 |
| ericsnow | natefinch: ah okay | 16:52 |
| cherylj | frobware: you around? | 17:02 |
| frobware | cherylj: yes | 17:07 |
| mup | Bug #1553272 opened: help text for destroy-model needs improving <helpdocs> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1553272> | 17:08 |
| cherylj | frobware: I opened up bug 1553017 for the xenial deployment issues | 17:08 |
| mup | Bug #1553017: Unable to deploy xenial on MAAS / resolv.conf not populated <open-iscsi (Ubuntu):In Progress by smoser> <https://launchpad.net/bugs/1553017> | 17:08 |
| frobware | cherylj: yes, noticed this morning, thx. | 17:08 |
| cherylj | smoser put in a workaround that I will try with your patch for bug 1550306 | 17:09 |
| mup | Bug #1550306: 1.25.3 can't bootstrap xenial environments <landscape> <juju-core:Fix Committed by frobware> <juju-core 1.25:In Progress by frobware> <https://launchpad.net/bugs/1550306> | 17:09 |
| cherylj | frobware: one thing I did see, though, that seems to be unique to your patch for that bug ^^ | 17:09 |
| cherylj | When I deployed to that node that had 2 NICs set up for testing bug 1549545 | 17:10 |
| mup | Bug #1549545: Bundle deploys fail at lxc-start when bridge br-eth1 is created <ci> <deploy> <maas-provider> <test-failure> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1549545> | 17:10 |
| cherylj | I couldn't juju ssh into it | 17:10 |
| cherylj | I could ssh directly to the IP | 17:10 |
| cherylj | and all the agents were running fime | 17:10 |
| cherylj | fine | 17:10 |
| cherylj | but just running juju ssh 1 didn't work | 17:11 |
| cherylj | (i'm rebootstrapping after verifying that it worked properly with 1.25 tip, and will get you the error message then) | 17:11 |
| frobware | cherylj: and the one thing is? | 17:13 |
| cherylj | I can't juju ssh into the node | 17:13 |
| cherylj | seems to only happen when I run with your patch for bug 1550306 | 17:13 |
| cherylj | juju ssh 1 | 17:14 |
| cherylj | Warning: Permanently added '192.168.100.150' (ECDSA) to the list of known hosts. | 17:14 |
| cherylj | ssh_exchange_identification: Connection closed by remote host | 17:14 |
| frobware | cherylj: dns issue. | 17:14 |
| frobware | possibly | 17:14 |
| frobware | cherylj: did you just apt-get update to get smosers changes? | 17:15 |
| cherylj | from machine 0? | 17:15 |
| frobware | cherylj: can we HO - might go a bit quicker. | 17:15 |
| cherylj | on the maas-controller? | 17:16 |
| cherylj | sure | 17:16 |
| cherylj | https://plus.google.com/hangouts/_/canonical.com/cheryl-jennings?authuser=0 | 17:16 |
| mup | Bug #1553272 changed: help text for destroy-model needs improving <helpdocs> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1553272> | 17:17 |
| mup | Bug #1553272 opened: help text for destroy-model needs improving <helpdocs> <juju-core:Triaged by cherylj> <https://launchpad.net/bugs/1553272> | 17:23 |
| natefinch | ericsnow: if you have a little time, sanity check my function signatures? don't need a full review yet, just want to make sure we're on the same page. https://github.com/juju/charmrepo/pull/65/files | 17:28 |
| ericsnow | natefinch: k | 17:28 |
| === natefinch is now known as natefinch-lunch | ||
| katco | ericsnow: natefinch-lunch: rogpeppe is going to give us some reviews on our 1-pager | 17:44 |
| ericsnow | katco: k | 17:44 |
| ericsnow | natefinch-lunch: I left a few comments on that PR. | 17:47 |
| * katco lunches | 17:49 | |
| rogpeppe | ericsnow: if you upload a new charm revision, does it have any resources by default, or do you have to put all the resources every time you upload a new charm? | 17:53 |
| rogpeppe | katco: ^ | 17:53 |
| ericsnow | rogpeppe: they get associated when you publish | 17:54 |
| rogpeppe | ericsnow: so resources aren't associated with a particular charm revision when you upload them? | 17:54 |
| ericsnow | rogpeppe: correct | 17:54 |
| rogpeppe | ericsnow: it might be worth mentioning that in the API docs | 17:55 |
| ericsnow | rogpeppe: a resource revision may be associated with more than one charm revision | 17:55 |
| rogpeppe | ericsnow: so unpublished charms can't have any resources? | 17:55 |
| ericsnow | katco: ^^^ | 17:56 |
| ericsnow | rogpeppe: I don't see why not, but the only mechanism we have to tie resource revisions to a charm revision is publishing | 17:56 |
| rogpeppe | ericsnow: that's my point | 17:56 |
| rogpeppe | ericsnow: just checking | 17:57 |
| rogpeppe | ericsnow: and can you "re-publish" the same charm revision several times with different resources? | 17:57 |
| ericsnow | rogpeppe: yep | 17:57 |
| rogpeppe | ericsnow: so that means that if you deploy (say) wordpress-4, you won't necessarily get the same thing each time? | 17:58 |
| rogpeppe | ericsnow: even though you've specified the revision exactly | 17:58 |
| ericsnow | rogpeppe: unfortunately yeah (this is a discussion we've had a bunch of times :/ ) | 17:58 |
| rogpeppe | ericsnow: that does seem bad | 17:59 |
| ericsnow | rogpeppe: there's now a problematic implicit charm revision tuple (rev, res 1 rev, ...) | 17:59 |
| rogpeppe | ericsnow: that skuppers reproducible charm deployment | 17:59 |
| ericsnow | rogpeppe: we could discuss this with rick_h__ again... | 18:00 |
| ericsnow | rogpeppe: I agree that it is a potential problem for that use case | 18:00 |
| rogpeppe | ericsnow: that's really important, i think | 18:00 |
| rogpeppe | jcastro: you got opinions on this jorge? | 18:01 |
| ericsnow | rick_h__: we should make sure this is settled ^^^ | 18:01 |
| rick_h__ | ericsnow: looking, otp atm but we'll see | 18:01 |
| ericsnow | rick_h__: np | 18:01 |
| ericsnow | rogpeppe: thanks for taking a look, BTW | 18:02 |
| rogpeppe | ericsnow: np. i've been meaning to do it for ages, sorry. | 18:02 |
| ericsnow | rogpeppe: it seems like the alternative is to make that implicit charm revision explicit: i.e. introduce a charm super-revision that maps to the revision tuple and use that to identify a charm "configuration" (poor name, I know) | 18:06 |
| rogpeppe | ericsnow: yes | 18:06 |
| jcastro | I am firmly in the reproduceability camp. marcoceppi ^^ wdyt | 18:06 |
| ericsnow | rogpeppe: but then we'd have 2 different charm revisions, which is confusing | 18:06 |
| rogpeppe | ericsnow: well, they're really different charms | 18:06 |
| rogpeppe | ericsnow: if you consider that a charm is really that tuple of stuff | 18:07 |
| marcoceppi | wait | 18:07 |
| ericsnow | rogpeppe: depends on if by "charm" you mean the archive or the archive + resources | 18:07 |
| rogpeppe | ericsnow: well, for the purposes of deployment it's gotta mean the latter | 18:08 |
| ericsnow | rogpeppe: unless we have clear and distinct language for the two, this is going to confuse people | 18:08 |
| ericsnow | rogpeppe: oh, I agree | 18:08 |
| rogpeppe | ericsnow: as the resources influence the behaviour of the charm | 18:08 |
| marcoceppi | ericsnow rogpeppe I agree with jcastro - the entire point of that revision is it's a moment in time that can be reproduced. If we're breaking that now it's not a good thing for the ecosystem | 18:09 |
| ericsnow | rogpeppe: so "charm revision" would mean different things in different contexts | 18:09 |
| rogpeppe | marcoceppi: i thought you'd say that :) | 18:09 |
| rogpeppe | ericsnow: well, it's a good question | 18:09 |
| rogpeppe | ericsnow: are resources specified in the charm metadata? | 18:09 |
| ericsnow | rogpeppe: yep | 18:10 |
| rogpeppe | ericsnow: so really, like bundles, it should be an error to upload a charm without some resources in place | 18:10 |
| jcastro | ok so when the resource needs to be revved the charm metadata needs to change right? | 18:10 |
| rogpeppe | jcastro: i hope not | 18:10 |
| marcoceppi | jcastro: no | 18:10 |
| marcoceppi | jcastro: resource revision is tracked in the store not in the charm | 18:11 |
| jcastro | ack | 18:11 |
| mup | Bug #1553292 opened: TestGoroutineProfile dial unix : no such file or directory <go1.5> <go1.6> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1553292> | 18:11 |
| ericsnow | jcastro: the *definition* of the resource is provided in the charm metadata | 18:11 |
| marcoceppi | jcastro: the problem is, you can rev charms and resources independantly of each other. So you could have resource+1 assocated to an existing charm which is technically a different experience | 18:11 |
| ericsnow | jcastro: the resource file is on top of that | 18:11 |
| rogpeppe | so in a way, it might make sense to specify a charm's associated resources at charm archive upload time | 18:11 |
| ericsnow | rogpeppe: there's a chicken-and-egg problem though, no? | 18:12 |
| rogpeppe | ericsnow: well yeah | 18:12 |
| ericsnow | rogpeppe: resources should not exist without the related charm | 18:12 |
| rogpeppe | ericsnow: :) | 18:12 |
| marcoceppi | rogpeppe ericsnow it seems to me, if you rev a resource version, it should artificially rev the charm version. Since "resource-upgrades" invoke a charm-upgrade it would solidify that story. | 18:13 |
| ericsnow | marcoceppi: we had discussed that, but I don't recall why we didn't pursue it | 18:13 |
| rogpeppe | here's another possibility: a POST to /$id/bindresources will create a new charm id with some specified resources associated with the given charm id | 18:14 |
| rogpeppe | and you ensure that you can't publish a charm to any channel unless all its resources have been bound | 18:15 |
| marcoceppi | ericsnow rogpeppe we could track the charm version as `cs:[~user]/series/charm-ver+resource_ver` cs:~marcoceppi/trusty/wordpress-12+2` | 18:15 |
| marcoceppi | or with a hash, I feel they're underutilized in the charm url schema wordpress-12#2 ;) | 18:15 |
| rogpeppe | marcoceppi: wouldn't it have to be wordpress-32+resource1:4+resource2:3 ? | 18:15 |
| ericsnow | rogpeppe: requiring all resources be there is already a requirement | 18:15 |
| marcoceppi | oh, yeah :\ | 18:16 |
| rogpeppe | ericsnow: ok, but currently publishing doesn't create a new revno | 18:16 |
| marcoceppi | rogpeppe: unless you considering a bundling of resources a version of that charm's resources | 18:16 |
| ericsnow | marcoceppi, rogpeppe: yeah, this is a hairy mess | 18:16 |
| rogpeppe | ericsnow: i'm proposing a primitive separate from publishing that makes a new revno | 18:16 |
| ericsnow | rogpeppe: right, that is one of the sticky points | 18:16 |
| rogpeppe | ericsnow: and you can then publish that | 18:16 |
| rogpeppe | ericsnow: so any revno always specifies an exact (charm, resources) tuple | 18:17 |
| ericsnow | rogpeppe: the question is, how to charmers and admins communicate about charm revisions? | 18:17 |
| ericsnow | rogpeppe: you'd still want to talk about the revision of a charm archive, right? | 18:17 |
| rogpeppe | ericsnow: i dunno | 18:18 |
| rogpeppe | ericsnow: maybe; although a hash is just as useful tbh | 18:18 |
| ericsnow | rogpeppe: agreed | 18:18 |
| rogpeppe | ericsnow: or a commit number | 18:18 |
| rogpeppe | ericsnow: charm revisions are pretty arbitrary tbh | 18:19 |
| ericsnow | rogpeppe: but then we're changing the meaning of "charm revision" in a way that may confuse users | 18:19 |
| rogpeppe | ericsnow: welcome to the brave new world of resources :) | 18:19 |
| ericsnow | rogpeppe: exactly | 18:19 |
| rogpeppe | ericsnow: but in other ways, we're keeping the important thing about charm revisions - if you specify a charm revision, you know what you're getting | 18:20 |
| ericsnow | rogpeppe: this is why we've had this same discussion several times already. :/ | 18:20 |
| ericsnow | rogpeppe: right, I agree that is the important part | 18:20 |
| ericsnow | rogpeppe: also, for charms without resources the meaning of "charm revision" will be the same | 18:20 |
| rogpeppe | ericsnow: i think that this is less confusing to the real users, and charm authors won't take long to catch up | 18:20 |
| rogpeppe | ericsnow: yes it will | 18:21 |
| rogpeppe | ericsnow: it just means that the second part of the tuple is always constant | 18:21 |
| rogpeppe | s/second/resources/ | 18:21 |
| ericsnow | rogpeppe: how about we always tie resources to a charm [archive] revision when we upload them, then other charm revisions may use existing resource revisions | 18:23 |
| ericsnow | rogpeppe: the we don't need to add another API endpoint | 18:23 |
| rogpeppe | ericsnow: how do you make a new charm revision with a different set of resources without uploading the archive again? | 18:24 |
| ericsnow | rogpeppe: publish will require that the charm entity have all it's resources set | 18:24 |
| rogpeppe | ericsnow: that doesn't answer the question AFAICS | 18:25 |
| rogpeppe | ericsnow: if i've uploaded a charm and specified the resources to associate with it, and then i want to make a new revision associated with new resources, without uploading the same archive again, how can I do that? | 18:26 |
| ericsnow | rogpeppe: hmm, you specify the resource revision explicitly during "upload"? "publish" will support associating them, but that doesn't help with development charms, etc. | 18:26 |
| ericsnow | rogpeppe: Perhaps you're right then about having an explicit endpoint for tying charm to resource revs | 18:27 |
| rogpeppe | ericsnow, marcoceppi, jcastro: unfortunately i have to go now | 18:27 |
| rogpeppe | it's been a useful discussion, thanks | 18:27 |
| ericsnow | rogpeppe: also, upload should be smart enough that it doesn't actually upload a resource blob that it already has (it should re-use the matching resource revision) | 18:28 |
| ericsnow | rogpeppe: thanks for bringing it up! | 18:28 |
| mup | Bug #1553298 opened: TestCloudInitWithGUI cannot fetch Juju GUI: cannot read Juju GUI archive: open \\gui.tar.bz2 on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553298> | 18:29 |
| mup | Bug #1553299 opened: TestCloudInitWithGUI cannot open posix paths on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553299> | 18:29 |
| mup | Bug #1553303 opened: TestCloudInitWithGUIError cannot open posix path on windows <ci> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553303> | 18:29 |
| === natefinch-lunch is now known as natefinch | ||
| mup | Bug #1553308 opened: Windows and Centos: Panic: unknown OS for series: "wily" <centos> <ci> <panic> <regression> <test-failure> <windows> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553308> | 18:41 |
| voidspace | bye all | 18:50 |
| voidspace | have a good weekend | 18:50 |
| natefinch | ericsnow: did you get a chance to peek at my PR? Like I said I don't need a detailed review, as long as I'm basically in the right ballpark | 18:50 |
| ericsnow | natefinch: yeah, I left comments | 18:51 |
| natefinch | ericsnow: oh, huh, I expected it to refresh when I went from code to comments, but I guess it doesn't. Thanks | 18:51 |
| natefinch | ericsnow: in your comment, you say I'm missing the resoucre revision... do you mean on the arguments to upload? Can you specify the revision number when you upload a resource? | 19:00 |
| natefinch | re: https://github.com/juju/charmrepo/pull/65#discussion_r55062391 | 19:00 |
| ericsnow | natefinch: the comment relates to the last line in the snippet, not the first :) | 19:02 |
| ericsnow | natefinch: GH code review, FTW | 19:02 |
| natefinch | ericsnow: oh, yeah, that makes much more sense | 19:02 |
| natefinch | ericsnow: yeah, GH code reviews, huzzah | 19:03 |
| mup | Bug #1553320 opened: TestBootstrapGUIErrorInvalidVersion os.ProcessState exit status 2 <centos> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553320> | 19:05 |
| mup | Bug #1553322 opened: TestBootstrapGUIErrorUnexpectedArchive os.ProcessState exit status 2 on centos <centos> <ci> <regression> <test-failure> <juju-core:Incomplete> <juju-core embedded-gui:Triaged> <https://launchpad.net/bugs/1553322> | 19:05 |
| rick_h__ | ericsnow: natefinch katco did you all want to chat? | 19:08 |
| katco | rick_h__: sure | 19:08 |
| katco | https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1 | 19:08 |
| natefinch | brt | 19:08 |
| katco | marcoceppi: jcastro: want to join us? ^^^ | 19:16 |
| jcastro | marcoceppi: we need you ^^ | 19:32 |
| katco | jcastro: marcoceppi: ty for your input | 20:09 |
| jcastro | <3 | 20:11 |
| mup | Bug #1553347 opened: juju bootstrap currently taking longer than 30mins <maas> <juju-core:New> <https://launchpad.net/bugs/1553347> | 20:41 |
| alexisb | jcastro, what are you loving? I missed it? | 20:44 |
| rick_h__ | alexisb: just some love passing between teams | 20:44 |
| mup | Bug #1553347 changed: juju bootstrap currently taking longer than 30mins <maas> <juju-core:New> <https://launchpad.net/bugs/1553347> | 20:44 |
| rick_h__ | katco: around when you get time. Can you also link me to the kanban board you use please so I can prep? | 20:45 |
| natefinch | rick_h__ https://canonical.leankit.com/Boards/View/114568542#workflow-view | 20:52 |
| rick_h__ | ty natefinch | 20:52 |
| mup | Bug #1553347 opened: juju bootstrap currently taking longer than 30mins <maas> <juju-core:New> <https://launchpad.net/bugs/1553347> | 20:53 |
| katco | rick_h__: hey sorry, was talking things through with the team. available now if you are | 21:16 |
| rick_h__ | katco: np, otp atm but will ping when off | 21:17 |
| katco | rick_h__: ok sounds good. give me a chance to make more tea :) | 21:17 |
| rick_h__ | katco: free now | 21:45 |
| rick_h__ | how bout your tea? | 21:46 |
| katco | rick_h__: going to get it now :) | 21:46 |
| katco | rick_h__: meet in moonstone? | 21:46 |
| rick_h__ | katco: link me please? | 21:46 |
| rick_h__ | google chrome won't autocomplete on moonstone for me yet, must not have used it enough times :) | 21:46 |
| katco | rick_h__: haha https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1 | 21:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!