21:00:29 <notmyname> #startmeeting swift
21:00:30 <openstack> Meeting started Wed Nov  4 21:00:29 2015 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:34 <openstack> The meeting name has been set to 'swift'
21:00:43 <notmyname> who's here for the swift team meeting?
21:00:45 <minwoob_> o/
21:00:47 <cschwede> o/
21:00:48 <kota_> o/
21:00:49 <jrichli> hello
21:00:50 <m_kazuhiro> o/
21:00:51 <wbhuber_> o/
21:00:52 <tdasilva> hi
21:00:55 <torgomatic> .
21:00:56 <gmmaha> o/
21:01:00 <ho> o/
21:01:13 <peterlisak> hi
21:01:48 <notmyname> welcome
21:01:59 <blmartin> o/
21:02:18 <notmyname> ok, first thing. somethign that just came up about 8 minutes ago :-)_
21:02:35 <acoles> hi
21:03:04 <notmyname> some of you may have heard of globo.com before. they're a pretty Big Deal in Latin America. based in Brazil, they're kinda like a yahoo type site for latic america
21:03:22 <notmyname> they've used swift for a while, and some of their ops have been in the -swift channel asking questions
21:03:50 <notmyname> first off, I was told to tell everyone thanks for that.
21:03:57 <notmyname> they're grateful for the help
21:04:35 <notmyname> and just yesterday they launched a new service (globo-play) which is like netflix for brazil. some of the static assets are stored in swift, and their video team is looking at putting the videos in swift too
21:04:46 <notmyname> I thought that was pretty cool :-)
21:04:49 <wbhuber> +1
21:05:56 <notmyname> oh, and globo-play is already the #1 downloaded app in the brazilian app store
21:06:10 <notmyname> yay! everyone using swift every day, even if they don't know it :-)
21:06:21 <jrichli> yay swift :-)
21:06:22 <tdasilva> cool!
21:06:31 <cschwede> nice! did they share any numbers (size)? always curious about that :)
21:06:47 <notmyname> cschwede: I don't know. ask NM if you see him in channel. not sure what he can share
21:06:53 <cschwede> k
21:07:29 <notmyname> ok, so moving on to the actual topics for the meeting... :-)
21:07:46 <minwoob_> Awesome user story
21:07:50 <notmyname> I want to start with the py3 info, just because of the time zones haypo and cschwede are in. it's late for them
21:07:55 <tdasilva> http://globoplay.globo.com/ nice, now you can all watch a whole lot of brazilian soap operas
21:07:59 <notmyname> #topic py3 status info
21:08:01 <notmyname> tdasilva: lol
21:08:24 <notmyname> last week several people met together to talk about py3, and haypo wrote it up on the ML
21:08:25 <notmyname> #link http://lists.openstack.org/pipermail/openstack-dev/2015-October/078058.html
21:08:43 <notmyname> haypo: cschwede: anything you'd like to add or comment on about this py3 plan?
21:08:50 <clayg> ohia
21:09:12 <cschwede> notmyname: i think there is an upcoming new pyeclib release that no longer requires the workaround in https://review.openstack.org/#/c/199034/?
21:09:21 <cschwede> i heard rumors about that ;)
21:09:28 <notmyname> cschwede: correct!
21:09:41 <haypo> cschwede: there is a review to bump PyEClib to 1.1
21:09:42 <notmyname> should have landed before the summit, but it didn't
21:10:00 <haypo> but i don't understand how libjerasure & gf-complete  will be installed
21:10:03 <notmyname> yeah, we'll get 1.1.x and won't have to deal with the sed-ness in tox.ini
21:10:19 <notmyname> haypo: they won't, by default
21:10:38 <haypo> notmyname: is it an issue to run the check jobs on gates?
21:11:09 <notmyname> haypo: no. liberasurecode has it's own simple EC scheme so it can do stuff with no dependencies. that's one of the reasons to bump the version
21:11:26 <cutforth> hello, sorry i'm late
21:11:26 <haypo> oh ok
21:12:02 <notmyname> on the py3 topic, in general, I think the plan is workable, but I think the reality is that it looks like a long road to go down. we'll end up with a constant set of "port to py3" patches
21:12:13 <notmyname> but the most important part is a voting gate job
21:12:22 <notmyname> ie nothing else really matters without that
21:12:32 <cschwede> but it should be more easy once we have voting patches, avoiding regressions
21:12:43 <notmyname> right. "easy"
21:12:46 <clayg> notmyname: do you mean a voting job that tests everything - or the green py3 dot that means "doesn't work on py3"
21:13:06 <haypo> notmyname: i don't care if it takes a long time to port swift, it's up to reviewers ;)
21:13:08 <notmyname> clayg: the green dot that means "some part does work on py3, but not everything"
21:13:26 <cschwede> clayg: a voting job that tests the parts that have been migrated to be py3-usable
21:13:30 <zaitcev> There's no alternative to a constant stream of "fix in py3" patches. The important part is to ratched new tests up constantly somehow.
21:13:50 <notmyname> haypo: that's not entirely fair. you've told us a big port won't work and haven't given us an idea of the scope. so it's really hard to assume anything other than "it will take a long time"
21:14:05 <notmyname> zaitcev: right
21:14:33 <clayg> zaitcev: it's not true to say there "is no alternative" - if we had a patch that fixes all the py3 - even if it conflicted frequently it'd be easy to show up on a wednesday and say "that's it i'm done - go +A"
21:15:22 <zaitcev> clayg: really? how did you fix rfc822 in it?
21:15:33 <haypo> https://review.openstack.org/#/c/238771/ Bump PyECLib version to 1.1.0
21:15:36 <notmyname> clayg: except that the py3 patch author (haypo) has said that he won't be able to do that
21:15:47 <clayg> notmyname: i know
21:16:05 <clayg> zaitcev: so you're saying all of this is for naught?  You can't acctually have a py3 swift because of pyeclib and other depends?
21:16:21 <haypo> notmyname: sorry, i have no idea of how much code requires to be modified to support py3
21:16:26 <clayg> rfc822 referring to the MIME message doc backport thingy?
21:16:26 <zaitcev> clayg: oh, wait, n/m. I think you said that you actually had that patch already, not "if we had a patch", sorry.
21:17:02 <haypo> notmyname: for some projects, it took 3 or 4 months, for some projects it will take 1 year or more (like nova)
21:17:23 <notmyname> IMO I'm fine with the plan as it stands, but I do with there were a way to have a faster port. ie something other than a new patch every week for a year with no real known end date
21:17:27 <clayg> zaitcev: oh right - totally hypothetical - I'm just saying we're on a path - and the that's fine - but it's hardly an enevitibility that this is the way
21:17:48 <haypo> notmyname: what i see is that i already proposed py3 patches for swift, and it always take 1 month at least to get reviewed. that's why i expect that the port will take 6 months or much more
21:17:50 <clayg> ok, so that was fun
21:17:52 <notmyname> "I'm fine with..." == it's somethign I can live with and it sets expectations
21:18:11 <haypo> notmyname: the problem is that we need first to have a voting py3 job
21:18:17 <notmyname> I agree with that
21:18:34 <haypo> (sorry, i'm in the middle of another meeting, it's hard to follow)
21:18:36 <notmyname> and getting the pyeclib version bumped is probably the next step
21:18:56 <clayg> right - how do you break off fast-POST, encrytpion, container-sync, etc to give py3 reveiew bandwidth?!
21:19:03 <clayg> torgomatic: says he can do py3 reviews on the train
21:19:22 <clayg> maybe I can make a filter to find +2'd py3 changes and +A them
21:19:33 <zaitcev> Since I'm not doing much of any technical work on Swift anymore, I tried to focus on haypo's patches recently... by being a stick in the mud most of the time. Like, I hate if six.PY3: thing and always try to challenge it.
21:19:43 <clayg> (then spend the next hour rebasing all of my changes)
21:19:44 <haypo> notmyname: for pyeclib, it took 3 months to get my py3 merged into pyeclib. pyeclib 1.0.8 was released with my fix but it's not used yet in swift
21:19:44 <notmyname> zaitcev: thanks!
21:20:01 <haypo> notmyname: and it looks like it will still take a few weeks to get pyeclib >= 1.0.8
21:20:07 <haypo> it's annoying to have to wait so long :-/
21:20:12 <notmyname> haypo: leave pyeclib out of it for now. that's going to be resolved within a week, I hope
21:20:21 <clayg> zaitcev: yawn - there's tons of ugly code in swift that is probably masking bugs - a few if PY3 branches won't kill us
21:20:30 <clayg> well tons is probably a strong word
21:20:46 <haypo> notmyname: https://review.openstack.org/#/c/238771/ the change on requirements for pyeclib is not merged yet :-/
21:20:50 <clayg> even if it was only 1/2% by line count I'd call it "way more than I would like"
21:21:00 <notmyname> I think it's safe to say that nobody is particularly happy with the speed of the py3 work
21:21:04 <clayg> haypo: is the new pyeclib released?!
21:21:12 <haypo> notmyname: hehe
21:21:38 <haypo> clayg: tuskar wants to use pyeclib 1.1 which was released at least 2 weeks ago
21:21:43 <acoles> patch 238771 has a -1 from kota
21:21:43 <patchbot> acoles: https://review.openstack.org/#/c/238771/ - Bump PyECLib version to 1.1.0
21:21:44 <notmyname> but the point is that we seem to have as close as possible agreement on something which might actually end with py3 support. even if nobody is particularly happy with that plan either
21:21:47 <haypo> clayg: the first step is to upgrade it in global requirements
21:22:09 <zaitcev> clayg: never say "new pyeclib". say "pyeclib-1.1.x" or something. This log will be archived you know :-)
21:22:26 <clayg> well then what do you want me to do?  it's not useful to say "this patch is a month old" if it's not ready to merge
21:22:35 <haypo> notmyname: i don't really understand why we are not making progress. IMHO the sed hack is an acceptable compromise to unblock the situation
21:22:54 <haypo> notmyname: always having to wait for other changes (like pyeclib) doesn't help
21:22:58 <clayg> haypo: I think the sed hack looks stupid and don't see the value of hacking around it instead of ust waiting
21:23:08 <clayg> haypo: but I'm *trying* to stay out of it
21:23:13 <notmyname> nope. nobody likes the sed hack and there is a plan in progress (delayed by the summit) for updating pyeclib
21:23:48 <notmyname> but I want to move on instead of spending 30 minutes in this meeting going over all this again
21:23:56 <tdasilva> sounds good!
21:24:01 <kota_> acoles: pyeclib 1.1.0 seems to have an issue for upgrading, so my -1 for safety
21:24:16 <notmyname> we have a py3 plan. it's in the link above. the first part is getting a passing test job (and yes I'm working on pyeclib updates to unblock that)
21:24:17 <tdasilva> we already have a plan, everybody knows it, let's move on
21:24:22 <acoles> kota_: right! just pointing out why it has not merged
21:24:24 <notmyname> tdasilva: :-)
21:24:31 <clayg> kota_: if the gate is happy with it it's probably fine - anyone running master can probably figure it out
21:24:33 <notmyname> acoles: kota_: and I'm in the same boat on that
21:24:38 <clayg> (or hack the requirements and be done with it)
21:24:54 <notmyname> ok, moving on
21:25:09 <notmyname> #topic summit recap
21:25:13 <clayg> thanks everyone for looking at those patches!
21:25:31 <notmyname> I want to ask a few questions about the summit. please let me know what you thought
21:25:42 <notmyname> 1) what did you like?
21:25:43 <zaitcev> I'll make sure Fedora has a pyeclib-1.1.x
21:26:00 <jrichli> I liked the number of fishbowls to working sessions
21:26:13 <acoles> +1
21:26:14 <notmyname> jrichli: ie lots of working sessions, few fishbowls?
21:26:18 <jrichli> yes
21:26:39 <blmartin> friday's free for all talks were great but it was hard to hear everyone in that room
21:26:39 <cschwede> more swift talks, as peluse counted. that’s great!
21:26:56 <notmyname> if I did it again, I'd probably put the crypto stuff in a fishbowl because of how crowded the room was
21:26:56 <clayg> we had lots of extra space in the fishbowls - I think a number of people in our working sessions were not around for the fishbowls
21:26:59 <zaitcev> yeah, I completely fell out of Friday in the end
21:27:28 <jrichli> having displays in the working sessions was nice (as compared to the previous summit)
21:27:31 <zaitcev> Haidi is super loud. Not to knock him, it's just the kind of voice he has.
21:27:38 <notmyname> heh
21:27:45 <clayg> I think there's a disconnect between the size of the room and format of the topics that isn't really captured in "fishbowl vs. working-session"
21:27:55 <notmyname> hrou: not sure if I should add that as +1 or -1 ;-)
21:28:01 <notmyname> clayg: agreed
21:28:19 <clayg> i may be getting our working sessions and Friday mixed up
21:28:32 <clayg> We needed more room to "break off" on Friday
21:28:35 <notmyname> ok, what did you not like?
21:28:44 <tdasilva> 4 days
21:28:46 <jrichli> rooms were too small for the number of people interested in swift
21:29:00 <clayg> we were spilling into the hall, and carrying whiteboards around the crowded table
21:29:02 <jrichli> (working sessions)
21:29:05 <notmyname> yeah
21:29:25 <clayg> I wonder if you could run a Friday in something more like the lunchroom?
21:29:31 <zaitcev> my main note from Summit was put fast-post is on my bucket list
21:29:41 <clayg> FUCK YEAH FAST POST!
21:29:41 <acoles> zaitcev: yay!
21:30:04 <notmyname> clayg: in paris? vancouver? we had a big room shared with cinder and we all thought the other project was being too loud
21:30:06 <blmartin> the next summit shirt should say swift: now with fast post
21:30:18 <notmyname> blmartin: now it works like you always assumed it did
21:30:21 <clayg> sorry container-sync, ec follow on, encyrption, etc - fast-POST first
21:30:24 <acoles> notmyname: no, they thought WE were too loud!
21:30:30 <blmartin> haha
21:30:42 <notmyname> acoles: right. they though we were loud. we thought they were loud
21:30:56 <acoles> hehe
21:31:12 <clayg> notmyname: yeah that's what I'm thinking of!  I liked that big room - i forgot it was shared - I donn't remember it being a problem - but I do remmeber running into a corner with a crowd to hit specific topics working well
21:31:15 <notmyname> what did you think of the scheduling? we tried the "blocks of time" approach instead of the "40 minutes for a topic" approach
21:31:27 <clayg> notmyname: SO MUCH BETTER
21:31:32 <notmyname> should we try that again next time?
21:31:33 <notmyname> ok :-)
21:31:34 <clayg> notmyname: I heard some other projects were doing the same thing
21:31:35 <torgomatic> worked pretty well for me
21:31:38 <acoles> +!
21:31:40 <jrichli> +1 for topic blocks
21:31:43 <acoles> +1 even
21:31:47 <zaitcev> no, clay, we need to you to balance redbo on python side; I have no clue what that "posrep" thing does better than ssync
21:31:49 <blmartin> blocks seemed great to me
21:31:55 <clayg> I thought we were being so clever
21:32:04 <notmyname> great, I'm glad that worked well. I was happy with it too
21:32:07 <kota_> +1
21:32:19 <notmyname> if we're clever, it probably means we could fit more stuff in too.
21:32:37 <notmyname> anyone else notice that we seem to be gradually turing the summit into one of our hackathons?
21:32:40 <acoles> did we work through all our breaks? :)
21:32:51 <zaitcev> I think bunching client topics together was good, at least we can have e.g. Tim and Zack schedule easier next time etc.
21:32:57 <tdasilva> notmyname: yeah, great, isn't it?
21:33:02 <clayg> notmyname: yes and I'm sure there's a downside hiding in there
21:33:08 <notmyname> zaitcev: right. next time is to actually get tim and joel in the room! ;-)
21:33:31 <notmyname> clayg: yeah. too much inward focus and we miss out on some cross-project stuff and hallway stuff
21:33:32 <hrou> notmyname, I was giving a summary about the summit and that was my one bigger comment; felt a lot like the hackathon ; )
21:33:41 <notmyname> hrou: was that good or bad?
21:34:13 <notmyname> ok, so was it a productive week overall? if not, what was missing?
21:34:15 <clayg> it was good
21:34:20 * notmyname is writing all this down
21:34:22 <hrou> zaitcev, I'll take that as a +1 ; ) (but yea, you're right, and I get that a lot, and need to keep that in mind)
21:34:34 <zaitcev> bunching of "swift immense topics" together was kinda challenging for a stupid guy like me; I basically tuned out Matthew and sharding because they came last
21:34:39 <hrou> notmyname, oh I didn't mind at all, I thought it was neat actually and effective.
21:35:05 <notmyname> zaitcev: yeah, I think everyone feels that after 8 hours of discussions
21:35:24 <clayg> notmyname: matt_____: acoles: I wonder if we haven't yet found the final form of dense topics at hack-a-thons
21:35:28 <notmyname> someone proposed that we should have a 11am-1pm + 8pm-1am summit schedule ;-)
21:35:39 <notmyname> clayg: oh, I'm pretty sure we haven't yet
21:35:53 <minwoob_> notmyname: Overall, it was a productive summit. Especially for container sharding, I feel that we made some good architectural progress.
21:36:02 <notmyname> great
21:36:04 <clayg> I felt like I was able to dissmeninate good info about the ring stuff - but my progress came on Saturday coding - not during the "working" session
21:36:12 <acoles> notmyname: i think we did more "intro to a topic" than at a hackathon e.g. clayg ring talk. but maybe others feel they needed more of an on-ramp to some topics.
21:36:13 <notmyname> yeah
21:36:27 <notmyname> what do you wish for the next summit?
21:36:41 <acoles> not to talk about fast-post ;)
21:36:46 <clayg> lol
21:37:03 <notmyname> lol
21:37:11 <kota_> lol
21:37:20 <notmyname> #agreed merge fast-POST before the next summit
21:37:21 <notmyname> ;-)
21:37:21 <acoles> seriously, more chairs in the room.
21:37:27 <clayg> what room?
21:37:32 <clayg> less chairs in the room
21:37:36 <clayg> more whiteboards
21:37:44 <clayg> are we talking about Friday or Thursday
21:37:50 <notmyname> wed/thurs
21:37:50 <zaitcev> I dunno, if I didn't hear you explain it, I would never get why 1 timestamp causes irreconcileable difference between nodes. The spec is impregnable sadly. So maybe it needs talkig about until it's in.
21:38:03 <acoles> Weds/Thursday - I don't like seeing people having to sit on floor
21:38:15 <notmyname> acoles: yeah, I agree there
21:38:23 <jrichli> larger tables would be nice too - to use laptop
21:38:29 <acoles> Friday I would say get rid of all furniture except whiteboards
21:38:39 <clayg> acoles: yeah - i think that's an artifact of the "working session" - we had a bunch of people show up for encyrption that don't show up for swift generally - it should have been a fishbowl
21:38:50 <jrichli> friday was a little chaotic, but I dont really have any good suggestions.  it shouldn't be formal, either.
21:38:51 <clayg> acoles: heh - maybe
21:38:52 <acoles> clayg: yep
21:39:31 <notmyname> thanks for all the feedback. anything else to add about the summit before we move on?
21:39:46 <blmartin> schedule the meetings so we can get food before its all gone D:
21:39:54 <notmyname> lol
21:40:08 <tdasilva> overall I was just glad to see so many people interested in swift...don't think people were expecting to have so many folks, so that's why it felt so cramped in there???
21:40:14 <zaitcev> I think this was about as good as they come and tweaking it may ruin next summit. However, I remember that at hackathon at SwiftStack offices it was quite useful to do breakouts into separate rooms where participants could really focus, in case topic was challenging.
21:40:40 <zaitcev> This may be not feasible in Summit venue, but if we can get it, it would be super, IMHO.
21:40:52 <tdasilva> and thanks to kota_ for being a great host!!!
21:40:53 <notmyname> zaitcev: no, swiftstack will not host the summit at our office
21:41:03 <notmyname> yes! kota_ did a great job! thanks!
21:41:08 <kota_> :-)
21:41:19 <clayg> kota_: !!++!!
21:41:35 <hrou> Yea kota_ it was really awesome thanks so much !
21:42:02 <minwoob_> +1
21:42:23 <notmyname> #topic swift-init return codes
21:42:26 <kota_> i can write a report "Swifters were sufficient"
21:42:41 <notmyname> patch 230352
21:42:41 <patchbot> notmyname: https://review.openstack.org/#/c/230352/ - swift-init return codes
21:42:51 <notmyname> clayg: you want to run this discussion?
21:43:06 <clayg> yeah so there's things legacy beahvior that's stupid
21:43:15 <clayg> i tried to change it once and redbo made me put it back
21:43:24 <clayg> and now distro's are complaining
21:43:46 <clayg> we could fix it - and maybe redbo less happy - maybe you too if you have a script that's effected (I checked I don't)
21:43:54 <clayg> or we could work around it - and live with the cruft
21:44:05 <clayg> normally we just live with the cruft - but meh
21:44:09 <clayg> any opinions?
21:44:13 <notmyname> swift-init all start will start everything that has a config
21:44:30 <notmyname> the proposal is to make that fail with an exit code if a config for a referenced server isn't found
21:44:50 <clayg> well "referenced" is maybe a strong word
21:44:50 <zaitcev> RDO and Fedora prohibit swift-init anyway, so from my perspective you can tweak it as much as you want
21:44:52 <notmyname> the question is if we need the first one or if we can move to the 2nd (which is what distros want, it seems)
21:45:11 <zaitcev> just as long as you don't make it completely brain dead
21:45:28 <clayg> I think rax does "swift-init all start" on object nodes and may still expect non-zero exit even if they only have /etc/hummingbird
21:45:50 <clayg> er.. still expect successful exit
21:45:51 <clayg> who knows
21:45:53 <notmyname> ...and no RAX dev is here
21:46:16 <notmyname> I think the interesting doc reference in the reviews is about the LSB standards
21:46:23 <zaitcev> (we tell users to avoid swift-init because launching with it inherits wrong SElinux context)
21:46:32 <cschwede> well, maybe added the RAX devs simply to the review?
21:46:39 <clayg> I think some daemons (like container-sync) are optional - it's possible swift-init all start would exit non-zero if you don't have a [container-sync] config section
21:46:42 <cschwede> asking them on their opinion?
21:46:55 <cschwede> s/added/add/
21:47:00 <clayg> cschwede: the idea was we could get that opinion in this meeting
21:47:23 <clayg> where the fuck is dfg redbo hurricanerick or nadeem or alan or btorch ;a;sdlkfj;laksdjf
21:47:32 <clayg> er... alex sorry
21:47:55 <clayg> oh well - i tried - I'll put my opinion on it (whenever I decide what that is) and we'll go from there
21:48:01 <clayg> I'll probably just say live with the cruft
21:48:08 <clayg> to easy to punt the pain on future me
21:48:25 <notmyname> FWIW, I think making it more inline with other init scripts to error on config not found is reasonable
21:48:49 <notmyname> acoles: does helion use swift-init?
21:48:55 <acoles> notmyname: clayg i need to speak to people here to know for sure if we care either way
21:49:00 <clayg> tdasilva: what about swift-on-file doesn't it like not run the auditor or something?
21:49:03 <notmyname> acoles: thanks
21:49:10 <acoles> added myself to review
21:49:18 <zaitcev> that's main vs. rest isn't it
21:49:34 <notmyname> zaitcev: all main and rest are the aliases that are there
21:49:49 <acoles> notmyname: off top of my head i don't recall if we use it
21:50:11 <clayg> you know maybe we could fix it so that if you *don't* use an alias then --strict is implied
21:50:23 <clayg> so swift-init all start will make all configured services start
21:50:24 <tdasilva> clayg: I need to double check our product docs, but I think we tell users to use 'service start'
21:50:31 <clayg> but swift-init object start will error if you don't have a config
21:50:47 <clayg> ^ which I think would achive the goal of the author
21:50:49 <notmyname> clayg: that also seems reasonable
21:51:09 <notmyname> clayg: do you want to move forward with that?
21:51:15 <clayg> ok, so "do both" - should have thought of that before hand
21:51:18 <peterlisak> clayg, yep that's the goal
21:51:24 <clayg> peterlisak: !
21:51:33 <notmyname> great. go forth and "do both"
21:51:38 <clayg> peterlisak: yeah so let's do that maybe - seems like a good way to punt on concensus
21:51:41 <notmyname> last topic
21:51:46 <notmyname> #topic keymaster name
21:51:55 <notmyname> jrichli: you ran into the hard problem of naming
21:51:57 <clayg> I'm *pretty* sure no one was epecting swift-init proxy start to exit zero when it didn't start the proxy
21:52:06 <acoles> jrichli: keymaster
21:52:09 <clayg> stupid naming things - this is why we have replicanths
21:52:16 <notmyname> jrichli: keymaster
21:52:19 <jrichli> yes.  we are planning on having a "less trivial" keymaster now
21:52:23 <clayg> jrichli: keymaster
21:52:27 <clayg> ^ why are we doing that?
21:52:28 <jrichli> hello ..
21:52:31 <jrichli> :-)
21:52:34 <clayg> oh naming the keymaster
21:52:56 <jrichli> so, what should this new "simple" keymaster be called?
21:52:58 <notmyname> keymaster vs simple_keymaster vs keymaster_v1 vs ??
21:53:04 <clayg> Gozer
21:53:05 <jrichli> just "keymaster"?
21:53:11 <jrichli> :-p
21:53:23 <acoles> jrichli: the other names imply simplicity or future versions neither of which may turn out to be true
21:53:25 <jrichli> mabye
21:53:29 <notmyname> the point of the keymaster we talked about last week is to provide enough functionality for the operator-level feature (cluster has access to the key, probably in a config)
21:53:34 <acoles> jrichli: and "keymaster" is less key strokes :)
21:53:37 <jrichli> acoles: ah.  gotcha
21:53:58 <blmartin> basic_keymaster decent_keymaster acceptable_keymaster
21:53:59 <notmyname> so trivial_keymaster that isn't supposed to be used in prod (a la tempauth) isn't right
21:54:09 <jlhinson> less_trivial_keymaster
21:54:14 <clayg> Gozer
21:54:19 <clayg> *the* keymaster
21:54:42 <jrichli> i would go with Gozer ...  why not
21:54:46 <jrichli> well, gozer
21:55:03 <clayg> http://ghostbusters.wikia.com/wiki/Vinz_Clortho
21:55:14 <jrichli> then we can use the word "keymaster" to represent whichever one actually gets loaded
21:55:16 <clayg> ^ this is me *not* being helpful
21:55:28 <notmyname> just "keymaster"
21:55:38 <clayg> ^ this is notmyname being helpful
21:55:59 <jrichli> ok.  but then there wont be a generic form
21:56:13 <clayg> it's full name is swift.common.middleware.keymaster.KeyMaster - but we just call him the "key-man" for short
21:56:30 <blmartin> keyapprentice
21:56:42 <notmyname> jrichli: I'm not too worried about building extensibility for something not yet implemented into a name of something else not yet implemented fully
21:56:48 <acoles> clayg: if you like vinz then go +A this https://review.openstack.org/183014
21:56:59 <jrichli> gotcha
21:57:17 <clayg> acoles: nice
21:57:18 <acoles> keymistress ?
21:57:22 <notmyname> point is, use keymaster and make future-me solve any future-problems that come up. for now, we need a keymaster, and "keymaster" makes more sense than "steve" or "bob"
21:57:29 <hrou> + 1 to just keymaster ; )
21:57:41 <clayg> swift.common.middleware.keymaster.KeyMaster is a great name
21:57:44 <jrichli> ok.  agreed.
21:57:47 <blmartin> honestly keymaster sounds great
21:57:56 <notmyname> briancline: do you use swift-init in prod?
21:58:09 <notmyname> great. agreed on "keymaster" then
21:58:22 <notmyname> #agreed the keymaster should be called "keymaster"
21:58:30 <acoles> lol
21:58:30 <briancline> notmyname: yeah
21:58:36 <clayg> ^ so much better than replicanth
21:58:48 <jrichli> lol
21:58:55 <notmyname> briancline: clayg is goign to ask you a question about swift-init in the #openstack-swift channel
21:59:35 <notmyname> and peterlisak ^
21:59:47 <notmyname> thanks everyone for coming today
21:59:54 <notmyname> it was great to see (most of) you last week!
21:59:58 <notmyname> thanks for working on swift
22:00:01 <notmyname> #endmeeting