19:01:39 #startmeeting swift 19:01:40 Meeting started Wed Jun 25 19:01:39 2014 UTC and is due to finish in 60 minutes. The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:43 The meeting name has been set to 'swift' 19:01:56 not much added to the agenda this week 19:01:57 #link https://wiki.openstack.org/wiki/Meetings/Swift 19:02:01 so.... 19:02:12 #topic open discussion 19:02:30 is there anything that you have that needs to be raised here in the meeting? 19:02:40 notmyname: i'd like to briefly mention keystone v3 work 19:02:48 port 6000 19:03:02 acoles: first 19:03:05 portante: good topic 19:03:13 acoles: tell me about keystone 19:03:31 So it maybe take more then 5 minutes then, good :) 19:03:32 i have a patch for swifclient that s been hanging around a while https://review.openstack.org/#/c/91788/ 19:03:50 keystone v3 support has been progressing across other clients 19:04:14 and we (hp) are very keen to see uniform v3 support in clients 19:04:14 acoles: can you add a link to that on https://wiki.openstack.org/wiki/Swift/PriorityReviews 19:04:23 yes, v3 support is good 19:04:27 so i'm throwing out an appeal to trade reviews 19:04:35 or i will beg... 19:04:51 notmyname: yes, i will add link 19:05:15 acoles: i’ll add my review on the patch tomorrow morning 19:05:33 related...i have put up for review the ACL issue as discussed at hackathon 19:05:48 thats a big 'un (mainly tests) 19:05:58 acoles: i'd like to see that as well please 19:06:22 anticw: https://review.openstack.org/#/c/86430/5 19:06:24 acoles: https://review.openstack.org/#/c/86430/ 19:06:29 cschwede: thanks! 19:06:54 cschwede: hey, if i catch a train to the paris sprint i could bug you in person :) 19:07:47 acoles: you should get an review earlier, but would be great to meet you in Paris! 19:07:47 notmyname: ok, that was all really, polite plea for reviews :) 19:08:09 acoles: ok, great. and you got at least one, which is good. the other should be much easier after cschwede has his on it :-) 19:08:15 portante: port 6000 19:08:16 notmyname: you might should maybe take a survey from core sometime to find out if keystone reviews take longer because they're a lower pority for core reviewers that don't use keystone day to day, or if they just don't have a keystone/devstack setup 19:08:37 port 6000 19:08:50 clayg: good idea 19:08:50 acoles: for my part that'll the next review(s) I look at when I have cycles (assuming you add them to PriorityReviews) 19:08:54 cschwede: i'll check diary... 19:09:22 as I understand it, the reason swift isn't in devstack is because we use ports 6000-6004 and those conflict with X 19:09:25 clayg: thx. and i understand not everyone has keystone experience 19:09:32 zaitcev has been working on trying to address reports about port 6000 conflicts 19:09:35 * acoles is the unlucky one 19:09:37 acoles: well, i'm learning :P 19:10:04 see https://bugzilla.redhat.com/show_bug.cgi?id=1107907 19:10:05 portante: Error: Could not parse XML returned by bugzilla.redhat.com: HTTP Error 404: Not Found 19:10:23 uvirtbot: lies! 19:10:24 notmyname: Error: "lies!" is not a valid command. 19:10:44 and https://bugzilla.redhat.com/show_bug.cgi?id=1107908 19:10:45 portante: Error: Could not parse XML returned by bugzilla.redhat.com: HTTP Error 404: Not Found 19:10:53 uvirtbot: more lies 19:10:53 portante: Error: I haven't seen lies. 19:11:05 uvirtbot: you can't see lies 19:11:05 portante: Error: "you" is not a valid command. 19:11:19 lol 19:11:26 uvirtbot: this is not a fruitful conversation 19:11:27 portante: Error: "this" is not a valid command. 19:11:28 I brought it up and someone, IIRC Sam, said that it was too trivial to change in case of conflict, so no need to adjust Swift's defaults. After all they worked for years. 19:11:31 zaitcev: so you're working inside of RH to move to 62xx for ports 19:11:33 wtf is going on 19:11:45 clayg: with uvirtbot or port 6k? 19:11:51 uvirtbot: wtf is going on? 19:11:52 portante: Error: "wtf" is not a valid command. 19:11:56 lol 19:12:08 wow, i'm confused to (about uvirbot) 19:12:10 portante: do not taunt happy fun bot 19:12:21 okay 19:12:23 :( 19:12:41 zaitcev: i think that's a fair point, but I also think being friendly neighbors is reasonable too, unfortunately it's NOT trivial for us to change the default because they're in your ring files :D 19:12:44 notmyname: we are getting bug reports and folks want that to stop 19:12:51 are there any obvious objections or problems with changing the ports 19:13:02 portante: "that"? 19:13:15 only that it'll hose anybody who hasn't specified bind_port in their configs and has an existing cluster 19:13:16 so, "yes" 19:13:17 notmyname: "that" meaning the AVC denials and conflicts with X11 19:13:17 portante: oh, the bug reports should stop 19:13:18 folks in red hat want less bug reports 19:13:38 port 6000 is a horrible default ... i think changing the docs and defaults is a reasonable thing 19:13:44 existing installations and rings will be fine 19:14:07 torgomatic: how will is hose folks who don't have bind_port set? 19:14:13 I was able to ignore X11 for a couple of years, but RHOS(P) folks really like their SElinux for some reason and thus they get attention. 19:14:23 anticw: I don't think that's true... if I upgrade, and my object server starts listening on 6200 but my object ring has 6000 in it, then my cluster is broken 19:14:34 torgomatic: oh it's no so terrible as all that, we document everywhere that you should specifiy a port and that it should be 6200 (or whatever) and if you don't set one we use 6000 but whine rather loudly about it and in a couple of releases we change the default 19:14:53 torgomatic: only if you don't have bind_port set ... we have to get people to update the pipeline anyhow 19:14:58 torgomatic: or even better we just refuse to start if you odn't set a bind_port 19:15:04 right now we insert dlo/slo, gatekeeper, etc ... all magically and potentially wrong 19:15:12 Sam's scenario is a problem. But Fedora, RDO, and RHOS always shipped with explicit ports, so I'm peachy here. 19:15:19 clayg: that - refuse to start without bind_port set 19:15:21 if folks think it's worth the hassle, that's fine, but we can't just flip a default and ship it 19:15:33 cschwede: +1 19:15:37 like clayg said, it'll take at least a couple of releases 19:15:42 or at least put an explicit warning 19:15:46 docs could happen now 19:15:52 I think the best is start with docs. 19:15:59 torgomatic: yup, +1, not worth *my* time - but I get why folks care 19:16:05 once docs are done, we can require bind_port to be explicit 19:16:09 making the config value required is nice 19:16:14 yeah docs are easy 19:16:20 notmyname: couldn't hurt - still needs to be over a release 19:16:24 clayg understands where I'm coming from :) 19:16:49 i think we should make the pipeline magic more explicity as well 19:16:55 and less magic 19:17:17 anticw: sure; the only reason for the magic stuff is to not break things on upgrades 19:17:28 so if folks want to do the multi-release deprecation thing, fine by me 19:17:31 anticw: creiht gholt and dfg had made that request as well, gholt suggested a static offline pipleline generator tool 19:17:38 sure, but over time it's cumbersome and things like swift 1.13.x put the slo/dlo in the wrong place 19:17:45 so it has to be explicit there anyhow 19:17:48 they did? 19:18:06 so we are done with port 6000, right? 19:18:07 anticw: well it's not so much that 1.13.x put them in the *wrong* place as we didn't know what was the *right* place 19:18:34 portante: i think so 19:18:37 #action change docs to set bind_port to 6200++. then later make it required. then default to that 19:18:38 portante: ^ 19:18:40 the action is to just update docs for the next release, and then a follow-on release is to require bind_port in configs, and then after that move the default? 19:18:42 portante: I'm continuing with my work in RDO and I'll look into changing docs, both in-tree and Anne's. 19:18:54 notmyname: if it's required why default? 19:19:12 anticw: oh yeah. my mistake. mising stuff up 19:19:24 #action undo previous action of setting a default 19:19:28 if we had that new specs git tree, perhaps this would be a good thing to write up there? 19:19:43 * clayg NOT IT! 19:19:45 I'm getting that that this afternoon!!! be patient!! 19:20:00 sorry I had to go break my shoulder 19:20:00 ;-) 19:20:15 /undo 19:20:24 portante: yes, that would be perfect for swift-specs 19:20:35 but now you are wolverine, right? so if you can stand up to jean gray, you can get the specs repo up and running, no? :) 19:21:34 he just went there 19:21:36 portante: will you be around this afternoon to take a look at -specs? 19:21:43 yes 19:21:51 great, thanks 19:21:59 * portante opened mouth, gotta step up 19:22:00 by updating docs first, would this include sample config files? That would be enough to get it into devstack right as they tend to just grab the sample configs. 19:22:23 mattoliverau: yes, sample configs are docs (or close enough) 19:22:25 yes, I said in-tree 19:22:32 speaking of sample docs ... we used to have a good example for tempauth ... at least something you could cut & paste 19:22:36 less so now 19:22:41 anticw: ? 19:23:07 iirc the latest docs on the deployment guide have everything you need but not in cut & paste format 19:23:17 [zaitcev@guren swift-tip]$ ls doc/saio/swift/ 19:23:24 account-server object-expirer.conf proxy-server.conf 19:23:54 that is SAIO, but it is a start 19:24:22 zaitcev: yeah, that's good ... just i recall pointing someone to the web-site saying you can cut & paste it ... and turns out that's not quite true 19:25:13 #action review tempauth sample config and ensure it's copy/pasteable 19:25:31 anything other burning issues in your minds? 19:26:29 were we going to revisit the timestamp offset format? 19:26:35 acoles: now 16 hex digits isn't enough!? 19:26:37 acoles: you know storeage policies is merged right? 19:26:39 lol 19:26:45 clayg: :) 19:27:00 oh, when? 19:27:01 * acoles smirks 19:27:53 acoles: do not taunt happy fun clayg 19:28:08 is there something like a final review for the RC? Or will this just become the release if there are no serious issues? 19:28:08 ok, i thought the 16 digits was a holding position. 19:28:32 cschwede: the latter. it will become the release unless serious issues arise 19:28:46 notmyname: ok, great! 19:29:27 ah, and what about the swiftclient patch for SP? should we merge it be before the release? 19:30:05 cschwede: IMO no because it's not available for the client to use until after swift is release (ie swift is upgraded more slowly than swiftclient) 19:30:32 well when does the RC become final? if the swiftclient change get merged? 19:30:35 cschwede: that is, it needs to be done soon and in Juno, but not eg tomorrow 19:30:55 clayg: current target for RC being final is next Thursday, July 3 19:31:36 wfm 19:31:53 notmyname: can cschwede add it to the priority reviews page anyway? 19:32:01 of course! :-) 19:32:13 clayg: notmyname: ok, will do so 19:32:26 BTW I updated that https://wiki.openstack.org/wiki/Swift/PriorityReviews 19:32:42 cschwede: thanks. to be clear, I think it's just fine if it lands before the final swift release. I just think that's not a requirement for the final release 19:33:16 notmyname: +1 19:34:01 for some reason I always though x-newest would stop after it found 3 copies instead of digging to the bottom of handoffs 19:35:58 clayg: x-newest is supposed to be expensive 19:36:56 notmyname: well we use it all the time, versions, container_sync 19:37:15 notmyname: acctually anytime you have a x-timestamp in the request (like e.g. the reconciler does) 19:37:34 clayg: by "bottom" you mean the handoff coung of 2*replica, not every single possible handoff (whole cluster) 19:37:41 lol 19:37:56 yeah just what comes of app.iter_nodes 19:38:50 clayg: so was that a question for the group? :-) 19:39:22 nah 19:39:43 ok. anything else then, or shall we close the meeting 19:39:44 ? 19:40:27 anyone likes to come to Paris next week for a small mid-sprint hackathon? 19:40:27 meeting done, then 19:40:29 thanks for coming 19:40:35 heh 19:40:42 and go to Paris next week :-) 19:40:51 or just whenever, really 19:41:00 cschwede: what's the link? 19:41:02 https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 19:41:12 #link https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 19:41:16 thanks 19:41:22 #endmeeting