| *** kumarmn has joined #openstack-tc | 00:17 | |
| openstackgerrit | Zane Bitter proposed openstack/governance master: Clarify new project requirements for affiliation diversity https://review.openstack.org/567944 | 00:27 |
|---|---|---|
| *** kumarmn has quit IRC | 00:29 | |
| *** edmondsw has joined #openstack-tc | 00:38 | |
| openstackgerrit | Zane Bitter proposed openstack/governance master: Minor grammatical fixes to new project requirements https://review.openstack.org/571344 | 00:40 |
| *** edmondsw has quit IRC | 00:43 | |
| *** harlowja has quit IRC | 01:19 | |
| *** mriedem_afk has quit IRC | 01:23 | |
| *** spotz has joined #openstack-tc | 01:29 | |
| spotz | dtroyer: You about? | 01:29 |
| *** kumarmn has joined #openstack-tc | 02:18 | |
| *** edmondsw has joined #openstack-tc | 02:26 | |
| *** edmondsw has quit IRC | 02:31 | |
| *** kumarmn has quit IRC | 02:48 | |
| *** kumarmn has joined #openstack-tc | 02:50 | |
| *** kumarmn has quit IRC | 02:58 | |
| *** kumarmn has joined #openstack-tc | 03:29 | |
| *** kumarmn has quit IRC | 03:33 | |
| *** ianychoi has quit IRC | 03:51 | |
| *** kumarmn has joined #openstack-tc | 04:02 | |
| *** rosmaita has quit IRC | 04:02 | |
| *** kumarmn has quit IRC | 04:07 | |
| *** edmondsw has joined #openstack-tc | 04:14 | |
| *** edmondsw has quit IRC | 04:19 | |
| *** kumarmn has joined #openstack-tc | 04:33 | |
| *** kumarmn has quit IRC | 04:38 | |
| *** kumarmn has joined #openstack-tc | 05:13 | |
| *** kumarmn has quit IRC | 05:17 | |
| *** ricolin has joined #openstack-tc | 05:33 | |
| *** jaosorior has quit IRC | 05:58 | |
| *** edmondsw has joined #openstack-tc | 06:03 | |
| *** edmondsw has quit IRC | 06:07 | |
| *** jaosorior has joined #openstack-tc | 06:14 | |
| *** kumarmn has joined #openstack-tc | 06:21 | |
| *** kumarmn has quit IRC | 06:26 | |
| *** kumarmn has joined #openstack-tc | 06:58 | |
| *** kumarmn has quit IRC | 07:03 | |
| *** kumarmn has joined #openstack-tc | 07:31 | |
| *** ianychoi has joined #openstack-tc | 07:32 | |
| *** kumarmn has quit IRC | 07:36 | |
| *** edmondsw has joined #openstack-tc | 07:51 | |
| *** jpich has joined #openstack-tc | 07:55 | |
| *** edmondsw has quit IRC | 07:56 | |
| *** kumarmn has joined #openstack-tc | 08:08 | |
| *** kumarmn has quit IRC | 08:12 | |
| *** diablo_rojo has quit IRC | 08:21 | |
| *** kumarmn has joined #openstack-tc | 08:39 | |
| *** kumarmn has quit IRC | 08:43 | |
| *** kumarmn has joined #openstack-tc | 09:48 | |
| *** ttx has quit IRC | 09:52 | |
| *** kumarmn has quit IRC | 09:53 | |
| *** ttx has joined #openstack-tc | 10:11 | |
| *** ttx has quit IRC | 10:14 | |
| *** ttx has joined #openstack-tc | 10:14 | |
| *** gcb has quit IRC | 10:36 | |
| *** rosmaita has joined #openstack-tc | 11:07 | |
| *** ttx has quit IRC | 11:07 | |
| *** ttx has joined #openstack-tc | 11:08 | |
| *** edmondsw has joined #openstack-tc | 11:27 | |
| *** edmondsw has quit IRC | 11:31 | |
| *** ttx has quit IRC | 11:34 | |
| *** ttx has joined #openstack-tc | 11:35 | |
| *** ttx has quit IRC | 11:47 | |
| *** ttx has joined #openstack-tc | 11:47 | |
| *** edmondsw has joined #openstack-tc | 11:47 | |
| *** ttx has quit IRC | 11:51 | |
| *** ttx has joined #openstack-tc | 11:51 | |
| *** kumarmn has joined #openstack-tc | 12:08 | |
| *** kumarmn has quit IRC | 12:13 | |
| dims | dhellmann : ttx : for the job description, i can write one up for a stable maintainer and we can iterate on it. sounds good? | 12:19 |
| dims | (or) is there another project we want to start with? (glance?) | 12:19 |
| dhellmann | dims : stable maint seems like a good place to start. we should work with the project PTLs to describe the roles from their perspective | 12:48 |
| dims | right | 12:51 |
| dims | we need a template for them to fill in | 12:52 |
| * TheJulia wonders why we need a template | 12:52 | |
| TheJulia | I agree stable maintainer is likely a good place to start, but it would seem to me that these could vary from a single paragraph to several paragraphs depending on the void we are looking to fill | 12:53 |
| dhellmann | if we want them all to include things like why the role is important, what the duties are, what skills might be needed, how to reach the relevant team, etc. then we could spell that out | 12:55 |
| dhellmann | I agree the actual content is going to vary, though | 12:55 |
| mnaser | with my business hat on, i think it's critical to demonstrate the importance of the role in the ecosystem | 12:55 |
| mnaser | 'without stable maintainers, we won't have a very stable release so the next time you upgrade, things might break' | 12:56 |
| dhellmann | yes, that was definitely the most important thing I took away from the meeting | 12:56 |
| mnaser | 'without resources to the glance project, the project could fall behind and then the development of nova will fall behind because it depends on glance heavily' | 12:56 |
| mnaser | etc | 12:56 |
| mnaser | i can help with some of that by looking things over after | 12:56 |
| TheJulia | In retrospect, I agree a template is a good idea | 12:57 |
| *** kumarmn has joined #openstack-tc | 13:01 | |
| dims | TheJulia : mnaser : i was browsing for volunteer/skills matching websites like this one for inspiration - https://www.catchafire.org/volunteer/20706/350-seattle--google-apps-setup/ | 13:07 |
| *** mriedem has joined #openstack-tc | 13:07 | |
| TheJulia | dims: I _really_ like that | 13:09 |
| fungi | neat idea, yes | 13:10 |
| dims | thanks fungi TheJulia . another example was https://www.sparked.com/find which is more free form request | 13:12 |
| smcginnis | I really like that catchafire format. | 13:13 |
| TheJulia | I get a sign-in screen instead :\ | 13:14 |
| smcginnis | Yeah, looks like sparked.com requires a login. | 13:14 |
| dims | oops sorry | 13:14 |
| dims | https://www.evernote.com/l/AZxrZqjYtZVDoKmxl4YtCtpKn3dosmNQppw | 13:15 |
| dims | screen shot ^ | 13:15 |
| dims | we need a cross between those kinds of things and a traditional job description (say the one from dhellmann/redhat that triggered this - https://lensa.com/senior-software-engineer-openstack-oslo-project-jobs/raleigh/jd/4df8ce1a7f0adf1ecb77ab32ef1f3a29) | 13:16 |
| dims | dhellmann : smcginnis : fungi : TheJulia : here's what i have so far - https://etherpad.openstack.org/p/job-description-template | 13:33 |
| smcginnis | dims: Nice, I like it! | 13:34 |
| smcginnis | Really like the communication channels, time zones, and mentor bits. | 13:34 |
| smcginnis | I think all of those will be important. | 13:34 |
| dims | thanks Sean | 13:41 |
| dhellmann | dims : I like the list. I wonder if "How This Will Help" should appear closer to the top. | 13:46 |
| dhellmann | maybe as the 2nd item? | 13:46 |
| dims | +1 | 13:47 |
| dims | please feel free to edit too | 13:47 |
| dhellmann | as part of looking at change management best practices to provide some better suggestions about how to communicate about adding new projects like starlingx, I came across this HBR article from 1990. The 6 steps they list map pretty well to what we've observed working for our community. https://hbr.org/1990/11/why-change-programs-dont-produce-change | 13:49 |
| TheJulia | dims: I like it, I'm not sure all of the fields will always be needed, but they are also good to point out. | 13:51 |
| dims | right | 13:51 |
| TheJulia | like, most people don't think about time zones too | 13:51 |
| dims | ack let me find Chris Price and loop him in | 13:54 |
| smcginnis | dhellmann: That bank might have been one of them discussed in Good to Great. | 13:54 |
| dhellmann | I've heard of Good to Great but I don't think I've read it | 13:55 |
| *** hongbin has joined #openstack-tc | 13:56 | |
| * dims queues up the HBR article | 13:56 | |
| mnaser | super silly, unrelated-but-kinda-related to the nitpicking thread, how would we feel about removing the red color of -1 in gerrit reviews | 14:09 |
| mnaser | in the subject of not feeling intimidated by -1s, i think them not being there glaring in red might feel a lot less "this is wrong" | 14:10 |
| mnaser | i know it sounds silly, but i think this sort of thing might have some small impact. | 14:10 |
| fungi | we could make them green so they look as friendly as a +1? ;) | 14:10 |
| dims | -1 is the new black :) | 14:11 |
| cmurphy | fungi: that sounds confusing :P | 14:11 |
| * cmurphy opts for purple | 14:11 | |
| mnaser | especially for new contributors, having a big red thing sitting on your review might be very discouraging | 14:11 |
| dims | cmurphy : purple is strong, orange seems to work better | 14:13 |
| smcginnis | <blink>-1</blink> | 14:13 |
| * dims toying with editing css/html | 14:13 | |
| dims | LOL smcginnis | 14:14 |
| mnaser | <marquee> | 14:14 |
| smcginnis | :) | 14:14 |
| mnaser | bring back geocities website | 14:14 |
| smcginnis | mnaser: No kidding! :D | 14:14 |
| dims | exactly my thought mnaser | 14:14 |
| fungi | can we use an animated gif of a -1 on fire? | 14:15 |
| fungi | that would be very geocities | 14:15 |
| mnaser | https://imgur.com/a/EzUj5fd | 14:16 |
| mnaser | here is a few suggestions based on the colors | 14:16 |
| fungi | keep in mind that color choices are very much culture-specific. for chinese contributors the red probably looks very friendly and not at all negative | 14:16 |
| mnaser | i think it's a lot less "YOUR STUFF IS BROKEN" than red | 14:16 |
| mnaser | that's a good point too | 14:16 |
| mnaser | but generally red => error, like the glaring "Merge Conflict" stuff too, but yeah | 14:17 |
| mnaser | nothing against jay though i just found a random review that had a -1 :D | 14:17 |
| fungi | in my opinion, a better argument against red/green schemes is that there are a significant number of people whose eyes can't differentiate those colors from each other | 14:17 |
| dims | indeed fungi | 14:18 |
| smcginnis | ++ | 14:19 |
| fungi | perhaps i'm just callous, but i'm not actually worried some new contributor is going to have a nervous breakdown because of the color of the -1 on their patch | 14:19 |
| fungi | they're far more likely to be upset by negative tone in the comments they get than the symbol or its color | 14:21 |
| smcginnis | I think you're right fungi | 14:22 |
| fungi | it's far too tempting to gravitate toward ineffectual things which are easy for us to change than things like human behavior | 14:23 |
| fungi | s/gravitate toward/focus on/ | 14:27 |
| *** gcb has joined #openstack-tc | 14:44 | |
| * TheJulia finally has coffeeeeeeeeee | 14:52 | |
| TheJulia | cmurphy: +1 to purple | 14:53 |
| cmurphy | :D | 14:54 |
| TheJulia | mnaser: I do kind of like the idea of delineating ERROR versus needs more work | 14:54 |
| mnaser | TheJulia: maybe we need to communicate that a -1 means more work and -2 means this is functionally incorrect | 14:54 |
| TheJulia | at that point though, we would need a -3 hard block | 14:55 |
| *** mriedem has quit IRC | 14:55 | |
| dhellmann | don't the built-in messages attached to -1 and -2 already clearly describe the differences? | 14:55 |
| TheJulia | I guess the issue there is the built in messages don't always map to actual human behaviors of what they should look at | 14:56 |
| EmilienM | hello | 14:57 |
| * EmilienM for once can make the office hour | 14:57 | |
| fungi | the tooltip you get when hovering over the scores say "this patch needs further work before it can be merged" for code review -1 and "doesn't seem to work" for verified -1 | 14:58 |
| fungi | i'm not sure how much more explicit we can make it? | 14:59 |
| fungi | and code review -2 is simply "do not merge" | 15:00 |
| zaneb | o/ | 15:00 |
| TheJulia | The conundrum is actually getting people to look at -1'ed patches | 15:00 |
| smcginnis | It's about that time. | 15:00 |
| dhellmann | who wants to start the office hours meetbot? | 15:00 |
| fungi | #startmeeting tc | 15:00 |
| openstack | Meeting started Thu May 31 15:00:58 2018 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| smcginnis | #startmeeting tc | 15:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| *** openstack changes topic to " (Meeting topic: tc)" | 15:01 | |
| TheJulia | is o/ | 15:01 |
| openstack | The meeting name has been set to 'tc' | 15:01 |
| TheJulia | err | 15:01 |
| openstack | smcginnis: Error: Can't start another meeting, one is in progress. Use #endmeeting first. | 15:01 |
| dhellmann | thanks, fungi & smcginnis | 15:01 |
| fungi | #chair smcginnis | 15:01 |
| openstack | Current chairs: fungi smcginnis | 15:01 |
| smcginnis | :) | 15:01 |
| fungi | #chair dhellmann | 15:01 |
| openstack | Current chairs: dhellmann fungi smcginnis | 15:01 |
| fungi | #chair TheJulia | 15:01 |
| openstack | Current chairs: TheJulia dhellmann fungi smcginnis | 15:01 |
| *** mriedem has joined #openstack-tc | 15:01 | |
| fungi | #chair zaneb | 15:01 |
| openstack | Current chairs: TheJulia dhellmann fungi smcginnis zaneb | 15:01 |
| fungi | #chair EmilienM | 15:01 |
| openstack | Current chairs: EmilienM TheJulia dhellmann fungi smcginnis zaneb | 15:01 |
| cmurphy | start all the meetings | 15:01 |
| dhellmann | #chair cmurphy | 15:01 |
| openstack | Current chairs: EmilienM TheJulia cmurphy dhellmann fungi smcginnis zaneb | 15:01 |
| fungi | #chair cmurphy | 15:01 |
| openstack | Current chairs: EmilienM TheJulia cmurphy dhellmann fungi smcginnis zaneb | 15:01 |
| fungi | #chair mnaser | 15:01 |
| openstack | Current chairs: EmilienM TheJulia cmurphy dhellmann fungi mnaser smcginnis zaneb | 15:01 |
| ttx | ohai | 15:01 |
| smcginnis | Our ping list has become a chair list. :) | 15:01 |
| fungi | looks like we have a bunch of tc members around around | 15:02 |
| dhellmann | heh, that's one way to do it | 15:02 |
| fungi | extra around | 15:02 |
| fungi | #chair ttx | 15:02 |
| openstack | Current chairs: EmilienM TheJulia cmurphy dhellmann fungi mnaser smcginnis ttx zaneb | 15:02 |
| fungi | to be fair, it made more sense to add all two present tc members as chairs during the last office hour ;) | 15:02 |
| dhellmann | the more the merrier | 15:03 |
| dhellmann | we have several items on our tracker list without drivers (or with only 1). what should we do about that? https://wiki.openstack.org/wiki/Technical_Committee_Tracker | 15:03 |
| smcginnis | Did the bylaws correction get done? | 15:04 |
| dhellmann | the board passed a resolution authorizing jbryce to deal with it as part of the next election | 15:04 |
| fungi | bylaws correction next step is making sure it gets on the next ballot for board elections | 15:04 |
| EmilienM | fungi, ttx : have we already created a story about "Reviewing the TC Vision" ? | 15:04 |
| dhellmann | I thought we would want to keep tracking it to ensure that correction makes it onto the ballot, and fungi signed up for that | 15:04 |
| fungi | EmilienM: i haven't yet and not aware of one, that would be great to have | 15:05 |
| EmilienM | if no, I'll go ahead and do it (+ update Wiki), maybe we could start poking at it today | 15:05 |
| smcginnis | Yeah, that makes sense to follow it through to completion. | 15:05 |
| dhellmann | oh, yes, please add links to relevant stories in the wiki | 15:05 |
| openstackgerrit | Samuel Cassiba proposed openstack/governance master: Add openstackclient to Chef OpenStack https://review.openstack.org/571504 | 15:06 |
| TheJulia | dhellmann: I think for some of them, I think we need to see if someone steps forward. It is also the week after summit and people are likely still decompressing/processing last week | 15:06 |
| dhellmann | sure. | 15:06 |
| dhellmann | I didn't know if we wanted to ask people to sign up, move unowned things to a separate list, or something else. | 15:07 |
| TheJulia | I think we should broadcast that we would like someone to step forward for these items, and kind of revisit it in a week. | 15:07 |
| ttx | EmilienM: it's on dhellmann's wiki already | 15:09 |
| TheJulia | That way we're also possibly growing the pool of potential leaders as time moves on/giving opportunities. | 15:09 |
| ttx | EmilienM: oh, you mean add link ? Yes++ | 15:09 |
| EmilienM | ttx: doing it now | 15:09 |
| ttx | EmilienM: I'll create an etherpad where we can dump the current vision and then add comment | 15:10 |
| dhellmann | TheJulia : are you suggesting that we ask folks not on the TC to take these up? | 15:10 |
| TheJulia | We had discussed in the past that we felt that it was acceptable for non-tc members to take up causes and work with the TC | 15:10 |
| dhellmann | I don't have a problem with us asking for help, but these are the things we said we wanted to do, so I think we should have TC members attached to each of them. | 15:11 |
| TheJulia | if that is no longer the case, then we have a limited pool of resources. | 15:11 |
| dhellmann | that's why I called them "drivers" and not "owners" | 15:11 |
| EmilienM | ttx: works for me, it can be faster than using Gerrit for now. | 15:11 |
| TheJulia | dhellmann: I see your point, I would just worry about drivers being looked at like owners | 15:12 |
| dhellmann | it's hard for me to reconcile a desire to be more active with the idea that we wouldn't do things. :-) | 15:12 |
| dhellmann | maybe we should have the conversation about what % of time TC members feel they have to contribute, and whether that should have some effect on the length of our todo list | 15:13 |
| dhellmann | perhaps some of these things are backlog items, and not actively being worked on, for example | 15:14 |
| cmurphy | what is "Trove Project Health"? I was in that session but I'm not sure what actions should be taken around that | 15:14 |
| dhellmann | zaneb thought he was the one who brought that up, but I didn't remember. the question was "is anyone actually working on trove any more?" | 15:15 |
| TheJulia | dhellmann: that is a valid point, we can't take on the world... at least not without prioritization and planning :) | 15:15 |
| dhellmann | it relates to the thing we talked about thursday of checking in on project teams more actively | 15:15 |
| ttx | dhellmann: I heard that question from a bunch | 15:16 |
| TheJulia | dhellmann: cmurphy: I believe the comment is that there is nobody working on it any longer, and that maintainers and contributors are needed | 15:16 |
| TheJulia | s/is/was/ | 15:16 |
| dhellmann | I took a peek in gerrit and saw what looked like relatively recent reviews landed, but it still seemed like enough of a question that I left it on the list | 15:16 |
| TheJulia | Someone raised ?Amrith?, but... yeah. | 15:16 |
| smcginnis | I thought a team from IBM took up Trove when amrith had proposed moving it to unmaintained. | 15:17 |
| ttx | To the point where a "Stop or encore" session would have been good at forum | 15:17 |
| ttx | smcginnis: yes | 15:17 |
| TheJulia | dhellmann: good plan then | 15:17 |
| dhellmann | who wants to check in on the trove team and report back? | 15:17 |
| TheJulia | I can put that on my todo list | 15:17 |
| mnaser | https://review.openstack.org/#/c/526728/ -- looks like they're still kinda landing things | 15:18 |
| dhellmann | thanks, TheJulia! | 15:18 |
| fungi | yeah, i think the worry is that trove engagement hasn't continued since the new team was put in control. if memory serves we had nobody in vancouver to run the trove sessions | 15:18 |
| ttx | I have history, can take Trove too | 15:18 |
| mnaser | but 6 weeks before that was the last merge | 15:18 |
| dhellmann | great, please put your names in the wiki, ttx & TheJulia | 15:18 |
| dhellmann | let's not do it *now* | 15:18 |
| zaneb | the last I heard Trove was in 'maintenance mode' and there is no new development, but it is maintained. I haven't actually checked so I don't know that this is the case | 15:18 |
| ttx | OVH has ben considering taking it over, which is why I looked into it | 15:18 |
| fungi | #link https://governance.openstack.org/tc/reference/tags/status_maintenance-mode.html | 15:19 |
| TheJulia | It would be good to have an operator get involved | 15:19 |
| fungi | only searchlight has that governance tag applied at the moment | 15:19 |
| zaneb | people (possibly including me) might have used the word 'unmaintained' to describe that, but at least in my case it wasn't based on any new information | 15:19 |
| * dhellmann was hoping to use this time for team organization, not a deep dive into trove | 15:19 | |
| ttx | I think at this point they don't dare taking it over, but we could encourage them if it's in bad shape | 15:20 |
| ttx | hehe | 15:20 |
| dhellmann | smcginnis , I have a ? next to your name on the stein goals item. did you want to help drive that? | 15:20 |
| TheJulia | dhellmann: next item! :) | 15:20 |
| * ttx now sees how fun it is to disrupt the chair | 15:20 | |
| mnaser | dhellmann: maybe that's why we'd need an actual meeting with an agenda besides office hours :> | 15:20 |
| mnaser | but back on track | 15:20 |
| dhellmann | mnaser : there is 1 topic on our agenda today: sort out this todo list! :-) | 15:20 |
| mnaser | fair :) | 15:21 |
| dhellmann | we more or less agreed to always pair up on items, and we have a lot with only 1 driver | 15:21 |
| EmilienM | ttx: i've noticed that https://www.openstack.org/software/sample-configs redirects to projects from ocata | 15:21 |
| dhellmann | do people still feel like pairing is a good way to ensure depth of coverage and to support each other? and important enough to do? | 15:21 |
| EmilienM | ttx: we might want to update it to Quees, perhaps | 15:21 |
| ttx | EmilienM: will signal it | 15:22 |
| smcginnis | dhellmann: Yes, I will update that to remove the ? | 15:22 |
| mnaser | dhellmann: i think it's beneficial being able to lean on someone else who will hopefully be intimately familiar with the topic | 15:22 |
| dhellmann | smcginnis : thanks | 15:22 |
| dhellmann | mnaser : good point | 15:22 |
| EmilienM | ttx: are these our constellations? they look like it anyway | 15:22 |
| mnaser | so i support taking items that have a single driver and aiming for at least two | 15:22 |
| zaneb | dhellmann: how long are we planning to keep around stuff that is marked as Approved in the list? | 15:23 |
| dhellmann | zaneb : until I send the next TC update email on Monday | 15:23 |
| dhellmann | I skipped this week because there were so many forum update emails already | 15:23 |
| zaneb | that makes a lot of sense :) | 15:23 |
| ttx | EmilienM: kind of -- depends on what we mean by constellation :) | 15:24 |
| dhellmann | ok, as TheJulia pointed out we probably have a few people on PTO after the summit, so I won't stress too much about these not having drivers until next week | 15:25 |
| dhellmann | did I miss anything other than the work dims has started on writing up job descriptions for the help-wanted areas? | 15:26 |
| dhellmann | I will add that item after I send my summary of the joint leadership meeting, if dims doesn't beat me to it | 15:26 |
| dims | no rush dhellmann :) | 15:26 |
| dims | got some feedback from Chris Price on email | 15:27 |
| dhellmann | maybe we want to move on to other topics, then? | 15:27 |
| dhellmann | oh, good | 15:28 |
| zaneb | when is it kosher to post info from the board meeting? usually jbryce posts a summary, but he wasn't actually there... | 15:29 |
| dhellmann | there are different rules for the board meeting, I think | 15:29 |
| dhellmann | the board asks members not to post summaries before the official minutes are posted, I think? | 15:30 |
| smcginnis | I thought we discussed that recently and heard board members need to wait for jbryce to post a summary, but non-board do not? | 15:30 |
| dhellmann | but I don't think that applies to the joint leadership meeting, since that's not a board meeting | 15:30 |
| dhellmann | I was going to post an email summary based on my own notes as a personal summary | 15:30 |
| zaneb | as a participant in the meeting, I would feel uncomfortable posting a summary before other participants (i.e. board members) are allowed to | 15:31 |
| fungi | right. yeah, official minutes will presumably eventually appear at | 15:31 |
| fungi | #link https://wiki.openstack.org/wiki/Governance/Foundation/20May2018BoardMinutes | 15:31 |
| dhellmann | zaneb : right, my point is that the rule on official minutes does not apply here | 15:31 |
| dhellmann | we met with the board, but it was not an operating meeting of the board of directors | 15:31 |
| dhellmann | *part* of the day was, but I wasn't in the room then so my summary won't cover that anyway | 15:32 |
| mnaser | yeah, afaik it is a "joint leadership meeting" | 15:32 |
| fungi | but only the board members (and possibly foundation staff?) are expected to refrain from making public comments before the minutes are posted | 15:32 |
| zaneb | well, there was a roll call and a motion was approved | 15:32 |
| zaneb | while we were there | 15:32 |
| dhellmann | yes, true, that portion of the meeting was more official than the rest | 15:32 |
| fungi | oh, right that too. there _was_ a board meeting, but it was at the very end of the day, lasted a handful of minutes and involved nothing of substance | 15:32 |
| mnaser | do we want to confirm with the board to have a clear understanding? | 15:32 |
| dhellmann | the agenda that day was a bit messy | 15:32 |
| dhellmann | ok, I'll ask Alan before I post anything | 15:33 |
| mnaser | maybe this is part of increasing communication with our board :) | 15:33 |
| dhellmann | #action dhellmann to ask Alan about posting a summary of the joint leadership meeting | 15:33 |
| dhellmann | the review https://review.openstack.org/564060 about goal champions needs 1 more vote, so please take a look at that when you have time | 15:34 |
| dhellmann | what else is on your minds this week? | 15:36 |
| TheJulia | dhellmann: you have the extra vote now | 15:37 |
| fungi | now that the summit's over and there's been no objection to the related ml thread, i was going to propose the base services addition change for a castellan-compatible key store | 15:38 |
| ttx | ++ | 15:38 |
| dhellmann | TheJulia : thanks | 15:38 |
| * ttx crosses one more item from his giant list | 15:38 | |
| dhellmann | fungi : ++ | 15:39 |
| fungi | #link http://lists.openstack.org/pipermail/openstack-dev/2018-May/130567.html key store in base services | 15:39 |
| zaneb | fungi: are we going to specify which key store? | 15:39 |
| fungi | was the start of the thread where it was suggested | 15:39 |
| dhellmann | fungi : I'm not sure what services that means today, so we probably want to make it clear that we welcome new drivers in castellan to cover other services that people want to be able to use | 15:39 |
| fungi | zaneb: consensus so far seemed to be around "a castellan-compatible key store" without specifying any one in particular | 15:40 |
| mnaser | one concern that i have is.. i feel like castellan is this extra layer of api abstraction on top of barbican, a secret store that abstracts other api stores | 15:40 |
| zaneb | ok, that makes sense | 15:40 |
| mnaser | afaik castellan has a 'vault' driver, but barbican also has one too | 15:41 |
| fungi | mnaser: well, castellan was the result of complaints that barbican meant having an extra service | 15:41 |
| zaneb | when people were saying Barbican in particular I was wondering if it was more a job for constellations than base services... | 15:41 |
| mnaser | i guess this could be a start in openstack projects being able to be used independently | 15:41 |
| mnaser | which is good too | 15:42 |
| fungi | apparently some distros/deployments already have vault for other reasons and wanted a way of being able to just use it without adding a barbican service to manage | 15:42 |
| dhellmann | I see it as a bit like oslo.messaging or oslo.db: services can rely on something for which we have a driver and use the abstraction layer to avoid dictating to deployers what to actually use | 15:42 |
| zaneb | dhellmann: yeah, it's just a little bit weird in this case because an openstack service can be a backend. like if there was a Trove driver for oslo.db | 15:44 |
| dhellmann | yes, that is a bit unusual | 15:45 |
| dhellmann | I guess one difference is whether the secret is part of the deployment or something owned by an end-user | 15:45 |
| dhellmann | so if a service wants to have end-user-managed secrets for doing things like encryption, that may imply barbican is actually required as an implementation detail, even if it is a wrapper around something else | 15:46 |
| fungi | i think what we're more worried about for now is other services being able to rely on havnig somewhere safe to quarantine secrets/keys so that they don't all have to duplicate that work badly and end up neutering their security features as a result or influencing distros/operators to avoid turning on useful security features which might otherwise benefit from having it | 15:49 |
| dhellmann | sure. is there actually a difference in user-facing vs. service-only keys? or is that distinction not important? I'm not that familiar with this space or how one interacts with something like vault, but it seems odd for us to say "in order to encrypt your cinder volume, put a key in vault and then tell us about it" since vault doesn't have an "Openstack API" | 15:51 |
| dhellmann | maybe that workflow is normal and expected, though, I just don't know | 15:51 |
| ttx | The reason that Vault it plugged both at castellan and Barbican levels is because those things do not strictly overlap | 15:52 |
| dhellmann | yeah, that part made sense to me. I just wonder if saying a "castellan-supported secret store" is actually the right thing if we want services to provide features that require users to interact with the key store | 15:53 |
| fungi | dhellmann: i think the difference between user-facing and service-only is more in how we end up saying whether it's a standard feature. for service-only we have the base services list saying what other services are allowed to depend on being present. for user-facing we decide with trademark programs and interoperability testing | 15:54 |
| dhellmann | I guess I'm not being clear. | 15:54 |
| dhellmann | If a user has to create a key to use a feature in cinder, is Vault "good enough"? | 15:54 |
| dhellmann | Because if so, we're telling services that relying on having users interact with non-openstack services is OK, and I think that's a new statement? | 15:55 |
| ttx | dhellmann: I /think/ castellan will let you create a key on Vault alright | 15:55 |
| fungi | if we want services to provide features that require users to interact with the key store then it's a matter for trademark programs/interop and would probably spell out barbican as a requirement | 15:55 |
| dhellmann | ttx: castellan is a python library. it's how cinder would interact with vault. it's not how a user would. | 15:55 |
| * TheJulia wonders if the discussion is in or just above the weeds | 15:56 | |
| dims | https://github.com/openstack/castellan/blob/master/castellan/key_manager/key_manager.py#L43 - create_key | 15:56 |
| dims | and yes vault manager supports it | 15:57 |
| ttx | dims: yeah | 15:57 |
| dhellmann | TheJulia : definitely muddy water, if not weeds | 15:57 |
| dhellmann | right, castellan *can* talk to vault, but it's not a REST API | 15:57 |
| dims | correct, calls vault directly - https://github.com/openstack/castellan/blob/master/castellan/key_manager/vault_key_manager.py#L139 | 15:57 |
| fungi | from a base services perspective, we're just saying it's okay for services to rely on it, not saying anything about what those services expose (and we're not saying they're required to expose anything to the user) | 15:57 |
| dhellmann | so we would be saying that it's OK for an openstack cloud to rely on a service that has no openstack API, and that's different from the other base services that are all hidden behind the cloud's API | 15:58 |
| mnaser | i mean, in terms of interop, how would we think about ceph and it's exposed openstack 'swift' compatible api.. it's an external component providing the same functionality (kindof?) | 15:58 |
| dhellmann | ok. I just think it's not going to be useful if there's not also a way for users to actually interact with the store | 15:58 |
| fungi | i don't follow | 15:58 |
| zaneb | so what dhellmann is saying is that the secret has to pass through Cinder API->Castellan->Vault, instead of going straight to the Barbican API. and that may be a less safe way of handling it | 15:58 |
| ttx | Does Cinder volume encryption require you to provide your own key ? Or does it just generate one for you ? | 15:58 |
| mnaser | good question for smcginnis ^ ? :) | 15:58 |
| fungi | etcd has a non-openstack api and it's in the base services list | 15:58 |
| dhellmann | fungi : do we expect users to interact with etcd? | 15:59 |
| dhellmann | zaneb : yes, that's a good way of putting it | 15:59 |
| zaneb | fungi: the cloud user never has to poke any data into etcd | 15:59 |
| fungi | i'm still not following. we wouldn't be saying deployments are required to expose cinder volume encryption either way | 15:59 |
| dhellmann | do we want every service to invent its own API for creating or uploading keys? | 15:59 |
| ttx | dhellmann: hrm, isn't that what Castellan does ? | 16:00 |
| dims | dhellmann : we want them to use the common library (like oslo.db and oslo.messaging) | 16:00 |
| zaneb | fungi: if there's no OpenStack API for secrets available then every API becomes an API for secrets, proxying via Castellan on the back end | 16:00 |
| dhellmann | we do not, in any other case, require users to use our client libraries | 16:00 |
| fungi | we'd be saying it's okay for services to assume a castellan-compatible key store is available to those services, we aren't saynig anyone has to expose any particular related api to end users | 16:00 |
| ttx | Also "creating" and "uploading" are not two separate things | 16:00 |
| * TheJulia feels like people are approaching this from different contexties and that we need to actually write it down at this point | 16:01 | |
| ttx | You create keys on the secret store. | 16:01 |
| *** kumarmn has quit IRC | 16:01 | |
| dhellmann | dims : end users do not use those libraries, though | 16:01 |
| dims | dhellmann : right, they use the native stuff directly like vault or barbican | 16:01 |
| fungi | take designate's desire for this, as an example. designate would like to treat a key store as an hsm, have it generate keys and handle signing requests, without those keys ever leaving the store | 16:01 |
| fungi | that has nothing to do with end users uploading keys | 16:02 |
| zaneb | fungi: yes, that's a case that castellan works for | 16:02 |
| * smcginnis had to step away for a bit, reading scrollback | 16:02 | |
| fungi | so i really, really, really don't see where this "exposing non-openstack apis to end users" tangent is coming from | 16:02 |
| dims | it's not just vault, folks want to use castellan + custodia ( https://review.openstack.org/#/c/515190/ ) | 16:02 |
| *** kumarmn has joined #openstack-tc | 16:02 | |
| dhellmann | fungi : true. that's 1 use case. Is that the only case where being generic about the keystore is useful? | 16:02 |
| ttx | I'm sad that we keep having this "should we require Castellan or Barbican" discussion every 6 months. Last time we spent one hour on it and concluded Castellan | 16:03 |
| dims | and KMIP https://review.openstack.org/#/c/298991/ | 16:03 |
| dims | yep ttx | 16:03 |
| ttx | Now I'm missing most of the context from that discussion | 16:03 |
| dhellmann | fungi : I'm trying to understand if it is sufficient to say "castellan supported" or if that's only going to enable 1 use case. | 16:03 |
| ttx | But I remember us going into deep | 16:03 |
| fungi | in fact, the previous time we discussed it we convinced the barbican team to create castellan so that we could consider it for this purpose | 16:03 |
| zaneb | e.g. in Heat we want to be able to auth to other OpenStack clouds, which requires the user's credentials for those cloud. we don't want to see those through the Heat API, so we're going to ask the user to put them in Barbican directly | 16:04 |
| dims | with dave-mccowan and kfarr and others | 16:04 |
| dhellmann | ok, I'll let it go. I'm sorry I've been unable to express my concern in a way that folks can understand. | 16:04 |
| mnaser | if that discussion of 'castellan vs barbican' has been had and a conclusion has been reached | 16:04 |
| mnaser | maybe we should just focus on the base services discussion | 16:04 |
| zaneb | but that feature will obviously be unavailable on clouds without Barbican, even if they have Vault | 16:04 |
| dims | dhellmann : another data point, some folks like Huawei have their own barbican equivalent, so castellan is the better integration point | 16:05 |
| ttx | zaneb: right -- so THAT was raised as an unresolved issue last time. Reliance on Barbican-specific features | 16:05 |
| dhellmann | I am not suggesting that services should only talk to barbican. I am suggesting that leaving barbican out of the base services list is going to mean we have a lot of features we can't implement because we don't provide users a way to deal with keys *or* that we will have a lot of services adding their own APIs for dealing with keys. Both are reasons we have the list in the first place. | 16:06 |
| zaneb | I'm ok with that btw. just trying to clarify Doug | 16:06 |
| dhellmann | thanks, zaneb | 16:06 |
| ttx | It might still be a problem | 16:06 |
| fungi | yeah, i personally felt like settling on barbican as the api was best for interoperability purposes, but it seems like there was a lot of pushback from deployment and operations representatives so at least having some way for projects to avoid duplicating this effort badly/insecurely/inconsistently on their own would be nice | 16:06 |
| zaneb | Doug's point that not all features we might want will be enabled by having just castellan | 16:06 |
| mnaser | well, we can always extend castellan | 16:06 |
| mnaser | to support barbican specific features | 16:07 |
| zaneb | enter key and the apostrophe key are too close as usual | 16:07 |
| dhellmann | mnaser : we cannot require users to use a specific client library for the trademark programs | 16:07 |
| ttx | mnaser: except those "features" are out of scope for Vault | 16:07 |
| dhellmann | so we have to enable a REST API for those things at some point | 16:07 |
| dhellmann | and right now our REST API for this is barbican | 16:07 |
| ttx | Basically the issue here is that Barbican is more than a store | 16:07 |
| ttx | which is why it can plug into Vault for store feature | 16:07 |
| fungi | castellan could also be extended to have multiple drivers for those different features to placate people who really don't want barbican running | 16:08 |
| dims | yep fungi | 16:08 |
| mnaser | so maybe for now we can say 'castellan' but eventually drop it if we really start running into issues | 16:08 |
| smcginnis | Cinder uses castellan. Users do not provide a key, though there have been some recent informal proposals to have user provided keys per volume for encryption. | 16:08 |
| mnaser | we might be discussing something that is non problematic? | 16:08 |
| ttx | The other factor here is that ANYTHING is better than the current situation so we tend to jump on anything that passes | 16:08 |
| smcginnis | I think it's fair to state castellan is a base service, but what is used behind that is left to the deployer. | 16:09 |
| *** kumarmn has quit IRC | 16:09 | |
| dhellmann | smcginnis : how would you implement user-provided keys? | 16:09 |
| dims | we should start with castellan as a base library requirement, then if barbican takes hold among operators then we can go to full dependency on barbican | 16:09 |
| dhellmann | yeah, it's a fine first step. I just expect us to have to revisit it very soon. | 16:09 |
| smcginnis | dhellmann: That's the open question. | 16:09 |
| mnaser | ++ dims | 16:09 |
| smcginnis | dims: ++ | 16:09 |
| dhellmann | maybe when that happens it will be clear why in a way that I seem unable to express. | 16:09 |
| *** kumarmn has joined #openstack-tc | 16:09 | |
| *** jpich has quit IRC | 16:09 | |
| fungi | i think that as soon as we're talking about whether it's safe for a trademark-covered service to require exposing another api to users, then we need that api also covered under the same trademark program(s) | 16:10 |
| smcginnis | I remember DuncanT had some concerns about Barbican, but I do not know enough about that area to really comment. | 16:10 |
| ttx | dims: that sounds a bit... weird though | 16:10 |
| ttx | People who end up doing Castellan+Vault might be forced to change | 16:10 |
| mnaser | arent those the same people who didnt want to run barbican in the first place? :\ | 16:11 |
| dhellmann | keystone is a good parallel here. we say that all of the services can rely on having keystone present to authenticate users, so that those services don't have to implement their own authentication. s/authentication/key management/ | 16:11 |
| dims | mysql / postgresql situation | 16:11 |
| TheJulia | I would urge us not to force additional services where they are not needed. Use cases are going to differ as this discussion shows, and the standalone usage or back-end integration points make very valid sense as some operators have different use context and business needs. | 16:11 |
| *** ricolin has quit IRC | 16:12 | |
| TheJulia | If the projects evolve to have that need, so be it, but at that point it is a conscious decision. | 16:12 |
| ttx | I guess the issue is that for 90% of the use cases castellan is enough... and forcing everyone to go full Barbican might hinder solution for those 90% | 16:12 |
| *** kumarmn has quit IRC | 16:12 | |
| dhellmann | ttx: I guess I am questioning that 90% number, though. | 16:12 |
| *** kumarmn has joined #openstack-tc | 16:12 | |
| mnaser | maybe this is an outlier and not the time for this comment, but barbican really isn't that heavy of a service. | 16:12 |
| mnaser | it's a simple rest api, it can integrate with vault if you're already running it | 16:13 |
| clarkb | as an end user this type of compromise typically means I never use any of these features (and if you look at infra's consumption of openstack its a very reduced feature set because very few things are reliably available). To me that effectively means not enforcing a complete solution is as bad as not having a solution at all | 16:13 |
| dhellmann | let's get a concrete proposal written up and have some project teams comment on it | 16:13 |
| TheJulia | mnaser: but it is still another network accessible service, that has to be monitored, reported upon, it is security related so additional reporting controls have to be put into place depending on operating and regulatory requirements | 16:13 |
| fungi | and the hope is that we can overcome the catch-22 critical mass inflection point which is causing deployments to resist implementing security features they'd find useful | 16:13 |
| ttx | Last time the only things that were raised as potentially needing Barbican were Octavia and Designate iirc | 16:13 |
| ttx | Octavia now uses Castellan... | 16:13 |
| johnsom | Octavia support both | 16:14 |
| mnaser | TheJulia: that's true, but that's up to the deployer if they want to use the extra features, then they'll have to support the things that come with it | 16:14 |
| ttx | So 90% might be 99% :) | 16:14 |
| ttx | johnsom: OR or AND ? | 16:14 |
| smcginnis | clarkb: That's a good point. | 16:14 |
| clarkb | johnsom: and octavia has its own apis for storing certs? | 16:14 |
| *** kumarmn has quit IRC | 16:14 | |
| TheJulia | mnaser: empowering the deployer to make the choice seems.. ideal, at least to me. | 16:15 |
| johnsom | Currently it is an OR, but with flavors (coming) it could be AND. | 16:15 |
| *** kumarmn has joined #openstack-tc | 16:15 | |
| zaneb | so Heat needs Barbican for multi-cloud. It's fine if that's a soft dependency, but obviously better if it were available to everyone | 16:15 |
| ttx | johnsom: no I mean you need one of them, not both, right ? | 16:15 |
| johnsom | clarkb No, the user provides Octavia with the reference to the secrets. We do not have an upload interface. | 16:15 |
| clarkb | johnsom: right so if the secret is in vault fronted by castellan how do I (the end user) give that service my certs so that octavia can use them? | 16:16 |
| clarkb | (this is dhellmann's concern aiui) | 16:16 |
| dhellmann | johnsom : how does the user create the secret? | 16:16 |
| johnsom | ttx It's an operator choice thing. Barbican has been supported for a long time, but people wanted Vault so we added Castellan | 16:16 |
| ttx | ok | 16:16 |
| dhellmann | fungi , you started the meeting, do you want to close it out? | 16:18 |
| johnsom | dhellmann We leave that to the user. Either the barbican CLI or custom UI systems. One operator already has a cert management UI for vault, so just uses that. Our cookbooks describe how to use OpenStack client to add certs to Barbican. There was also castellan-ui dashboard plugin, but I'm not sure if that is finished. | 16:18 |
| fungi | oh! sure | 16:18 |
| clarkb | on an interop front ^ is not very friendly and is another case of infra wouldn't use that feature | 16:18 |
| fungi | #endmeeting | 16:18 |
| dhellmann | johnsom : ok, so that says to me there is no workflow that the interop group would consider for the octavia service | 16:18 |
| *** openstack changes topic to "OpenStack Technical Committee office hours: Tuesdays at 09:00 UTC, Wednesdays at 01:00 UTC, and Thursdays at 15:00 UTC | https://governance.openstack.org/tc/ | channel logs http://eavesdrop.openstack.org/irclogs/%23openstack-tc/" | 16:18 | |
| dims | thanks fungi | 16:18 |
| openstack | Meeting ended Thu May 31 16:18:54 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:18 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-05-31-15.00.html | 16:18 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-05-31-15.00.txt | 16:18 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-05-31-15.00.log.html | 16:18 |
| fungi | we can of course continue discussing | 16:19 |
| johnsom | Cookbook: https://docs.openstack.org/octavia/latest/user/guides/basic-cookbook.html#deploy-a-tls-terminated-https-load-balancer | 16:19 |
| ttx | dhellmann: I think I understand your point now | 16:19 |
| johnsom | dhellmann Can you tell me more about that? | 16:19 |
| zaneb | am I reading right that we already have a castellan UI and a barbican UI for adding secrets? | 16:19 |
| zaneb | because that was a major facepalm moment for me | 16:20 |
| dhellmann | johnsom : if part of the workflow involves an arbitrary service that is up to the deployer it is by definition not interoperable | 16:20 |
| *** kumarmn has quit IRC | 16:20 | |
| clarkb | our interop requirements also require end user apis not UIs | 16:20 |
| clarkb | UIs aren't programmable infrastructure friendly | 16:20 |
| ttx | (I just wish we would have raised it before we asked to make Castellan a thing) | 16:20 |
| johnsom | dhellmann The same could be said of our use of Nova and Neutron I guess | 16:21 |
| *** kumarmn has joined #openstack-tc | 16:21 | |
| dhellmann | ttx: castellan is still useful, because operators may want to store their system-level secrets in something other than barbican | 16:21 |
| dhellmann | johnsom : nova and neutron are part of the interop program already. something like vault is not. | 16:22 |
| johnsom | dhellmann From our perspective we have API parameters that take a reference and we "figure it out" | 16:22 |
| dhellmann | johnsom : if you can use something other than nova to create VMs, then maybe | 16:22 |
| zaneb | Adjutant workflow to add a secret to Vault in 3... 2... 1... | 16:22 |
| ttx | zaneb: lol | 16:22 |
| mnaser | i think if we imagine castellan as oslo.secret_store, it makes a lot more sense, seeing it as a system side thing only | 16:23 |
| dhellmann | mnaser : yes, we decided that renaming it was too painful to be useful | 16:23 |
| mnaser | but anything user facing shouldn't involve it, and should involve barbican only | 16:23 |
| mnaser | (oh, it's just how i imagine it personally to clarify it personally) | 16:23 |
| dhellmann | that's what it actually is: an abstraction layer that binds oslo.config to the driver to talk to the secret store | 16:24 |
| johnsom | dhellmann This makes me uncomfortable. Providing operators flexibility in the deployment shouldn't mean it's not inter-operable as long as the API presented to the user is consistent. This is the same as designate. It requires a DNS backend, none of which are OpenStack projects. | 16:24 |
| dhellmann | so it is just like oslo.messaging or oslo.db, just not named that way because another team created it | 16:24 |
| dhellmann | johnsom : the API isn't consistent if it requires interacting with an arbitrary service, though, right? you have to consider the entire workflow, not just individual API calls into your service. | 16:25 |
| johnsom | Or the ML2 drivers for neutron for example, some require OVS, others not | 16:25 |
| smcginnis | I wonder if renaming to oslo.secret_store would actually make it easier for folks to understand though. | 16:25 |
| *** kumarmn has quit IRC | 16:25 | |
| dhellmann | smcginnis : probably | 16:25 |
| *** kumarmn has joined #openstack-tc | 16:25 | |
| ttx | funny we had that discussion too | 16:25 |
| ttx | so the question is whether asking castellan to be in base service makes it less or more difficult to get Barbican used | 16:26 |
| zaneb | johnsom: not suggesting you're doing anything wrong, but the whole system is not interoperable because there are different APIs (or even no API) for adding the secret on different clouds | 16:26 |
| johnsom | dhellmann Hmm, so if we ever want to be one of the chosen projects we should drop barbican or castellan support? Or do we need to drop both? | 16:26 |
| smcginnis | But castellan isn't a "service", so I think it's use as a library should be encouraged, but doesn't solve the issue of having a recommended backing behind it. | 16:27 |
| dhellmann | johnsom : I don't think dropping features is the right solution. I think relying on 1 external API is the solution. | 16:27 |
| *** kumarmn has quit IRC | 16:27 | |
| zaneb | yeah, I feel like this is our problem to fix, not Octavia's | 16:28 |
| dhellmann | castellan is only useful for features where the user doesn't interact with the keys through the REST API | 16:28 |
| *** kumarmn has joined #openstack-tc | 16:28 | |
| johnsom | dhellmann So that means, yes, we would have to drop Castellan support of Vault and go back to only allowing Barbican | 16:28 |
| jbryce | zaneb smcginnis dhellmann - just catching up. it's fine to post about the meeting | 16:28 |
| ttx | dhellmann: so you would go directly to Barbican as a base service ? | 16:28 |
| dhellmann | jbryce : thanks | 16:28 |
| mnaser | i feel like maybe we should reach out to the community about this subject and hear what some of those who don't want to deploy barbican have to say | 16:28 |
| dhellmann | ttx: yes | 16:28 |
| smcginnis | jbryce: Thanks! | 16:28 |
| dhellmann | johnsom : barbican can front vault, so deployers could still use it | 16:29 |
| zaneb | dhellmann: I wouldn't say it's not useful in those other cases, I would say it promotes bad design in those other cases (which is arguably worse) | 16:29 |
| dhellmann | I'm not sure if there's a separate barbican client library, or if that's wrapped up in castellan, too | 16:29 |
| jbryce | The rule for board members of 72 hours for me to post an official summary, which I definitely didn't do (in part because I didn't go and no who was there had time to fill in for me) | 16:29 |
| ttx | dhellmann: if it can really front Vault, yes | 16:29 |
| dhellmann | zaneb : sure, ok | 16:29 |
| zaneb | jbryce: thanks! | 16:29 |
| johnsom | dhellmann Last we checked it still did not support Vault. | 16:29 |
| dhellmann | ok, well, then we should address that if we have users who want to use vault | 16:29 |
| mnaser | i think barbican has vault support | 16:29 |
| mnaser | let me verify this | 16:29 |
| *** kumarmn has quit IRC | 16:30 | |
| mnaser | https://github.com/openstack/barbican/blob/master/barbican/plugin/vault_secret_store.py | 16:30 |
| dhellmann | jbryce : thanks for the clarification on the rule, too | 16:30 |
| *** kumarmn has joined #openstack-tc | 16:30 | |
| mnaser | it does | 16:30 |
| dhellmann | mnaser : does it *work*? | 16:30 |
| smcginnis | SO this is kind of like trying to say oslo.db and mysql are base services. | 16:30 |
| mnaser | https://github.com/openstack/barbican/commit/89cb777941af91ef24d3209b89ac3268b345c2a0 merged 17 days ago and it seems to have plenty of tests | 16:30 |
| smcginnis | I think the important thing is that we have a pluggable interface to something, then the deployment is up to the consumer. | 16:30 |
| *** kumarmn has quit IRC | 16:30 | |
| mnaser | wait | 16:31 |
| smcginnis | But we should probably pick $implementation so there is always at least one available. | 16:31 |
| dhellmann | smcginnis : we say "an oslo.db compatible database" but a REST API user never interacts with the database directly. It's more like keystone. | 16:31 |
| mnaser | barbican uses castellan based stores now | 16:31 |
| ttx | dhellmann: that's definitely new input. Last time we asked, nobody was interested in developing a Vault backend for barbican itself | 16:31 |
| fungi | i'm happy to start yet another still different mailing list thread rehashing the previous barbican vs castellan in the base services list discussions before proposing the addition to governance, if people think that helps. i tried to summarize those earlier discussions in the current thread already though | 16:31 |
| *** kumarmn has joined #openstack-tc | 16:31 | |
| jroll | would an operator that currently doesn't want to deploy barbican, because they already have vault, want to deploy barbican in front of vault? | 16:31 |
| smcginnis | dhellmann: And castellan provides that REST API abstraction, right? | 16:31 |
| jroll | I don't think the vault backend solves that issue | 16:31 |
| dhellmann | I don't think it's necessarily bad to start with castellan. I just think it's not going to take us very far. | 16:32 |
| smcginnis | Sorry if I've missed some of the details in the scrollback. Still too distracted with things. | 16:32 |
| mnaser | castellan is a library | 16:32 |
| dhellmann | smcginnis : no. castellan is a python client library. It doesn't do any REST. | 16:32 |
| dhellmann | it is not a service. | 16:32 |
| smcginnis | Good, I didn't think so. | 16:32 |
| smcginnis | So what is the REST API that we need to have exposed? | 16:32 |
| dhellmann | barbican. | 16:32 |
| mnaser | ^ | 16:32 |
| dhellmann | at least that's our current REST API for key management. | 16:32 |
| ttx | dhellmann: my fear is that saying "any castellan-compatible backend" makes it more difficult to say "Barbican" in the future | 16:32 |
| fungi | i think that _if_ the discussion shifts toward expectations about barbican being present and exposed to end users, that's a trademark program and interop discussion not a base services discussion (or at least not only a base services discussion) | 16:32 |
| smcginnis | That's an implementation. But are we saying users need to have a base service to have a REST API for this, or that services can expect to interact with a key management backend? | 16:33 |
| dhellmann | ttx: good point, it might | 16:33 |
| mnaser | how about adding 'vault' to the base services | 16:33 |
| ttx | would be a bit like saying "any castellan-compatible backend as long as it's Barbican" | 16:33 |
| mnaser | just like etcd was added for oslo.config related stuff | 16:33 |
| mnaser | we don't have a "oslo.config compatible backend" | 16:33 |
| dhellmann | smcginnis : we're trying to figure out the most useful way to say that projects can rely on having a secret store so they don't have to build those features themselves | 16:33 |
| ttx | well, users don't interact with etcd | 16:33 |
| smcginnis | dhellmann: And for a project to have that, they can use castellan. | 16:34 |
| dhellmann | mnaser : oslo.config doesn't have drivers, yet (we're working on it) | 16:34 |
| mnaser | dhellmann: right, but i was just kinda putting that in theory | 16:34 |
| smcginnis | So I'm still confused where the REST API is coming into play. | 16:34 |
| smcginnis | If that's our goal. | 16:34 |
| dhellmann | smcginnis : how does a user of cinder tell cinder which key to use? | 16:34 |
| smcginnis | It's a setting in the volume type. | 16:34 |
| dhellmann | (in the world where that feature is implemented and they can provide a key) | 16:34 |
| smcginnis | Ah.. | 16:34 |
| dhellmann | how is it expressed? do they pass the key? an ID? something else? | 16:35 |
| *** amotoki has quit IRC | 16:35 | |
| fungi | i'm more concerned for now with making incremental progress on projects being able to assume presence of some place where they can quarantine the secrets needed for their own operation, not those which involve interaction with a user. stalling the former on the latter seems like the sort of thing which will result in no progress at all | 16:35 |
| zaneb | smcginnis: do you generate the key or does the user provide they key, and if so how do they get it to you? | 16:35 |
| *** kumarmn has quit IRC | 16:35 | |
| * ttx unfortunately has to drop from that information gathering exercise | 16:35 | |
| smcginnis | I would expect that to be a Cinder-specific API that uses castellan (or a future version of it that provides the necessary functionality) and not some external REST API that we send people to separately from the CInder API. | 16:35 |
| dhellmann | fungi : sure. I'm not sure how much of ttx's worry about making it harder to take further steps to take into account. | 16:35 |
| *** kumarmn has joined #openstack-tc | 16:35 | |
| mnaser | i think i see fungi's point, barbican serves two functions, secret store for *services* and secret store for *users*. we're talking about secret store for services. | 16:35 |
| dhellmann | smcginnis : and I think it should be "go to barbican, create/upload a key, get the UUID, pass that to cinder" | 16:36 |
| fungi | dhellmann: right, that is in fact my only concern wit the current (not-yet-written) proposal is if it makes barbican less easy to add later | 16:36 |
| zaneb | dhellmann++ | 16:36 |
| smcginnis | zaneb: Right now admin configures it and sets it in the volume type extra specs I believe. | 16:36 |
| smcginnis | dhellmann: I don't think that would be a clean user experience though. | 16:37 |
| zaneb | ah, so it's not something a user can do | 16:37 |
| dhellmann | yeah, anything hidden from a REST API user isn't the problem. castellan is fine for those cases. | 16:37 |
| johnsom | dhellmann That is the workflow we have today with Barbican | 16:37 |
| fungi | mnaser: the muddiness there is that some services have security features where they want to use secrets provided by users, and i guess the question is whether those are more or less common than secrets which are generated by the services | 16:37 |
| smcginnis | dhellmann: If we want to support user provided keys, I don't think we should send them off somewhere else to do some stuff, then come back to us and tell us what you did. | 16:37 |
| dhellmann | smcginnis : so you're going to add an API to cinder for managing the keys separately? and we'll have similar APIs in every other service with a similar feature? | 16:37 |
| clarkb | the octavia case might be easier to reason about because with tls termination on a load balancer my cloud provider isn't going to be able to provide the cert for me | 16:37 |
| *** amotoki has joined #openstack-tc | 16:37 | |
| clarkb | unless they also own my domain | 16:37 |
| smcginnis | Cinder should probably own that whole interaction. | 16:37 |
| smcginnis | dhellmann: Yes, because the use case will be service specific. | 16:38 |
| clarkb | cinder is different in that it can encrypt with an arbitrary key as long as it knows what that key is | 16:38 |
| johnsom | clarkb Correct, we are not is the user CA business | 16:38 |
| mnaser | is there any use case where a service needs to use a secret store that is not user facing? | 16:38 |
| dhellmann | smcginnis : how is creating an encryption key service-specific? | 16:38 |
| zaneb | smcginnis: you really want to own secrets upload? I would run a mile from that | 16:38 |
| smcginnis | dhellmann: It's not, but "I want a new volume and please encrypt it using this key" is. | 16:38 |
| mnaser | because all the scenarios i imagine involve the user interacting with the secret store | 16:38 |
| fungi | clarkb: the designate dnssec case is a nice counterpoint to that, where it wants an hsm | 16:38 |
| dhellmann | mnaser : yes, we're enabling secret stores in oslo.config for deployment secrets like database passwords | 16:38 |
| dhellmann | smcginnis : sure. pass the UUID in to represent the key, that makes sense. | 16:39 |
| smcginnis | zaneb: Should be just a matter of passing what they provide off to a castellan call. | 16:39 |
| dhellmann | but where do you get "this key" in the first place? that is not cinder's job. | 16:39 |
| smcginnis | dhellmann: Not what I was thinking, but if we made them go do stuff elsewhere, then yeah, it would just be a UUID probably. | 16:39 |
| johnsom | fungi I don't follow. An HSM is not a certificate authority that generates certs. | 16:39 |
| smcginnis | dhellmann: If cinder is owning encrypting a volume with a user provided key, I do think it is cinder's job. | 16:40 |
| dhellmann | and from an interop perspective, "go do stuff elsewhere" needs to be consistent because the interop program won't use tests that have branches for alternative behaviors in them | 16:40 |
| zaneb | smcginnis: yes, it's not hard to do. it also puts you inside a security perimeter you don't want to be in | 16:40 |
| smcginnis | This is all theoretical since no one has actually proposed a design for cinder to do this yet. | 16:40 |
| dhellmann | smcginnis : it's cinder's job to use the key. I'm less sure it's cinder's job to create the key. | 16:40 |
| clarkb | smcginnis: right that is why I am pointing to octavia which actually does this stuff today aiui | 16:40 |
| dhellmann | or to return it to the user when they ask to see it | 16:40 |
| fungi | johnsom: "ahardware security module is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing" | 16:40 |
| smcginnis | zaneb: We already are in the security perimeter I think when we're setting up volume encryption. | 16:40 |
| smcginnis | dhellmann: Not create, be provided. | 16:41 |
| dhellmann | right, I'm talking about the APIs for managing keys, not for using them. | 16:41 |
| smcginnis | dhellmann: Not returning to the end user to see it. Just taking what they provide. | 16:41 |
| johnsom | fungi Correct, they typically do not generate certs | 16:41 |
| fungi | johnsom: some hsms provide their own keys so that the key material never exists outside the hsm even for bootstrapping purposes | 16:41 |
| clarkb | fungi: right but to terminate ssl for an arbitrary domain on a load balancer the cloud needs a valid cert for that domain. Which typically will come from a trusted CA | 16:42 |
| fungi | johnsom: "cryptoprocessing" in that sense includes tasks like signing provided material | 16:42 |
| * dhellmann needs lunch | 16:42 | |
| clarkb | the cloud itself isn't (likely) going to be a trusted CA | 16:42 |
| fungi | clarkb: correct. the hsm can provide you with a csr | 16:42 |
| fungi | clarkb: then you take that csr to your ca and get them to provide you with a certificate | 16:43 |
| fungi | and the key never leaves the hsm | 16:43 |
| johnsom | Correct, and even for encrypted at rest most companies require use of an internal CA. It's really about the revocation and ownership. | 16:43 |
| fungi | now clearly that doesn't help in situations where you want the webserver to have access to the key material | 16:43 |
| clarkb | fungi: or if you want bakcups of your key | 16:44 |
| fungi | this is more relevant for less frequent key use, such as dnssec signing | 16:44 |
| fungi | clarkb: right | 16:44 |
| johnsom | fungi Actually, if you are having the HSM sign in the enclave you present a CSR to the HSM | 16:44 |
| *** kumarmn has quit IRC | 16:44 | |
| fungi | johnsom: sure, you're talking about hsm use within a ca | 16:44 |
| fungi | i'm not talking about ca-related uses | 16:44 |
| *** kumarmn has joined #openstack-tc | 16:45 | |
| clarkb | however with cinder encryption using a key I gnerated vs a key the cloud generated is largely the same operationally | 16:46 |
| clarkb | I have to trust the cloud with the key I generate just as much as the key they generate and likely have no way of independently checking that the data is even encrypted with that key | 16:46 |
| clarkb | the only upside to generating my key is that I will know later if the generation method is found to be insecure | 16:47 |
| fungi | consider using an hsm for uniquely identifying a machine. that machine maybe is used to perform trusted builds of software. you ask the hsm for a csr which you then get a certificate issued for. any binaries built on that machine pass a hash of the build to the hsm and ask it to sign that with its key. then anyone with a copy of the ca-issued cert can verify that the build produced on that machine was | 16:47 |
| fungi | signed by a key known only to that machine's hsm | 16:47 |
| *** kumarmn has quit IRC | 16:48 | |
| *** kumarmn has joined #openstack-tc | 16:48 | |
| fungi | this is very similar to how dnssec operates | 16:49 |
| clarkb | fungi: as an end user of the cloud you don't know that an hsm is used though right? | 16:50 |
| fungi | right. i was trying to explain why designate would want a key store with hsm-like features | 16:50 |
| clarkb | ah | 16:50 |
| clarkb | I mean yes it is a great feature. I'm just looking at this from the user perspective (as I am one) and most of the time it is hard to trust things to that level simply because I as a user can't actually know what tools are used behind the scenes | 16:51 |
| clarkb | I can be told but can't verify | 16:51 |
| fungi | sure. this is also why the infra team runs its own nameservers in virtual machines it controls | 16:51 |
| dims | mnaser : barbican uses castellan to talk to vault :) | 16:52 |
| zaneb | so it's castellan->barbican->castellan->vault (potentially)? | 16:54 |
| dims | yep | 16:55 |
| dims | thanks for starting that tangent thread smcginnis | 16:56 |
| smcginnis | dims: I didn't want to but felt I just had to say a little more. I guess that's how these tangents spin out control. ;0 | 16:58 |
| clarkb | going back to the red -1 and messaging around that. I would be careful updating that without some data backing up the perceptions of the current -1 color and the expected perceptions of the new color | 16:59 |
| clarkb | I don't think red means error is very universal. My life experience tells me it is something to pay attention to like a stop sign or railway crossing not necessarily a bad thing | 17:00 |
| clarkb | the concerns about color blindness and green and red conflicting are valid though and there are guidelines published on how to better accomodate for that | 17:00 |
| smcginnis | I didn't realize how much people care about color selection until I saw the comment of someone refusing to move to storyboard until it stopped using red. | 17:00 |
| clarkb | I think if we head down that path with real data we'll be removing the use of the digit 4 and the number 13 and so on. (some airplanes don't have a row 13 so its definitely a thing) | 17:03 |
| smcginnis | Hah, right. | 17:03 |
| smcginnis | Maybe we should have an official suggestion to use Stylish if red bothers you. https://addons.mozilla.org/en-US/firefox/addon/stylish/ | 17:04 |
| clarkb | I do wonder if the bigger problem with a -1 in general is the culture shock of your code not just being merged as is. Ime it isn't common for pre merge review to be used in many places | 17:08 |
| clarkb | we might be better off explaining to people upfront that we use a code review system that require pre merge review and everyone has to go through it | 17:09 |
| clarkb | (because another assumption may be that they being new have to go through it and that everyone else gets a pass?) | 17:09 |
| clarkb | (this is common in other projects like the linux kernel aiui) | 17:09 |
| clarkb | that doesn't mean we should be nit picky. I agree we can be better about not doing that a community, but legit problems in the code should be called out and its fair to ask for them to be fixed | 17:10 |
| clarkb | this is why we do pre merge code review | 17:10 |
| smcginnis | Can we fit all that in a tooltip when they hover over a -1? :) | 17:11 |
| clarkb | smcginnis: probably not on fungi's browser screen but it may fit on everyone elses :P | 17:12 |
| smcginnis | :D | 17:12 |
| clarkb | https://blog.ffwll.ch/2018/04/maintainer-statistics.html talks about this in the linux kernel | 17:13 |
| clarkb | "Kernel w/o graphics is an entirely different story. Overall, review is much less a thing that happens, with only about 30% of all maintainer self-commits having any indication of oversight." if coming from a system like that being -1'd would be frustrating if you assume the people doing the -1 just merge their code as is | 17:15 |
| fungi | we do already try to explain some of this in the welcome comment left on a new contributor's first change | 17:15 |
| fungi | along with pointers to places to read more about how our community operates | 17:16 |
| clarkb | ya I think that was a really helpful thing that fifieldt helped to add | 17:17 |
| mtreinish | clarkb: heh, my first kernel patch experience was very different: http://permalink.gmane.org/gmane.linux.nfs/44862 was frustrating not because it got blocked. But more because of the tone and how they did it | 17:41 |
| mtreinish | going from that environment to openstack was a big improvement | 17:42 |
| clarkb | mtreinish: wow | 17:46 |
| clarkb | mtreinish: I guess my point is I could see how you might interpret a -1 please fix this bug in one of our code reviews as just being another case of the above | 17:46 |
| clarkb | hwoever good to hear that you found it an improvement :) | 17:46 |
| *** edmondsw_ has joined #openstack-tc | 17:51 | |
| *** edmondsw has quit IRC | 17:54 | |
| fungi | i do find examples like that from other communities helpful in getting some contrasting perspective | 17:55 |
| openstackgerrit | Julia Kreger proposed openstack/governance master: Add principles entry for peer review https://review.openstack.org/570940 | 18:07 |
| *** diablo_rojo has joined #openstack-tc | 18:31 | |
| TheJulia | clarkb: I think part of the issue is that the -1 causes an all-stop to future review activity, and -1s do get misused to ask questions, try and force people to refactor chunks of code unrelated or near to their patch, or change the entire testing style to a single reviewers personal preference. IME, the reviewers often don't revisit or respond to questions or explanation unless they are invested in that change. | 18:52 |
| clarkb | TheJulia: right but that isn't a problem with properly used -1' | 18:53 |
| zaneb | clarkb: this can't only be about re-educating new contributors to be more thick-skinned. TheJulia is talking about things that actually happened to her. deva said at the Forum that he left the project in part because of this | 18:53 |
| clarkb | the fix is to improve our reviewing not change the color of gerrits string | 18:54 |
| zaneb | so I agree that changing the color is a waste of time | 18:54 |
| TheJulia | clarkb: agreed, but there is a varying definition of what that setting is for | 18:54 |
| clarkb | now separately we might change colors to help those that are color blind but I Think that is an orthogonal concern | 18:54 |
| TheJulia | I totally agree as well, the color is not going to change perception | 18:54 |
| *** diablo_rojo has quit IRC | 18:55 | |
| TheJulia | have a "change to high contrast?" button for the stylesheet? | 18:55 |
| zaneb | we should change the caption to "-1 today I am going to obstruct your work" | 18:55 |
| zaneb | (kidding. mostly.) | 18:55 |
| clarkb | TheJulia: there are pallette guides for that published in places, I'm not personally familiar with them but making one or more of them an option in gerrit may be beneficial for users outside of openstack too | 18:56 |
| clarkb | I also think that the best way to address these problems is to lead by example | 18:58 |
| *** cdent has joined #openstack-tc | 18:58 | |
| TheJulia | feels like that should at least go back to the gerrit community as "hey, random thought/idea, do with it what you will" | 18:58 |
| clarkb | code reviews in projects (particularly by core members) reflect what is basically tribal behavior around teh code base | 18:58 |
| clarkb | and it varies within openstack to a great degree | 18:59 |
| *** edmondsw_ is now known as edmondsw | 18:59 | |
| dhellmann | speaking of tribal behavior, I just finished reading this article about the "Nut Island Effect" and found it pretty interesting https://hbr.org/2001/03/when-good-teams-go-wrong | 18:59 |
| clarkb | if this is happening and core reviewers don't like it start pushing back. Leave a comment like "this can be fixed in a followup" or "isn't related to this change" and approve it | 19:00 |
| TheJulia | I personally have done that to mixed results | 19:01 |
| clarkb | (I don't think this will magically fix everything, but if we want code review behavior to change we need to start explicitly pushing it in the direction we want) | 19:01 |
| TheJulia | the problem is I respect the -1 votes because I'm an idealist. | 19:01 |
| dhellmann | clarkb : do you have suggestions for ways to do that? | 19:02 |
| clarkb | dhellmann: I think it starts by asking core reviewers directly to chagne behavior, then on reviews where it is happening overriding the unwanted behavior | 19:03 |
| TheJulia | clarkb: I totally agree, and I think the step 1 is recording it, step 2 in my mind is beginning to shift the culture in through leading by example. Whatever project that starts with is likely going to have a rough go at it, but maybe not... | 19:03 |
| clarkb | a -1 does not mean it cannot merge | 19:03 |
| TheJulia | Do we have any stats on how often patches with an oustanding -1 actually merge versus otherwise? | 19:04 |
| dhellmann | do you feel like there's some prerequisite to updating the list of principles/ | 19:04 |
| dhellmann | ? | 19:04 |
| clarkb | dhellmann: I'm not sure what specific list you mean, but in general we (openstack we) have given large lattitutde to projects to determine their review practices/policy in the past. So we may need to change that | 19:05 |
| TheJulia | clarkb: I agree it does not, but it often does block it, people exclude -1s from review dashboards because the patches are not seen as "ready" | 19:05 |
| dhellmann | TheJulia : https://review.openstack.org/#/q/status:merged+label:Code-Review-1 | 19:05 |
| dhellmann | ok, I guess I'm not sure what you're objecting to | 19:06 |
| clarkb | in infra and zuul land we taken to leaving the same comments but +2'ing so that we can discuss the other problems but try and make it clear the change author isn't on the hook for it. And usually point that out explicitly | 19:06 |
| dhellmann | are you commenting on this patch? https://review.openstack.org/#/c/570940/ | 19:06 |
| dhellmann | or the conversation in general? | 19:06 |
| clarkb | dhellmann: is that directed at me? | 19:06 |
| dhellmann | yeah | 19:06 |
| clarkb | dhellmann: I'm objecting to the idea that changing UI is going to make anyone feel better | 19:06 |
| dhellmann | ok | 19:07 |
| clarkb | Instead I think direct communication with involved parties is necessary | 19:07 |
| dhellmann | yeah, I wasn't considering that as a serious proposal | 19:07 |
| clarkb | as a community we often (at least it feels that way as an individual in the crosshairs) point to tools to solve fundamental social and communication problems | 19:08 |
| TheJulia | Nor was I. It would be cool, and there may be social connotations from different cultures to consider, but it wouldn't really be a problem if -1s were not misused | 19:08 |
| clarkb | code review is almost entirely about communicating | 19:08 |
| clarkb | we are failing at communicating in the arena of code review | 19:09 |
| TheJulia | Completely agree | 19:09 |
| dhellmann | clarkb : I'm much more interested in your input on that patch than any discussion of colors in gerrit :-) | 19:09 |
| clarkb | noted, I shall review it shortly | 19:10 |
| dhellmann | thanks | 19:11 |
| cdent | Have I missed anything super important in the last few days (since summit)? | 19:13 |
| TheJulia | it is social/community culture issues that we've bypassed, and now we need to come back to them one at a time. I actually like the idea of not trying to solve social problems solve with changes to or addition to tools. Granted, if I look in the back of my brain, I might have a few ideas in the back of my head for tools, but they aren't to solve social issues. | 19:13 |
| TheJulia | cdent: eh.... *shrugs* | 19:13 |
| dhellmann | cdent : I started trying to make a list of everything we're working on in the wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker | 19:14 |
| dhellmann | I would appreciate it if you'd double check that I have your name down in all the right places, and that I've captured everything | 19:14 |
| dhellmann | I already know it's missing the thing about job descriptions and help-wanted areas | 19:14 |
| cdent | thanks, will take a look. I'm not fully back yet (in california) but somewhat looping myself back in | 19:15 |
| TheJulia | thanks to whomever updated the wiki after the meeting for the trove portion | 19:15 |
| *** dklyle has quit IRC | 19:18 | |
| * TheJulia is now curious how much feedback the -1'ed principles change will garner | 19:18 | |
| *** dklyle has joined #openstack-tc | 19:18 | |
| cdent | dhellmann: I'll go through that at some point in more detail and try to add my name in a few more places | 19:18 |
| TheJulia | likely not at all representative since I emailed the ml | 19:18 |
| dhellmann | cdent : thanks! | 19:19 |
| *** dklyle has quit IRC | 19:19 | |
| *** david-lyle has joined #openstack-tc | 19:19 | |
| smcginnis | The biggest issue with -1's I've seen is what TheJulia pointed out awhile back - no one looks at a patch anymore once someone has downvoted it, so that part becomes problematic. | 19:23 |
| dhellmann | so maybe we need to do something to highlight those sorts of patches? | 19:24 |
| smcginnis | Not sure the best answer there other than to either prod cores to still look at -1 patches or get the people leaving unncessary -1's to stop. | 19:25 |
| clarkb | smcginnis: I think that would be less problematic if we were better about using -1's when they make sense | 19:25 |
| clarkb | because then it is something that needs valid rework and you can wait on it | 19:26 |
| *** cdent has quit IRC | 19:27 | |
| TheJulia | I completely concur, it compounds, and we should work on trying to fix the root of the problem, not a symptom. | 19:29 |
| *** david-lyle has quit IRC | 19:29 | |
| *** dklyle has joined #openstack-tc | 19:29 | |
| *** kumarmn has quit IRC | 19:30 | |
| *** kumarmn has joined #openstack-tc | 19:30 | |
| *** kumarmn_ has joined #openstack-tc | 19:34 | |
| *** kumarmn has quit IRC | 19:34 | |
| *** kumarmn_ has quit IRC | 19:37 | |
| *** kumarmn has joined #openstack-tc | 19:37 | |
| clarkb | TheJulia: dhellmann I've reviewed the change. I do agree that being clear on our gerrit terminology will be helpful (hopefuly that isn't seen as a nit :) ) | 19:41 |
| *** kumarmn has quit IRC | 19:42 | |
| TheJulia | It ia a totally valid point to me | 19:42 |
| TheJulia | Just not going to rev it immediately to see where some of the discussion goes. Besides, i need to get a beer and go look at ironics docs builds :( | 19:43 |
| *** kumarmn has joined #openstack-tc | 19:43 | |
| fungi | i can't speak to the behavior choices of others, but a code review -1 doesn't impact whether i'm likely to review a change. presence of a code review +2 does, since those are changes which i can clear out of the queue more quickly, as does verified -1 since i'm not interested in looking at changed which are failing ci jobs unless someone explicitly points me to them | 19:47 |
| *** kumarmn has quit IRC | 19:48 | |
| clarkb | fungi: did you see I have a verified -1 in bindep I'd like you to review :) | 19:49 |
| fungi | yes, i did. also need to prioritize! ;) | 19:49 |
| clarkb | for concrete examples of how I think review should go (and I'm biased here obviously) https://review.openstack.org/#/c/569103/3/diskimage_builder/elements/ubuntu-core/root.d/10-cache-ubuntu-image which sort of resulted in https://review.openstack.org/#/c/569077/ | 19:50 |
| fungi | we _could_ solve the distinction by creating separate categories for plebian-review and royal-review so that we can distinguish votes made by the dirty unwashed masses from those of the all-powerful core reviewers on a project, but it seems not entirely in keeping with our values as a community | 19:50 |
| * TheJulia facepalms, and goes and opens a beer | 19:51 | |
| *** kumarmn has joined #openstack-tc | 19:51 | |
| fungi | i missed my sarcastic winky smiley ;) | 19:51 |
| dims | LOL | 19:51 |
| clarkb | we shouldn't be afraid to identify problems in the code base because review is about communicating. We just shouldn't punish people for things that don't deserve punishment | 19:52 |
| fungi | worth noting that my hyperbole about plebian-review and royal-review categories isn't entirely fictional... it's what we do (the names have been changed to protect the guilty) for code-review vs roll-call votes on the governance repo, for example ;) | 19:56 |
| TheJulia | fungi: oh, good, the ;) | 19:56 |
| fungi | though in the case of the governance repo we actually only give _real_ power (the workflow +1) to our elected chair | 19:58 |
| * smcginnis would so love a casual nick Friday where dhellmann changes his nick to HisHighness | 19:58 | |
| * TheJulia notes that Friday is fast approaching | 20:00 | |
| TheJulia | Today is Thursday right? | 20:00 |
| clarkb | yes | 20:00 |
| TheJulia | \o/ | 20:00 |
| clarkb | I thought yesterday was tuesady | 20:00 |
| clarkb | summit then holiday has me really confused | 20:00 |
| TheJulia | likewise | 20:00 |
| *** harlowja has joined #openstack-tc | 20:01 | |
| fungi | friday starts in just under 4 hours | 20:03 |
| fungi | brace yourselves! | 20:04 |
| TheJulia | mass casual nick friday in 4 hours? | 20:04 |
| fungi | anyway, the plebian/royal fairy tale was my attempt to point out that any time someone asks to have the review tool separate votes so that they can tell core review -1 apart from general -1 is supporting classism ;) | 20:05 |
| * TheJulia suddenly misses ye olde days of being an irc operator and having a feature in the ircd that allowed us to change user's nicks for them.... | 20:05 | |
| jroll | don't forget /nicklock :P | 20:07 |
| clarkb | in the past we've had the idea to stop using numbers for votes in part because people like to do math on numbers and gerrit doesn't do math on those numbers | 20:08 |
| clarkb | people have assumed that if you had a +1 and a -1 that balacned things out for example | 20:08 |
| TheJulia | I can't help but wonder if that would be better as time goes on and the community evolves... | 20:09 |
| TheJulia | Anyway, I'm actually going to ignore IRC for a little while. | 20:09 |
| clarkb | it may be but it isn't how gerrit operates so would require work | 20:09 |
| * TheJulia had an idea about that, but it is presently locked in reserved for "later" | 20:10 | |
| fungi | the bigger misconception is "you say it needs two +2 votes so why don't four +1 votes work?" | 20:11 |
| zaneb | that confused that heck out of me when I first started on OpenStack | 20:12 |
| zaneb | fungi: I seem to recall it was you who had to explain it to me ;) | 20:13 |
| fungi | hah | 20:13 |
| smcginnis | Maybe we need to change the votes to emojis instead. | 20:13 |
| fungi | -2 = stop sign; -1 = question mark; +1 = thumbs up; +2 = beer mug | 20:14 |
| * fungi is of course, still kidding | 20:14 | |
| clarkb | personally I don't think a math based system would work well. It would devolve to popularity contests | 20:15 |
| fungi | (though maybe not about the 🍺) | 20:15 |
| zaneb | -1 should be a yield sign, but with that I am on board and I am not even kidding | 20:15 |
| smcginnis | ++ :) | 20:15 |
| clarkb | what do we give workflow +1? | 20:15 |
| clarkb | giant check mark? | 20:16 |
| smcginnis | Rocket ship? | 20:16 |
| jroll | the two beers clinking, ofc | 20:16 |
| zaneb | green traffic light? | 20:16 |
| fungi | crashing rocket ship | 20:16 |
| smcginnis | lol | 20:16 |
| jroll | 🍻 to be clear | 20:16 |
| TheJulia | How about just a rocket? | 20:31 |
| dims | 🚢 | 20:31 |
| dims | "shipping" | 20:32 |
| fungi | if you look at the gerrit instance which gerrit upstream runs, they have a mix of red X, green checkmark, red -1 and green +1 https://gerrit-review.googlesource.com/ | 20:35 |
| fungi | though the polygerrit interface changes all of this around, so might make more sense to defer gerrit skinning discussions until the next ui | 20:36 |
| zaneb | dims: YES | 20:43 |
| *** harlowja has quit IRC | 21:00 | |
| spotz | ok I"m jealous you got emojis in IRC! | 21:17 |
| *** dklyle has quit IRC | 21:17 | |
| *** dklyle has joined #openstack-tc | 21:18 | |
| smcginnis | spotz: Poor (wo)man's IRC emoji - copy and paste from here: https://en.wikipedia.org/wiki/Emoji#Unicode_blocks | 21:19 |
| smcginnis | ;) | 21:19 |
| spotz | :) | 21:19 |
| smcginnis | ✌️ | 21:19 |
| spotz | oooh cows.... | 21:20 |
| clarkb | my terminal font doesn't suppor them so there are just a bunch of blank spaces. Oh that last one worked. But I had to blow up the font size to read it | 21:20 |
| smcginnis | Though you do need to be careful, because at least one person told me that the gender neutral person I pasted from there shows up in their GUI client as a waving woman with the female sign, so I probably confused a few people with that one. | 21:20 |
| spotz | U+1F404 | 21:20 |
| spotz | bah! | 21:20 |
| smcginnis | clarkb: Yeah, they're small for me too. | 21:21 |
| smcginnis | spotz: Actually copy the picture, it should work. | 21:21 |
| spotz | 🐄 | 21:21 |
| smcginnis | cowsays yeah! | 21:21 |
| spotz | where are asettle and mhayden to torture when you need them:) | 21:22 |
| smcginnis | Hah | 21:22 |
| * TheJulia giggles at emojis in irc | 21:32 | |
| *** kumarmn has quit IRC | 21:32 | |
| *** kumarmn has joined #openstack-tc | 21:33 | |
| * fungi just considers them glyphs for extended unicode codepoints | 21:35 | |
| *** kumarmn has quit IRC | 21:38 | |
| smcginnis | Curmudgeon | 21:38 |
| smcginnis | :) | 21:38 |
| *** diablo_rojo has joined #openstack-tc | 21:40 | |
| *** cdent has joined #openstack-tc | 21:40 | |
| spotz | The things I learn on the TC channel:) | 21:45 |
| *** diablo_rojo has quit IRC | 21:50 | |
| *** mriedem has quit IRC | 22:05 | |
| *** gagehugo has quit IRC | 22:05 | |
| *** diablo_rojo has joined #openstack-tc | 22:09 | |
| *** lbragstad has quit IRC | 22:18 | |
| *** harlowja has joined #openstack-tc | 22:21 | |
| *** lbragstad has joined #openstack-tc | 22:23 | |
| TheJulia | heh | 22:26 |
| TheJulia | We're just a bunch of geeks :) | 22:27 |
| *** ricolin has joined #openstack-tc | 22:39 | |
| *** cdent has quit IRC | 22:40 | |
| *** hongbin has quit IRC | 22:41 | |
| fungi | i.e., some genius mapped the old ms "wigdings" font into some unused codepoint range and got the unicode consortium to ratify them | 22:48 |
| *** gagehugo has joined #openstack-tc | 22:48 | |
| fungi | er, wingdings | 22:49 |
| clarkb | J | 22:51 |
| clarkb | that is wingding for :) | 22:51 |
| fungi | touch'e | 22:58 |
| fungi | which is i-hit-the-wrong-compose-key for touché | 22:59 |
| *** cdent has joined #openstack-tc | 23:58 | |
| *** kumarmn has joined #openstack-tc | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!