| frankban | dimitern: morning. re charm GET in core? what's the plan? do we want to implement it as /charms/ HTTPS GET? if you are busy ping me later, no rush | 09:38 |
|---|---|---|
| dimitern | frankban, morning! I don't think core has immediate plans to implement GET, I think we agreed you guys to do it? the placeholder for a GET handler is already in place in charmsHandler | 09:39 |
| frankban | dimitern: sure, so it's an HTTPS request right? not a websocket one. cool. just two questions: 1) is it ok something like /charms?charm=curl&path=path/to/file? 2) could you please point me to the code we have to use to retrieve a charm file from the storage? | 09:42 |
| dimitern | frankban, 1) I'd prefer /charms?url=curl&file=path/to/file (if file= is missing, you'll get the whole archive); 2) yep, just a sec | 09:45 |
| dimitern | frankban, re 2) you can take a look in repackageAndUploadCharm() in apiserver/charms.go | 09:48 |
| dimitern | frankban, there's the GetEnvironStorage to access the storage interface and from there you can do a Get(name) to download it, where name := charm.Quote(curl.String()) | 09:49 |
| frankban | dimitern: thanks, I'll take a look. so if file is missing, you get the charm as a zip, right? | 09:51 |
| dimitern | frankban, yep, if you even need to get the whole thing | 10:00 |
| frankban | dimitern: AFAICT the GUI does not need that (at least for now) | 10:01 |
| dimitern | frankban, so you can just return an error for now if file= is not given | 10:02 |
| frankban | dimitern: right, thank you | 10:02 |
| rick_h_ | morning | 10:54 |
| rick_h_ | frankban: can you look into the #1279075 card this week for release? That's the #1 bundle marketing bug from ecosystem that we'd like to have for the release/quickstart update this week. | 11:01 |
| _mup_ | Bug #1279075: Deployer should not stop when a unit has an error <juju-deployer:New> <https://launchpad.net/bugs/1279075> | 11:01 |
| rick_h_ | frankban: I moved it up into urgent over the other bug about the second bundle failing and such | 11:01 |
| rick_h_ | frankban: per hazmat in the friday standup the goal is to add a flag we can pass to the deployer that tweaks the behavior but leaves it failing as it does now by default because others rely on it for CI checks and such. | 11:02 |
| frankban | rick_h_: sure. so 1) introduce a flag for the new behavior, 2) that flag is not activated by default and 3) with that flag enabled, the deployment stops only if a unit error is found in one of the units belonging to bundle specific services. correct? | 11:04 |
| rick_h_ | frankban: well it should only stop if a service fails to come up entirely I think. If any unit comes up and can take a relation then it should | 11:05 |
| rick_h_ | if the bundle is 5 units and 4 come up ok the bundle should continue to add relations | 11:05 |
| rick_h_ | actually, reading the bug they want relations added even if the units don't come up. Not sure about that, but it's the issue they're having is that large scale demo bundles often have a unit or two that don't come up and the bundle aborts and fails the demo | 11:06 |
| rick_h_ | frankban: but yea, on 1) 2) | 11:07 |
| frankban | rick_h_: ack, ok | 11:07 |
| rick_h_ | thanks frankban | 11:08 |
| hazmat | g'morning | 11:14 |
| rick_h_ | morning hazmat, getting TZ adjusted? | 11:14 |
| hazmat | rick_h_, been up for a while.. woke up 3am due to some muscle cramps post long hike yesterday. | 11:15 |
| rick_h_ | ouch | 11:16 |
| rick_h_ | long hike? You bring a snow blower with you? | 11:16 |
| hazmat | rick_h_, yeah.. everywhere around here is covered with snow and 3-8 foot high snow drifts from the blows. | 11:16 |
| hazmat | er.. plows | 11:16 |
| hazmat | somewhat surreal for the area | 11:16 |
| rick_h_ | every time I try to take the dog for a walk I have to either wade up past my knees or risk cars sliding around on the street | 11:17 |
| bac | hello frankban. ought to be very quiet here today. | 12:11 |
| frankban | bac: morning, not so quiet actually | 12:13 |
| bac | oh? | 12:14 |
| bac | things on fire? | 12:14 |
| rick_h_ | ssshhh | 12:25 |
| rick_h_ | bac: heads up, talked with IS and there's some activity on your charmworld RT | 12:26 |
| rick_h_ | looks like we should be heading to a resolution there soon | 12:26 |
| bac | rick_h_: which one? :) | 12:26 |
| bac | the deployment one or the staging setup? | 12:26 |
| rick_h_ | bac: deployment | 12:26 |
| bac | yay | 12:27 |
| rick_h_ | staging is 3rd on the list so it's down the road still | 12:27 |
| bac | so rick_h_ are you really here today? | 12:29 |
| rick_h_ | bac: yes | 12:29 |
| bac | cool | 12:29 |
| rick_h_ | bac: I'll be here all week, tip your waitresses | 12:30 |
| bac | so rick_h_, in your email are you suggesting during a charmworld upgrade they do a 'destroy-service charmworld' and re-deploy it? is that what you mean by 'get a new unit'? | 12:50 |
| rick_h_ | bac: I'd assume they could juju add-unit, move the dns to the new ip, and then be all happy? | 12:51 |
| rick_h_ | bac: once that was done destroy the old unit | 12:51 |
| rick_h_ | bac: at least that's how I read things. I could be wrong | 12:51 |
| bac | rick_h_: their process is mysterious | 12:52 |
| rick_h_ | bac: yea, true. | 12:52 |
| bac | and by mysterious i mean way too complicated | 12:52 |
| rick_h_ | so maybe I'm thinking it's too easy | 12:52 |
| rick_h_ | lol | 12:52 |
| === gary_poster|away is now known as gary_poster | ||
| gary_poster | Well, I've been turning my computer on and off for the last 30 minutes, doing the moral equivalent of opening and shutting car windows to see if helps the vehicle start | 13:39 |
| rick_h_ | hah | 13:39 |
| rick_h_ | you offend the computer coming back? | 13:40 |
| gary_poster | :-) apparently so | 13:40 |
| gary_poster | I think I'm over 2000 unread emails... | 13:44 |
| rick_h_ | See you thursday | 13:44 |
| gary_poster | heh | 13:45 |
| gary_poster | rick_h_, could you please verify that you have leankit kanban super-super-powers? I'm not sure what you couldn't do before, but you now have the same privs as I do according to the interface | 13:46 |
| rick_h_ | gary_poster: rgr, looking | 13:47 |
| rick_h_ | gary_poster: yea, looks like it now | 13:47 |
| gary_poster | cool thanks | 13:47 |
| rick_h_ | whoa, board edit crazy | 13:47 |
| rick_h_ | *cancel cancel* | 13:47 |
| gary_poster | moving down the checklist you sent--thanks! also will review my logins to see what we can do | 13:48 |
| rick_h_ | gary_poster: thanks, yea. Just stuff I thought of and ran into last week. | 13:48 |
| frankban | dimitern: re GET request, when sending back the file, do you think it is better to read and expand the bundle to a temp dir (and then using http.ServeFile) or to directly read the file from the zip archive and send it some way? The former seems easier/safer | 13:51 |
| dimitern | frankban, I'd be a bit careful when implementing the extraction, because it's a possible DDoS target if the api server gets flooded with tons of GET requests for the same charm | 13:54 |
| rick_h_ | dimitern: does the api call support only auth'd requests so that's not an issue? | 13:54 |
| dimitern | frankban, perhaps using a "cache" dir somewhere, and each curl gets extracted to the same place if it's not there already? | 13:54 |
| frankban | dimitern: well, it's a ddos target for authenticated users | 13:54 |
| * bac installs trusty updates. reboots. holds breath. | 13:55 | |
| frankban | dimitern: yeah that can be an option | 13:55 |
| dimitern | frankban, rick_h_ , that's true, but still my spider sense is tingling a bit :) | 13:55 |
| dimitern | frankban, also, what you get "for free" is the ability to cache charms and thus answer to subsequent GETs for the same curl faster | 13:56 |
| frankban | dimitern, where do you usually store this kind of cache dirs? /tmp? /var/lib/juju/? | 13:56 |
| dimitern | frankban, i think /var/lib/juju/agents/.. something - take a look where the charms are cached when deployed | 13:57 |
| frankban | dimitern: is charm.Quote(curl) good enough as a directory name? | 13:58 |
| dimitern | frankban, yes, it's intended to be filepath safe, although it's perhaps better to use the same tactic as the charmsHandler - i.e. "<charm name>-<revision>-<bundlesha256>" as filename, so that it's both readable in a list of files, and guarantees the same internal contents get the same name | 14:00 |
| frankban | dimitern: sounds good, thank you! | 14:01 |
| dimitern | frankban, np :) | 14:03 |
| bac | rick_h_: i made some changes to your doc in situ. hope you don't mind. looks good! | 14:46 |
| rick_h_ | bac: thanks! appreciate the help and feedback. | 14:46 |
| gary_poster | rick_h_: sent you email reply with important bits | 14:57 |
| rick_h_ | gary_poster: thanks | 14:57 |
| gary_poster | welcome | 14:57 |
| hatch | morning all | 15:48 |
| rick_h_ | party | 15:50 |
| hatch | s club party! | 15:50 |
| rick_h_ | jujugui meeting in 5 | 15:55 |
| rick_h_ | Makyo: standup? | 16:00 |
| bac | benji: have we ever tried to promulgate a bundle? is it possible? (done via charm-tools) | 16:13 |
| benji | bac: I /think/ it is possible. I don't know about charm-tools, I thought there was a UI on charmworld to do it. | 16:14 |
| Makyo | rick_h_, out today, not swapping. Sorry :( | 16:46 |
| rick_h_ | Makyo: rgr, thanks for the heads up | 16:46 |
| rick_h_ | Makyo: can you submit that in canonical admin? | 16:46 |
| Makyo | rick_h_, on it. | 16:46 |
| benji | is it intentional that we do not confirm scaling down the number of units in a service but do confirm scaling up? | 17:25 |
| benji | It seems just as dangerous to go from 100 to 1 as it is to go from 1 to 100. Maybe it is because scaling up might cost someone money (directly). | 17:26 |
| rick_h_ | benji: yea, i think that's the general idea | 17:28 |
| benji | I have a small bug-fix branch up for y'all to review: https://github.com/juju/juju-gui/pull/132 | 17:36 |
| rick_h_ | benji: looking | 17:39 |
| benji | k | 17:40 |
| rick_h_ | benji: it is a bit jarring isn't it, without the confirmation on downgrade. | 17:43 |
| * rick_h_ thinks we should update that as well just to be consistent | 17:43 | |
| benji | it is odd | 17:44 |
| rick_h_ | yea, just stands out when you're doing both back to back. | 17:44 |
| rick_h_ | benji: heads up, that test failure is spurious and I'm looking into it. Feel free to :shipit: with that there | 18:03 |
| benji | k | 18:12 |
| hatch | hey benji I'm wondering if we can remove the db.fire('update') in your most recent branch as well... I'm not sure what purpose that serves any longer | 18:23 |
| * hatch notes that he might be totally wrong :) | 18:23 | |
| benji | hatch: I can try removing it, if you want | 18:24 |
| hatch | well I'm just trying to think of things which require the canvas to be re-rendered at that point... | 18:24 |
| === BradCrittenden is now known as bac | ||
| bac | jujugui: any idea how we spell ISD these days? | 18:38 |
| hatch | isd? | 18:38 |
| rick_h_ | ISD? | 18:38 |
| rick_h_ | heh | 18:38 |
| hazmat | ops :-) | 18:38 |
| hazmat | bac, not sure we have isd anymore | 18:39 |
| hazmat | dunno | 18:39 |
| * gary_poster thought they were webops now | 18:39 | |
| gary_poster | on #webops | 18:39 |
| bac | thanks gary_poster. | 18:39 |
| gary_poster | welcome | 18:39 |
| rick_h_ | oh, yea I think it's basically IS and webops but even webops I don't think means what it used to | 18:39 |
| * bac wonders why #isd still exists, then. | 18:39 | |
| hazmat | well there was isd as a form of internal apps web dev at one point as well | 18:40 |
| hazmat | d was developer i thought | 18:40 |
| hatch | isd sounds like a disease haha | 18:40 |
| bac | hazmat: yeay, and they owned SSO, right? | 18:40 |
| bac | s/yeay/yeah/ | 18:41 |
| hazmat | bac, yeah.. although i think some of that shifted to online services | 18:42 |
| hazmat | hence i'm not entirely clear they exist as a dev group anymore | 18:42 |
| bac | you're right i think | 18:42 |
| bac | they are still referenced in the 2fa FAQ. of course it says it is in beta, too. | 18:43 |
| bac | hey marcoceppi, does 'charm promulgate' work with bundles? | 18:51 |
| rick_h_ | bac: it's supposed to, but not sure we've tested it | 18:52 |
| marcoceppi | bac: not really, currently to promulgate a bundle we just have a ~charmer push to lp:~charmers/charms/bundles/<bundle>/bundle | 18:52 |
| marcoceppi | bac: there will soon be a bundle promulgate command as soon as we figure out that process for that | 18:52 |
| bac | marcoceppi: for testing could i get you to promulgate one then? | 18:53 |
| marcoceppi | bac: certainly | 18:53 |
| bac | marcoceppi: bzr+ssh://bazaar.launchpad.net/~bac/charms/bundles/muletrain/bundle | 18:53 |
| bac | marcoceppi: i can be undone, right? | 18:53 |
| marcoceppi | bac: yes, we can delete the branch later | 18:53 |
| bac | rt | 18:53 |
| bac | rick_h_: last week you asked about featuring bundles. (one part of the orange metatask) the answer is you can only feature promulgated bundles. once marco promulgates that branch i'll feature it and see that it works. | 18:54 |
| rick_h_ | bac: ah, makes sense | 18:55 |
| marcoceppi | bac: passes proof, pushing now | 18:55 |
| bac | ty | 18:55 |
| rick_h_ | bac: I remembering having these discussions back when bundles were first done. Thought that was working. Oh well | 18:55 |
| bac | rick_h_, marcoceppi: if any of jorge's bundles are of sufficent quality we might consider promulgating them and featuring. | 18:56 |
| marcoceppi | bac: I'll got through them again, there are a few that are supposed to be good | 18:56 |
| marcoceppi | bac: pushed https://code.launchpad.net/charms/bundles | 18:56 |
| rick_h_ | bac: marcoceppi there's a marketing meeting to determine featured bundles later this week | 18:56 |
| rick_h_ | wel'll have a list from that to use | 18:56 |
| bac | ok | 18:57 |
| hatch | benji yay, less db update events....one step closer to removing double dispatch :D | 19:15 |
| benji | :) | 19:16 |
| benji | bac: I'm looking at bug 1277188 and wondering if we should change the GUI's behavior or add the proposed warning to the charm proof tool. Thoughts? | 20:09 |
| _mup_ | Bug #1277188: charm-proof should warn on revision-less charm URLs <charmworld:Triaged> <https://launchpad.net/bugs/1277188> | 20:09 |
| bac | benji: last week i did a branch for bug 1277696 that is waiting for review/landing to juju-deployer | 20:12 |
| _mup_ | Bug #1277696: Bundles with revision-less charm URLs should deploy <juju-gui:In Progress> <https://launchpad.net/bugs/1277696> | 20:12 |
| bac | benji: that branch makes the behavior the same across deployment-ers | 20:13 |
| benji | bac: oh! so the card for 1277188 should be... deleted? blocked pending the other landing? | 20:13 |
| bac | so bug 1277188 now really is about just making 'charm proof' spit out a warning | 20:13 |
| _mup_ | Bug #1277188: charm-proof should warn on revision-less charm URLs <charmworld:Triaged> <https://launchpad.net/bugs/1277188> | 20:13 |
| bac | benji: not blocked, imo. just do it. | 20:14 |
| bac | they are uncoupled. | 20:14 |
| benji | sounds good | 20:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!