#openstack-meeting log

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