Thursday, 2018-05-31

*** kumarmn has joined #openstack-tc00:17
openstackgerritZane Bitter proposed openstack/governance master: Clarify new project requirements for affiliation diversity
*** kumarmn has quit IRC00:29
*** edmondsw has joined #openstack-tc00:38
openstackgerritZane Bitter proposed openstack/governance master: Minor grammatical fixes to new project requirements
*** edmondsw has quit IRC00:43
*** harlowja has quit IRC01:19
*** mriedem_afk has quit IRC01:23
*** spotz has joined #openstack-tc01:29
spotzdtroyer: You about?01:29
*** kumarmn has joined #openstack-tc02:18
*** edmondsw has joined #openstack-tc02:26
*** edmondsw has quit IRC02:31
*** kumarmn has quit IRC02:48
*** kumarmn has joined #openstack-tc02:50
*** kumarmn has quit IRC02:58
*** kumarmn has joined #openstack-tc03:29
*** kumarmn has quit IRC03:33
*** ianychoi has quit IRC03:51
*** kumarmn has joined #openstack-tc04:02
*** rosmaita has quit IRC04:02
*** kumarmn has quit IRC04:07
*** edmondsw has joined #openstack-tc04:14
*** edmondsw has quit IRC04:19
*** kumarmn has joined #openstack-tc04:33
*** kumarmn has quit IRC04:38
*** kumarmn has joined #openstack-tc05:13
*** kumarmn has quit IRC05:17
*** ricolin has joined #openstack-tc05:33
*** jaosorior has quit IRC05:58
*** edmondsw has joined #openstack-tc06:03
*** edmondsw has quit IRC06:07
*** jaosorior has joined #openstack-tc06:14
*** kumarmn has joined #openstack-tc06:21
*** kumarmn has quit IRC06:26
*** kumarmn has joined #openstack-tc06:58
*** kumarmn has quit IRC07:03
*** kumarmn has joined #openstack-tc07:31
*** ianychoi has joined #openstack-tc07:32
*** kumarmn has quit IRC07:36
*** edmondsw has joined #openstack-tc07:51
*** jpich has joined #openstack-tc07:55
*** edmondsw has quit IRC07:56
*** kumarmn has joined #openstack-tc08:08
*** kumarmn has quit IRC08:12
*** diablo_rojo has quit IRC08:21
*** kumarmn has joined #openstack-tc08:39
*** kumarmn has quit IRC08:43
*** kumarmn has joined #openstack-tc09:48
*** ttx has quit IRC09:52
*** kumarmn has quit IRC09:53
*** ttx has joined #openstack-tc10:11
*** ttx has quit IRC10:14
*** ttx has joined #openstack-tc10:14
*** gcb has quit IRC10:36
*** rosmaita has joined #openstack-tc11:07
*** ttx has quit IRC11:07
*** ttx has joined #openstack-tc11:08
*** edmondsw has joined #openstack-tc11:27
*** edmondsw has quit IRC11:31
*** ttx has quit IRC11:34
*** ttx has joined #openstack-tc11:35
*** ttx has quit IRC11:47
*** ttx has joined #openstack-tc11:47
*** edmondsw has joined #openstack-tc11:47
*** ttx has quit IRC11:51
*** ttx has joined #openstack-tc11:51
*** kumarmn has joined #openstack-tc12:08
*** kumarmn has quit IRC12:13
dimsdhellmann : 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
dhellmanndims : stable maint seems like a good place to start. we should work with the project PTLs to describe the roles from their perspective12:48
dimswe need a template for them to fill in12:52
* TheJulia wonders why we need a template12:52
TheJuliaI 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 fill12:53
dhellmannif 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 out12:55
dhellmannI agree the actual content is going to vary, though12:55
mnaserwith my business hat on, i think it's critical to demonstrate the importance of the role in the ecosystem12:55
mnaser'without stable maintainers, we won't have a very stable release so the next time you upgrade, things might break'12:56
dhellmannyes, that was definitely the most important thing I took away from the meeting12: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
mnaseri can help with some of that by looking things over after12:56
TheJuliaIn retrospect, I agree a template is a good idea12:57
*** kumarmn has joined #openstack-tc13:01
dimsTheJulia : mnaser : i was browsing for volunteer/skills matching websites like this one for inspiration -
*** mriedem has joined #openstack-tc13:07
TheJuliadims: I _really_ like that13:09
fungineat idea, yes13:10
dimsthanks fungi TheJulia . another example was which is more free form request13:12
smcginnisI really like that catchafire format.13:13
TheJuliaI get a sign-in screen instead :\13:14
smcginnisYeah, looks like requires a login.13:14
dimsoops sorry13:14
dimsscreen shot ^13:15
dimswe need a cross between those kinds of things and a traditional job description (say the one from dhellmann/redhat that triggered this -
dimsdhellmann : smcginnis : fungi : TheJulia : here's what i have so far -
smcginnisdims: Nice, I like it!13:34
smcginnisReally like the communication channels, time zones, and mentor bits.13:34
smcginnisI think all of those will be important.13:34
dimsthanks Sean13:41
dhellmanndims : I like the list. I wonder if "How This Will Help" should appear closer to the top.13:46
dhellmannmaybe as the 2nd item?13:46
dimsplease feel free to edit too13:47
dhellmannas 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.
TheJuliadims: 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
TheJulialike, most people don't think about time zones too13:51
dimsack let me find Chris Price and loop him in13:54
smcginnisdhellmann: That bank might have been one of them discussed in Good to Great.13:54
dhellmannI've heard of Good to Great but I don't think I've read it13:55
*** hongbin has joined #openstack-tc13:56
* dims queues up the HBR article13:56
mnasersuper silly, unrelated-but-kinda-related to the nitpicking thread, how would we feel about removing the red color of -1 in gerrit reviews14:09
mnaserin 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
mnaseri know it sounds silly, but i think this sort of thing might have some small impact.14:10
fungiwe could make them green so they look as friendly as a +1? ;)14:10
dims-1 is the new black :)14:11
cmurphyfungi: that sounds confusing :P14:11
* cmurphy opts for purple14:11
mnaserespecially for new contributors, having a big red thing sitting on your review might be very discouraging14:11
dimscmurphy : purple is strong, orange seems to work better14:13
* dims toying with editing css/html14:13
dimsLOL smcginnis14:14
mnaserbring back geocities website14:14
smcginnismnaser: No kidding! :D14:14
dimsexactly my thought mnaser14:14
fungican we use an animated gif of a -1 on fire?14:15
fungithat would be very geocities14:15
mnaserhere is a few suggestions based on the colors14:16
fungikeep in mind that color choices are very much culture-specific. for chinese contributors the red probably looks very friendly and not at all negative14:16
mnaseri think it's a lot less "YOUR STUFF IS BROKEN" than red14:16
mnaserthat's a good point too14:16
mnaserbut generally red => error, like the glaring "Merge Conflict" stuff too, but yeah14:17
mnasernothing against jay though i just found a random review that had a -1 :D14:17
fungiin 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 other14:17
dimsindeed fungi14:18
fungiperhaps 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 patch14:19
fungithey're far more likely to be upset by negative tone in the comments they get than the symbol or its color14:21
smcginnisI think you're right fungi14:22
fungiit's far too tempting to gravitate toward ineffectual things which are easy for us to change than things like human behavior14:23
fungis/gravitate toward/focus on/14:27
*** gcb has joined #openstack-tc14:44
* TheJulia finally has coffeeeeeeeeee14:52
TheJuliacmurphy: +1 to purple14:53
TheJuliamnaser: I do kind of like the idea of delineating ERROR versus needs more work14:54
mnaserTheJulia: maybe we need to communicate that a -1 means more work and -2 means this is functionally incorrect14:54
TheJuliaat that point though, we would need a -3 hard block14:55
*** mriedem has quit IRC14:55
dhellmanndon't the built-in messages attached to -1 and -2 already clearly describe the differences?14:55
TheJuliaI guess the issue there is the built in messages don't always map to actual human behaviors of what they should look at14:56
* EmilienM for once can make the office hour14:57
fungithe 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 -114:58
fungii'm not sure how much more explicit we can make it?14:59
fungiand code review -2 is simply "do not merge"15:00
TheJuliaThe conundrum is actually getting people to look at -1'ed patches15:00
smcginnisIt's about that time.15:00
dhellmannwho wants to start the office hours meetbot?15:00
fungi#startmeeting tc15:00
openstackMeeting 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
smcginnis#startmeeting tc15:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:01
*** openstack changes topic to " (Meeting topic: tc)"15:01
TheJuliais o/15:01
openstackThe meeting name has been set to 'tc'15:01
openstacksmcginnis: Error: Can't start another meeting, one is in progress.  Use #endmeeting first.15:01
dhellmannthanks, fungi & smcginnis15:01
fungi#chair smcginnis15:01
openstackCurrent chairs: fungi smcginnis15:01
fungi#chair dhellmann15:01
openstackCurrent chairs: dhellmann fungi smcginnis15:01
fungi#chair TheJulia15:01
openstackCurrent chairs: TheJulia dhellmann fungi smcginnis15:01
*** mriedem has joined #openstack-tc15:01
fungi#chair zaneb15:01
openstackCurrent chairs: TheJulia dhellmann fungi smcginnis zaneb15:01
fungi#chair EmilienM15:01
openstackCurrent chairs: EmilienM TheJulia dhellmann fungi smcginnis zaneb15:01
cmurphystart all the meetings15:01
dhellmann#chair cmurphy15:01
openstackCurrent chairs: EmilienM TheJulia cmurphy dhellmann fungi smcginnis zaneb15:01
fungi#chair cmurphy15:01
openstackCurrent chairs: EmilienM TheJulia cmurphy dhellmann fungi smcginnis zaneb15:01
fungi#chair mnaser15:01
openstackCurrent chairs: EmilienM TheJulia cmurphy dhellmann fungi mnaser smcginnis zaneb15:01
smcginnisOur ping list has become a chair list. :)15:01
fungilooks like we have a bunch of tc members around around15:02
dhellmannheh, that's one way to do it15:02
fungiextra around15:02
fungi#chair ttx15:02
openstackCurrent chairs: EmilienM TheJulia cmurphy dhellmann fungi mnaser smcginnis ttx zaneb15:02
fungito be fair, it made more sense to add all two present tc members as chairs during the last office hour ;)15:02
dhellmannthe more the merrier15:03
dhellmannwe have several items on our tracker list without drivers (or with only 1). what should we do about that?
smcginnisDid the bylaws correction get done?15:04
dhellmannthe board passed a resolution authorizing jbryce to deal with it as part of the next election15:04
fungibylaws correction next step is making sure it gets on the next ballot for board elections15:04
EmilienMfungi, ttx : have we already created a story about "Reviewing the TC Vision" ?15:04
dhellmannI thought we would want to keep tracking it to ensure that correction makes it onto the ballot, and fungi signed up for that15:04
fungiEmilienM: i haven't yet and not aware of one, that would be great to have15:05
EmilienMif no, I'll go ahead and do it (+ update Wiki), maybe we could start poking at it today15:05
smcginnisYeah, that makes sense to follow it through to completion.15:05
dhellmannoh, yes, please add links to relevant stories in the wiki15:05
openstackgerritSamuel Cassiba proposed openstack/governance master: Add openstackclient to Chef OpenStack
TheJuliadhellmann: 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 week15:06
dhellmannI didn't know if we wanted to ask people to sign up, move unowned things to a separate list, or something else.15:07
TheJuliaI 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
ttxEmilienM: it's on dhellmann's wiki already15:09
TheJuliaThat way we're also possibly growing the pool of potential leaders as time moves on/giving opportunities.15:09
ttxEmilienM: oh, you mean add link ? Yes++15:09
EmilienMttx: doing it now15:09
ttxEmilienM: I'll create an etherpad where we can dump the current vision and then add comment15:10
dhellmannTheJulia : are you suggesting that we ask folks not on the TC to take these up?15:10
TheJuliaWe had discussed in the past that we felt that it was acceptable for non-tc members to take up causes and work with the TC15:10
dhellmannI 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
TheJuliaif that is no longer the case, then we have a limited pool of resources.15:11
dhellmannthat's why I called them "drivers" and not "owners"15:11
EmilienMttx: works for me, it can be faster than using Gerrit for now.15:11
TheJuliadhellmann: I see your point, I would just worry about drivers being looked at like owners15:12
dhellmannit's hard for me to reconcile a desire to be more active with the idea that we wouldn't do things. :-)15:12
dhellmannmaybe 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 list15:13
dhellmannperhaps some of these things are backlog items, and not actively being worked on, for example15:14
cmurphywhat is "Trove Project Health"? I was in that session but I'm not sure what actions should be taken around that15:14
dhellmannzaneb 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
TheJuliadhellmann: that is a valid point, we can't take on the world... at least not without prioritization and planning :)15:15
dhellmannit relates to the thing we talked about thursday of checking in on project teams more actively15:15
ttxdhellmann: I heard that question from a bunch15:16
TheJuliadhellmann: cmurphy: I believe the comment is that there is nobody working on it any longer, and that maintainers and contributors are needed15:16
dhellmannI 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 list15:16
TheJuliaSomeone raised ?Amrith?, but... yeah.15:16
smcginnisI thought a team from IBM took up Trove when amrith had proposed moving it to unmaintained.15:17
ttxTo the point where a "Stop or encore" session would have been good at forum15:17
ttxsmcginnis: yes15:17
TheJuliadhellmann: good plan then15:17
dhellmannwho wants to check in on the trove team and report back?15:17
TheJuliaI can put that on my todo list15:17
mnaser -- looks like they're still kinda landing things15:18
dhellmannthanks, TheJulia!15:18
fungiyeah, 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 sessions15:18
ttxI have history, can take Trove too15:18
mnaserbut 6 weeks before that was the last merge15:18
dhellmanngreat, please put your names in the wiki, ttx & TheJulia15:18
dhellmannlet's not do it *now*15:18
zanebthe 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 case15:18
ttxOVH has ben considering taking it over, which is why I looked into it15:18
TheJuliaIt would be good to have an operator get involved15:19
fungionly searchlight has that governance tag applied at the moment15:19
zanebpeople (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 information15:19
* dhellmann was hoping to use this time for team organization, not a deep dive into trove15:19
ttxI think at this point they don't dare taking it over, but we could encourage them if it's in bad shape15:20
dhellmannsmcginnis , I have a ? next to your name on the stein goals item. did you want to help drive that?15:20
TheJuliadhellmann: next item! :)15:20
* ttx now sees how fun it is to disrupt the chair15:20
mnaserdhellmann: maybe that's why we'd need an actual meeting with an agenda besides office hours :>15:20
mnaserbut back on track15:20
dhellmannmnaser : there is 1 topic on our agenda today: sort out this todo list! :-)15:20
mnaserfair :)15:21
dhellmannwe more or less agreed to always pair up on items, and we have a lot with only 1 driver15:21
EmilienMttx: i've noticed that redirects to projects from ocata15:21
dhellmanndo 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
EmilienMttx: we might want to update it to Quees, perhaps15:21
ttxEmilienM: will signal it15:22
smcginnisdhellmann: Yes, I will update that to remove the ?15:22
mnaserdhellmann: i think it's beneficial being able to lean on someone else who will hopefully be intimately familiar with the topic15:22
dhellmannsmcginnis : thanks15:22
dhellmannmnaser : good point15:22
EmilienMttx: are these our constellations? they look like it anyway15:22
mnaserso i support taking items that have a single driver and aiming for at least two15:22
zanebdhellmann: how long are we planning to keep around stuff that is marked as Approved in the list?15:23
dhellmannzaneb : until I send the next TC update email on Monday15:23
dhellmannI skipped this week because there were so many forum update emails already15:23
zanebthat makes a lot of sense :)15:23
ttxEmilienM: kind of -- depends on what we mean by constellation :)15:24
dhellmannok, 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 week15:25
dhellmanndid I miss anything other than the work dims has started on writing up job descriptions for the help-wanted areas?15:26
dhellmannI will add that item after I send my summary of the joint leadership meeting, if dims doesn't beat me to it15:26
dimsno rush dhellmann :)15:26
dimsgot some feedback from Chris Price on email15:27
dhellmannmaybe we want to move on to other topics, then?15:27
dhellmannoh, good15:28
zanebwhen is it kosher to post info from the board meeting? usually jbryce posts a summary, but he wasn't actually there...15:29
dhellmannthere are different rules for the board meeting, I think15:29
dhellmannthe board asks members not to post summaries before the official minutes are posted, I think?15:30
smcginnisI 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
dhellmannbut I don't think that applies to the joint leadership meeting, since that's not a board meeting15:30
dhellmannI was going to post an email summary based on my own notes as a personal summary15:30
zanebas a participant in the meeting, I would feel uncomfortable posting a summary before other participants (i.e. board members) are allowed to15:31
fungiright. yeah, official minutes will presumably eventually appear at15:31
dhellmannzaneb : right, my point is that the rule on official minutes does not apply here15:31
dhellmannwe met with the board, but it was not an operating meeting of the board of directors15:31
dhellmann*part* of the day was, but I wasn't in the room then so my summary won't cover that anyway15:32
mnaseryeah, afaik it is a "joint leadership meeting"15:32
fungibut only the board members (and possibly foundation staff?) are expected to refrain from making public comments before the minutes are posted15:32
zanebwell, there was a roll call and a motion was approved15:32
zanebwhile we were there15:32
dhellmannyes, true, that portion of the meeting was more official than the rest15:32
fungioh, 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 substance15:32
mnaserdo we want to confirm with the board to have a clear understanding?15:32
dhellmannthe agenda that day was a bit messy15:32
dhellmannok, I'll ask Alan before I post anything15:33
mnasermaybe 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 meeting15:33
dhellmannthe review about goal champions needs 1 more vote, so please take a look at that when you have time15:34
dhellmannwhat else is on your minds this week?15:36
TheJuliadhellmann: you have the extra vote now15:37
funginow 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 store15:38
dhellmannTheJulia : thanks15:38
* ttx crosses one more item from his giant list15:38
dhellmannfungi : ++15:39
fungi#link key store in base services15:39
zanebfungi: are we going to specify which key store?15:39
fungiwas the start of the thread where it was suggested15:39
dhellmannfungi : 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 use15:39
fungizaneb: consensus so far seemed to be around "a castellan-compatible key store" without specifying any one in particular15:40
mnaserone 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 stores15:40
zanebok, that makes sense15:40
mnaserafaik castellan has a 'vault' driver, but barbican also has one too15:41
fungimnaser: well, castellan was the result of complaints that barbican meant having an extra service15:41
zanebwhen people were saying Barbican in particular I was wondering if it was more a job for constellations than base services...15:41
mnaseri guess this could be a start in openstack projects being able to be used independently15:41
mnaserwhich is good too15:42
fungiapparently 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 manage15:42
dhellmannI 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 use15:42
zanebdhellmann: 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.db15:44
dhellmannyes, that is a bit unusual15:45
dhellmannI guess one difference is whether the secret is part of the deployment or something owned by an end-user15:45
dhellmannso 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 else15:46
fungii 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 it15:49
dhellmannsure. 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
dhellmannmaybe that workflow is normal and expected, though, I just don't know15:51
ttxThe reason that Vault it plugged both at castellan and Barbican levels is because those things do not strictly overlap15:52
dhellmannyeah, 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 store15:53
fungidhellmann: 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 testing15:54
dhellmannI guess I'm not being clear.15:54
dhellmannIf a user has to create a key to use a feature in cinder, is Vault "good enough"?15:54
dhellmannBecause 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
ttxdhellmann: I /think/ castellan will let you create a key on Vault alright15:55
fungiif 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 requirement15:55
dhellmannttx: 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 weeds15:56
dims - create_key15:56
dimsand yes vault manager supports it15:57
ttxdims: yeah15:57
dhellmannTheJulia : definitely muddy water, if not weeds15:57
dhellmannright, castellan *can* talk to vault, but it's not a REST API15:57
dimscorrect, calls vault directly -
fungifrom 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
dhellmannso 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 API15:58
mnaseri 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
dhellmannok. I just think it's not going to be useful if there's not also a way for users to actually interact with the store15:58
fungii don't follow15:58
zanebso 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 it15:58
ttxDoes Cinder volume encryption require you to provide your own key ? Or does it just generate one for you ?15:58
mnasergood question for smcginnis ^ ? :)15:58
fungietcd has a non-openstack api and it's in the base services list15:58
dhellmannfungi : do we expect users to interact with etcd?15:59
dhellmannzaneb : yes, that's a good way of putting it15:59
zanebfungi: the cloud user never has to poke any data into etcd15:59
fungii'm still not following. we wouldn't be saying deployments are required to expose cinder volume encryption either way15:59
dhellmanndo we want every service to invent its own API for creating or uploading keys?15:59
ttxdhellmann: hrm, isn't that what Castellan does ?16:00
dimsdhellmann : we want them to use the common library (like oslo.db and oslo.messaging)16:00
zanebfungi: if there's no OpenStack API for secrets available then every API becomes an API for secrets, proxying via Castellan on the back end16:00
dhellmannwe do not, in any other case, require users to use our client libraries16:00
fungiwe'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 users16:00
ttxAlso "creating" and "uploading" are not two separate things16:00
* TheJulia feels like people are approaching this from different contexties and that we need to actually write it down at this point16:01
ttxYou create keys on the secret store.16:01
*** kumarmn has quit IRC16:01
dhellmanndims : end users do not use those libraries, though16:01
dimsdhellmann : right, they use the native stuff directly like vault or barbican16:01
fungitake 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 store16:01
fungithat has nothing to do with end users uploading keys16:02
zanebfungi: yes, that's a case that castellan works for16:02
* smcginnis had to step away for a bit, reading scrollback16:02
fungiso i really, really, really don't see where this "exposing non-openstack apis to end users" tangent is coming from16:02
dimsit's not just vault, folks want to use castellan + custodia ( )16:02
*** kumarmn has joined #openstack-tc16:02
dhellmannfungi : true. that's 1 use case. Is that the only case where being generic about the keystore is useful?16:02
ttxI'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 Castellan16:03
dimsand KMIP
dimsyep ttx16:03
ttxNow I'm missing most of the context from that discussion16:03
dhellmannfungi : 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
ttxBut I remember us going into deep16:03
fungiin fact, the previous time we discussed it we convinced the barbican team to create castellan so that we could consider it for this purpose16:03
zanebe.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 directly16:04
dimswith dave-mccowan and kfarr and others16:04
dhellmannok, 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
mnaserif that discussion of 'castellan vs barbican' has been had and a conclusion has been reached16:04
mnasermaybe we should just focus on the base services discussion16:04
zanebbut that feature will obviously be unavailable on clouds without Barbican, even if they have Vault16:04
dimsdhellmann : another data point, some folks like Huawei have their own barbican equivalent, so castellan is the better integration point16:05
ttxzaneb: right -- so THAT was raised as an unresolved issue last time. Reliance on Barbican-specific features16:05
dhellmannI 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
zanebI'm ok with that btw. just trying to clarify Doug16:06
dhellmannthanks, zaneb16:06
ttxIt might still be a problem16:06
fungiyeah, 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 nice16:06
zanebDoug's point that not all features we might want will be enabled by having just castellan16:06
mnaserwell, we can always extend castellan16:06
mnaserto support barbican specific features16:07
zanebenter key and the apostrophe key are too close as usual16:07
dhellmannmnaser : we cannot require users to use a specific client library for the trademark programs16:07
ttxmnaser: except those "features" are out of scope for Vault16:07
dhellmannso we have to enable a REST API for those things at some point16:07
dhellmannand right now our REST API for this is barbican16:07
ttxBasically the issue here is that Barbican is more than a store16:07
ttxwhich is why it can plug into Vault for store feature16:07
fungicastellan could also be extended to have multiple drivers for those different features to placate people who really don't want barbican running16:08
dimsyep fungi16:08
mnaserso maybe for now we can say 'castellan' but eventually drop it if we really start running into issues16:08
smcginnisCinder 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
mnaserwe might be discussing something that is non problematic?16:08
ttxThe other factor here is that ANYTHING is better than the current situation so we tend to jump on anything that passes16:08
smcginnisI 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 IRC16:09
dhellmannsmcginnis : how would you implement user-provided keys?16:09
dimswe should start with castellan as a base library requirement, then if barbican takes hold among operators then we can go to full dependency on barbican16:09
dhellmannyeah, it's a fine first step. I just expect us to have to revisit it very soon.16:09
smcginnisdhellmann: That's the open question.16:09
mnaser++ dims16:09
smcginnisdims: ++16:09
dhellmannmaybe when that happens it will be clear why in a way that I seem unable to express.16:09
*** kumarmn has joined #openstack-tc16:09
*** jpich has quit IRC16:09
fungii 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
smcginnisI remember DuncanT had some concerns about Barbican, but I do not know enough about that area to really comment.16:10
ttxdims:  that sounds a bit... weird though16:10
ttxPeople who end up doing Castellan+Vault might be forced to change16:10
mnaserarent those the same people who didnt want to run barbican in the first place? :\16:11
dhellmannkeystone 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
dimsmysql / postgresql situation16:11
TheJuliaI 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 IRC16:12
TheJuliaIf the projects evolve to have that need, so be it, but at that point it is a conscious decision.16:12
ttxI 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 IRC16:12
dhellmannttx: I guess I am questioning that 90% number, though.16:12
*** kumarmn has joined #openstack-tc16:12
mnasermaybe this is an outlier and not the time for this comment, but barbican really isn't that heavy of a service.16:12
mnaserit's a simple rest api, it can integrate with vault if you're already running it16:13
clarkbas 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 all16:13
dhellmannlet's get a concrete proposal written up and have some project teams comment on it16:13
TheJuliamnaser: 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 requirements16:13
fungiand 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 useful16:13
ttxLast time the only things that were raised as potentially needing Barbican were Octavia and Designate iirc16:13
ttxOctavia now uses Castellan...16:13
johnsomOctavia support both16:14
mnaserTheJulia: 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 it16:14
ttxSo 90% might be 99% :)16:14
ttxjohnsom: OR or AND ?16:14
smcginnisclarkb: That's a good point.16:14
clarkbjohnsom: and octavia has its own apis for storing certs?16:14
*** kumarmn has quit IRC16:14
TheJuliamnaser: empowering the deployer to make the choice seems.. ideal, at least to me.16:15
johnsomCurrently it is an OR, but with flavors (coming) it could be AND.16:15
*** kumarmn has joined #openstack-tc16:15
zanebso Heat needs Barbican for multi-cloud. It's fine if that's a soft dependency, but obviously better if it were available to everyone16:15
ttxjohnsom: no I mean you need one of them, not both, right ?16:15
johnsomclarkb No, the user provides Octavia with the reference to the secrets. We do not have an upload interface.16:15
clarkbjohnsom: 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
dhellmannjohnsom : how does the user create the secret?16:16
johnsomttx It's an operator choice thing.  Barbican has been supported for a long time, but people wanted Vault so we added Castellan16:16
dhellmannfungi , you started the meeting, do you want to close it out?16:18
johnsomdhellmann 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
fungioh! sure16:18
clarkbon an interop front ^ is not very friendly and is another case of infra wouldn't use that feature16:18
dhellmannjohnsom : ok, so that says to me there is no workflow that the interop group would consider for the octavia service16: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 | | channel logs"16:18
dimsthanks fungi16:18
openstackMeeting ended Thu May 31 16:18:54 2018 UTC.  Information about MeetBot at . (v 0.1.4)16:18
openstackMinutes (text):
fungiwe can of course continue discussing16:19
ttxdhellmann: I think I understand your point now16:19
johnsomdhellmann Can you tell me more about that?16:19
zanebam I reading right that we already have a castellan UI and a barbican UI for adding secrets?16:19
zanebbecause that was a major facepalm moment for me16:20
dhellmannjohnsom : if part of the workflow involves an arbitrary service that is up to the deployer it is by definition not interoperable16:20
*** kumarmn has quit IRC16:20
clarkbour interop requirements also require end user apis not UIs16:20
clarkbUIs aren't programmable infrastructure friendly16:20
ttx(I just wish we would have raised it before we asked to make Castellan a thing)16:20
johnsomdhellmann The same could be said of our use of Nova and Neutron I guess16:21
*** kumarmn has joined #openstack-tc16:21
dhellmannttx: castellan is still useful, because operators may want to store their system-level secrets in something other than barbican16:21
dhellmannjohnsom : nova and neutron are part of the interop program already. something like vault is not.16:22
johnsomdhellmann From our perspective we have API parameters that take a reference and we "figure it out"16:22
dhellmannjohnsom : if you can use something other than nova to create VMs, then maybe16:22
zanebAdjutant workflow to add a secret to Vault in 3... 2... 1...16:22
ttxzaneb: lol16:22
mnaseri think if we imagine castellan as oslo.secret_store, it makes a lot more sense, seeing it as a system side thing only16:23
dhellmannmnaser : yes, we decided that renaming it was too painful to be useful16:23
mnaserbut anything user facing shouldn't involve it, and should involve barbican only16:23
mnaser(oh, it's just how i imagine it personally to clarify it personally)16:23
dhellmannthat's what it actually is: an abstraction layer that binds oslo.config to the driver to talk to the secret store16:24
johnsomdhellmann 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
dhellmannso it is just like oslo.messaging or oslo.db, just not named that way because another team created it16:24
dhellmannjohnsom : 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
johnsomOr the ML2 drivers for neutron for example, some require OVS, others not16:25
smcginnisI wonder if renaming to oslo.secret_store would actually make it easier for folks to understand though.16:25
*** kumarmn has quit IRC16:25
dhellmannsmcginnis : probably16:25
*** kumarmn has joined #openstack-tc16:25
ttxfunny we had that discussion too16:25
ttxso the question is whether asking castellan to be in base service makes it less or more difficult to get Barbican used16:26
zanebjohnsom: 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 clouds16:26
johnsomdhellmann 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
smcginnisBut 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
dhellmannjohnsom : 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 IRC16:27
zanebyeah, I feel like this is our problem to fix, not Octavia's16:28
dhellmanncastellan is only useful for features where the user doesn't interact with the keys through the REST API16:28
*** kumarmn has joined #openstack-tc16:28
johnsomdhellmann So that means, yes, we would have to drop Castellan support of Vault and go back to only allowing Barbican16:28
jbrycezaneb smcginnis dhellmann - just catching up. it's fine to post about the meeting16:28
ttxdhellmann: so you would go directly to Barbican as a base service ?16:28
dhellmannjbryce : thanks16:28
mnaseri 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 say16:28
dhellmannttx: yes16:28
smcginnisjbryce: Thanks!16:28
dhellmannjohnsom : barbican can front vault, so deployers could still use it16:29
zanebdhellmann: 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
dhellmannI'm not sure if there's a separate barbican client library, or if that's wrapped up in castellan, too16:29
jbryceThe 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
ttxdhellmann: if it can really front Vault, yes16:29
dhellmannzaneb : sure, ok16:29
zanebjbryce: thanks!16:29
johnsomdhellmann Last we checked it still did not support Vault.16:29
dhellmannok, well, then we should address that if we have users who want to use vault16:29
mnaseri think barbican has vault support16:29
mnaserlet me verify this16:29
*** kumarmn has quit IRC16:30
dhellmannjbryce : thanks for the clarification on the rule, too16:30
*** kumarmn has joined #openstack-tc16:30
mnaserit does16:30
dhellmannmnaser : does it *work*?16:30
smcginnisSO this is kind of like trying to say oslo.db and mysql are base services.16:30
mnaser merged 17 days ago and it seems to have plenty of tests16:30
smcginnisI 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 IRC16:30
smcginnisBut we should probably pick $implementation so there is always at least one available.16:31
dhellmannsmcginnis : 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
mnaserbarbican uses castellan based stores now16:31
ttxdhellmann: that's definitely new input. Last time we asked, nobody was interested in developing a Vault backend for barbican itself16:31
fungii'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 though16:31
*** kumarmn has joined #openstack-tc16:31
jrollwould 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
smcginnisdhellmann: And castellan provides that REST API abstraction, right?16:31
jrollI don't think the vault backend solves that issue16:31
dhellmannI 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
smcginnisSorry if I've missed some of the details in the scrollback. Still too distracted with things.16:32
mnasercastellan is a library16:32
dhellmannsmcginnis : no. castellan is a python client library. It doesn't do any REST.16:32
dhellmannit is not a service.16:32
smcginnisGood, I didn't think so.16:32
smcginnisSo what is the REST API that we need to have exposed?16:32
dhellmannat least that's our current REST API for key management.16:32
ttxdhellmann: my fear is that saying "any castellan-compatible backend" makes it more difficult to say "Barbican" in the future16:32
fungii 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
smcginnisThat'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
dhellmannttx: good point, it might16:33
mnaserhow about adding 'vault' to the base services16:33
ttxwould be a bit like saying "any castellan-compatible backend as long as it's Barbican"16:33
mnaserjust like etcd was added for oslo.config related stuff16:33
mnaserwe don't have a "oslo.config compatible backend"16:33
dhellmannsmcginnis : 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 themselves16:33
ttxwell, users don't interact with etcd16:33
smcginnisdhellmann: And for a project to have that, they can use castellan.16:34
dhellmannmnaser : oslo.config doesn't have drivers, yet (we're working on it)16:34
mnaserdhellmann: right, but i was just kinda putting that in theory16:34
smcginnisSo I'm still confused where the REST API is coming into play.16:34
smcginnisIf that's our goal.16:34
dhellmannsmcginnis : how does a user of cinder tell cinder which key to use?16:34
smcginnisIt'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
dhellmannhow is it expressed? do they pass the key? an ID? something else?16:35
*** amotoki has quit IRC16:35
fungii'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 all16:35
zanebsmcginnis: 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 IRC16:35
* ttx unfortunately has to drop from that information gathering exercise16:35
smcginnisI 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
dhellmannfungi : 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-tc16:35
mnaseri 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
dhellmannsmcginnis : and I think it should be "go to barbican, create/upload a key, get the UUID, pass that to cinder"16:36
fungidhellmann: right, that is in fact my only concern wit the current (not-yet-written) proposal is if it makes barbican less easy to add later16:36
smcginniszaneb: Right now admin configures it and sets it in the volume type extra specs I believe.16:36
smcginnisdhellmann: I don't think that would be a clean user experience though.16:37
zanebah, so it's not something a user can do16:37
dhellmannyeah, anything hidden from a REST API user isn't the problem. castellan is fine for those cases.16:37
johnsomdhellmann That is the workflow we have today with Barbican16:37
fungimnaser: 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 services16:37
smcginnisdhellmann: 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
dhellmannsmcginnis : 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
clarkbthe 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 me16:37
*** amotoki has joined #openstack-tc16:37
clarkbunless they also own my domain16:37
smcginnisCinder should probably own that whole interaction.16:37
smcginnisdhellmann: Yes, because the use case will be service specific.16:38
clarkbcinder is different in that it can encrypt with an arbitrary key as long as it knows what that key is16:38
johnsomclarkb Correct, we are not is the user CA business16:38
mnaseris there any use case where a service needs to use a secret store that is not user facing?16:38
dhellmannsmcginnis : how is creating an encryption key service-specific?16:38
zanebsmcginnis: you really want to own secrets upload? I would run a mile from that16:38
smcginnisdhellmann: It's not, but "I want a new volume and please encrypt it using this key" is.16:38
mnaserbecause all the scenarios i imagine involve the user interacting with the secret store16:38
fungiclarkb: the designate dnssec case is a nice counterpoint to that, where it wants an hsm16:38
dhellmannmnaser : yes, we're enabling secret stores in oslo.config for deployment secrets like database passwords16:38
dhellmannsmcginnis : sure. pass the UUID in to represent the key, that makes sense.16:39
smcginniszaneb: Should be just a matter of passing what they provide off to a castellan call.16:39
dhellmannbut where do you get "this key" in the first place? that is not cinder's job.16:39
smcginnisdhellmann: 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
johnsomfungi I don't follow. An HSM is not a certificate authority that generates certs.16:39
smcginnisdhellmann: If cinder is owning encrypting a volume with a user provided key, I do think it is cinder's job.16:40
dhellmannand 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 them16:40
zanebsmcginnis: yes, it's not hard to do. it also puts you inside a security perimeter you don't want to be in16:40
smcginnisThis is all theoretical since no one has actually proposed a design for cinder to do this yet.16:40
dhellmannsmcginnis : it's cinder's job to use the key. I'm less sure it's cinder's job to create the key.16:40
clarkbsmcginnis: right that is why I am pointing to octavia which actually does this stuff today aiui16:40
dhellmannor to return it to the user when they ask to see it16:40
fungijohnsom: "ahardware security module is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing"16:40
smcginniszaneb: We already are in the security perimeter I think when we're setting up volume encryption.16:40
smcginnisdhellmann: Not create, be provided.16:41
dhellmannright, I'm talking about the APIs for managing keys, not for using them.16:41
smcginnisdhellmann: Not returning to the end user to see it. Just taking what they provide.16:41
johnsomfungi Correct, they typically do not generate certs16:41
fungijohnsom: some hsms provide their own keys so that the key material never exists outside the hsm even for bootstrapping purposes16:41
clarkbfungi: 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 CA16:42
fungijohnsom: "cryptoprocessing" in that sense includes tasks like signing provided material16:42
* dhellmann needs lunch16:42
clarkbthe cloud itself isn't (likely) going to be a trusted CA16:42
fungiclarkb: correct. the hsm can provide you with a csr16:42
fungiclarkb: then you take that csr to your ca and get them to provide you with a certificate16:43
fungiand the key never leaves the hsm16:43
johnsomCorrect, and even for encrypted at rest most companies require use of an internal CA. It's really about the revocation and ownership.16:43
funginow clearly that doesn't help in situations where you want the webserver to have access to the key material16:43
clarkbfungi: or if you want bakcups of your key16:44
fungithis is more relevant for less frequent key use, such as dnssec signing16:44
fungiclarkb: right16:44
johnsomfungi Actually, if you are having the HSM sign in the enclave you present a CSR to the HSM16:44
*** kumarmn has quit IRC16:44
fungijohnsom: sure, you're talking about hsm use within a ca16:44
fungii'm not talking about ca-related uses16:44
*** kumarmn has joined #openstack-tc16:45
clarkbhowever with cinder encryption using a key I gnerated vs a key the cloud generated is largely the same operationally16:46
clarkbI 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 key16:46
clarkbthe only upside to generating my key is that I will know later if the generation method is found to be insecure16:47
fungiconsider 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 was16:47
fungisigned by a key known only to that machine's hsm16:47
*** kumarmn has quit IRC16:48
*** kumarmn has joined #openstack-tc16:48
fungithis is very similar to how dnssec operates16:49
clarkbfungi: as an end user of the cloud you don't know that an hsm is used though right?16:50
fungiright. i was trying to explain why designate would want a key store with hsm-like features16:50
clarkbI 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 scenes16:51
clarkbI can be told but can't verify16:51
fungisure. this is also why the infra team runs its own nameservers in virtual machines it controls16:51
dimsmnaser : barbican uses castellan to talk to vault :)16:52
zanebso it's castellan->barbican->castellan->vault (potentially)?16:54
dimsthanks for starting that tangent thread smcginnis16:56
smcginnisdims: 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. ;016:58
clarkbgoing 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 color16:59
clarkbI 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 thing17:00
clarkbthe concerns about color blindness and green and red conflicting are valid though and there are guidelines published on how to better accomodate for that17:00
smcginnisI 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
clarkbI 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
smcginnisHah, right.17:03
smcginnisMaybe we should have an official suggestion to use Stylish if red bothers you.
clarkbI 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 places17:08
clarkbwe 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 it17: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
clarkbthat 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 fixed17:10
clarkbthis is why we do pre merge code review17:10
smcginnisCan we fit all that in a tooltip when they hover over a -1? :)17:11
clarkbsmcginnis: probably not on fungi's browser screen but it may fit on everyone elses :P17:12
clarkb talks about this in the linux kernel17: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 is17:15
fungiwe do already try to explain some of this in the welcome comment left on a new contributor's first change17:15
fungialong with pointers to places to read more about how our community operates17:16
clarkbya I think that was a really helpful thing that fifieldt helped to add17:17
mtreinishclarkb: heh, my first kernel patch experience was very different: was frustrating not because it got blocked. But more because of the tone and how they did it17:41
mtreinishgoing from that environment to openstack was a big improvement17:42
clarkbmtreinish: wow17:46
clarkbmtreinish: 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 above17:46
clarkbhwoever good to hear that you found it an improvement :)17:46
*** edmondsw_ has joined #openstack-tc17:51
*** edmondsw has quit IRC17:54
fungii do find examples like that from other communities helpful in getting some contrasting perspective17:55
openstackgerritJulia Kreger proposed openstack/governance master: Add principles entry for peer review
*** diablo_rojo has joined #openstack-tc18:31
TheJuliaclarkb: 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
clarkbTheJulia: right but that isn't a problem with properly used -1'18:53
zanebclarkb: 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 this18:53
clarkbthe fix is to improve our reviewing not change the color of gerrits string18:54
zanebso I agree that changing the color is a waste of time18:54
TheJuliaclarkb: agreed, but there is a varying definition of what that setting is for18:54
clarkbnow separately we might change colors to help those that are color blind but I Think that is an orthogonal concern18:54
TheJuliaI totally agree as well, the color is not going to change perception18:54
*** diablo_rojo has quit IRC18:55
TheJuliahave a "change to high contrast?" button for the stylesheet?18:55
zanebwe should change the caption to "-1 today I am going to obstruct your work"18:55
zaneb(kidding. mostly.)18:55
clarkbTheJulia: 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 too18:56
clarkbI also think that the best way to address these problems is to lead by example18:58
*** cdent has joined #openstack-tc18:58
TheJuliafeels like that should at least go back to the gerrit community as "hey, random thought/idea, do with it what you will"18:58
clarkbcode reviews in projects (particularly by core members) reflect what is basically tribal behavior around teh code base18:58
clarkband it varies within openstack to a great degree18:59
*** edmondsw_ is now known as edmondsw18:59
dhellmannspeaking of tribal behavior, I just finished reading this article about the "Nut Island Effect" and found it pretty interesting
clarkbif 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 it19:00
TheJuliaI personally have done that to mixed results19: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
TheJuliathe problem is I respect the -1 votes because I'm an idealist.19:01
dhellmannclarkb : do you have suggestions for ways to do that?19:02
clarkbdhellmann: I think it starts by asking core reviewers directly to chagne behavior, then on reviews where it is happening overriding the unwanted behavior19:03
TheJuliaclarkb: 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
clarkba -1 does not mean it cannot merge19:03
TheJuliaDo we have any stats on how often patches with an oustanding -1 actually merge versus otherwise?19:04
dhellmanndo you feel like there's some prerequisite to updating the list of principles/19:04
clarkbdhellmann: 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 that19:05
TheJuliaclarkb: 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
dhellmannTheJulia :
dhellmannok, I guess I'm not sure what you're objecting to19:06
clarkbin 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 explicitly19:06
dhellmannare you commenting on this patch?
dhellmannor the conversation in general?19:06
clarkbdhellmann: is that directed at me?19:06
clarkbdhellmann: I'm objecting to the idea that changing UI is going to make anyone feel better19:06
clarkbInstead I think direct communication with involved parties is necessary19:07
dhellmannyeah, I wasn't considering that as a serious proposal19:07
clarkbas 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 problems19:08
TheJuliaNor 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 misused19:08
clarkbcode review is almost entirely about communicating19:08
clarkbwe are failing at communicating in the arena of code review19:09
TheJuliaCompletely agree19:09
dhellmannclarkb : I'm much more interested in your input on that patch than any discussion of colors in gerrit :-)19:09
clarkbnoted, I shall review it shortly19:10
cdentHave I missed anything super important in the last few days (since summit)?19:13
TheJuliait 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
TheJuliacdent: eh.... *shrugs*19:13
dhellmanncdent : I started trying to make a list of everything we're working on in the wiki:
dhellmannI would appreciate it if you'd double check that I have your name down in all the right places, and that I've captured everything19:14
dhellmannI already know it's missing the thing about job descriptions and help-wanted areas19:14
cdentthanks, will take a look. I'm not fully back yet (in california) but somewhat looping myself back in19:15
TheJuliathanks to whomever updated the wiki after the meeting for the trove portion19:15
*** dklyle has quit IRC19:18
* TheJulia is now curious how much feedback the -1'ed principles change will garner19:18
*** dklyle has joined #openstack-tc19:18
cdentdhellmann: I'll go through that at some point in more detail and try to add my name in a few more places19:18
TheJulialikely not at all representative since I emailed the ml19:18
dhellmanncdent : thanks!19:19
*** dklyle has quit IRC19:19
*** david-lyle has joined #openstack-tc19:19
smcginnisThe 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
dhellmannso maybe we need to do something to highlight those sorts of patches?19:24
smcginnisNot 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
clarkbsmcginnis: I think that would be less problematic if we were better about using -1's when they make sense19:25
clarkbbecause then it is something that needs valid rework and you can wait on it19:26
*** cdent has quit IRC19:27
TheJuliaI 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 IRC19:29
*** dklyle has joined #openstack-tc19:29
*** kumarmn has quit IRC19:30
*** kumarmn has joined #openstack-tc19:30
*** kumarmn_ has joined #openstack-tc19:34
*** kumarmn has quit IRC19:34
*** kumarmn_ has quit IRC19:37
*** kumarmn has joined #openstack-tc19:37
clarkbTheJulia: 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 IRC19:42
TheJuliaIt ia a totally valid point to me19:42
TheJuliaJust 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-tc19:43
fungii 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 them19:47
*** kumarmn has quit IRC19:48
clarkbfungi: did you see I have a verified -1 in bindep I'd like you to review :)19:49
fungiyes, i did. also need to prioritize! ;)19:49
clarkbfor concrete examples of how I think review should go (and I'm biased here obviously) which sort of resulted in
fungiwe _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 community19:50
* TheJulia facepalms, and goes and opens a beer19:51
*** kumarmn has joined #openstack-tc19:51
fungii missed my sarcastic winky smiley ;)19:51
clarkbwe 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 punishment19:52
fungiworth 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
TheJuliafungi: oh, good, the ;)19:56
fungithough in the case of the governance repo we actually only give _real_ power (the workflow +1) to our elected chair19:58
* smcginnis would so love a casual nick Friday where dhellmann changes his nick to HisHighness19:58
* TheJulia notes that Friday is fast approaching20:00
TheJuliaToday is Thursday right?20:00
clarkbI thought yesterday was tuesady20:00
clarkbsummit then holiday has me really confused20:00
*** harlowja has joined #openstack-tc20:01
fungifriday starts in just under 4 hours20:03
fungibrace yourselves!20:04
TheJuliamass casual nick friday in 4 hours?20:04
fungianyway, 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
jrolldon't forget /nicklock :P20:07
clarkbin 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 numbers20:08
clarkbpeople have assumed that if you had a +1 and a -1 that balacned things out for example20:08
TheJuliaI can't help but wonder if that would be better as time goes on and the community evolves...20:09
TheJuliaAnyway, I'm actually going to ignore IRC for a little while.20:09
clarkbit may be but it isn't how gerrit operates so would require work20:09
* TheJulia had an idea about that, but it is presently locked in reserved for "later"20:10
fungithe bigger misconception is "you say it needs two +2 votes so why don't four +1 votes work?"20:11
zanebthat confused that heck out of me when I first started on OpenStack20:12
zanebfungi: I seem to recall it was you who had to explain it to me ;)20:13
smcginnisMaybe we need to change the votes to emojis instead.20:13
fungi-2 = stop sign; -1 = question mark; +1 = thumbs up; +2 = beer mug20:14
* fungi is of course, still kidding20:14
clarkbpersonally I don't think a math based system would work well. It would devolve to popularity contests20: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 kidding20:15
smcginnis++ :)20:15
clarkbwhat do we give workflow +1?20:15
clarkbgiant check mark?20:16
smcginnisRocket ship?20:16
jrollthe two beers clinking, ofc20:16
zanebgreen traffic light?20:16
fungicrashing rocket ship20:16
jroll🍻 to be clear20:16
TheJuliaHow about just a rocket?20:31
fungiif you look at the gerrit instance which gerrit upstream runs, they have a mix of red X, green checkmark, red -1 and green +1
fungithough the polygerrit interface changes all of this around, so might make more sense to defer gerrit skinning discussions until the next ui20:36
zanebdims: YES20:43
*** harlowja has quit IRC21:00
spotzok I"m jealous you got emojis in IRC!21:17
*** dklyle has quit IRC21:17
*** dklyle has joined #openstack-tc21:18
smcginnisspotz: Poor (wo)man's IRC emoji - copy and paste from here:
spotzoooh cows....21:20
clarkbmy 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 it21:20
smcginnisThough 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
smcginnisclarkb: Yeah, they're small for me too.21:21
smcginnisspotz: Actually copy the picture, it should work.21:21
smcginniscowsays yeah!21:21
spotzwhere are asettle and mhayden to torture when you need them:)21:22
* TheJulia giggles at emojis in irc21:32
*** kumarmn has quit IRC21:32
*** kumarmn has joined #openstack-tc21:33
* fungi just considers them glyphs for extended unicode codepoints21:35
*** kumarmn has quit IRC21:38
*** diablo_rojo has joined #openstack-tc21:40
*** cdent has joined #openstack-tc21:40
spotzThe things I learn on the TC channel:)21:45
*** diablo_rojo has quit IRC21:50
*** mriedem has quit IRC22:05
*** gagehugo has quit IRC22:05
*** diablo_rojo has joined #openstack-tc22:09
*** lbragstad has quit IRC22:18
*** harlowja has joined #openstack-tc22:21
*** lbragstad has joined #openstack-tc22:23
TheJuliaWe're just a bunch of geeks :)22:27
*** ricolin has joined #openstack-tc22:39
*** cdent has quit IRC22:40
*** hongbin has quit IRC22:41
fungii.e., some genius mapped the old ms "wigdings" font into some unused codepoint range and got the unicode consortium to ratify them22:48
*** gagehugo has joined #openstack-tc22:48
fungier, wingdings22:49
clarkbthat is wingding for :)22:51
fungiwhich is i-hit-the-wrong-compose-key for touché22:59
*** cdent has joined #openstack-tc23:58
*** kumarmn has joined #openstack-tc23:59

Generated by 2.15.3 by Marius Gedminas - find it at!