| *** ricolin has joined #openstack-tc | 00:49 | |
| openstackgerrit | Michael Johnson proposed openstack/governance master: Octavia asserts supports-accessible-upgrade https://review.openstack.org/577970 | 00:50 |
|---|---|---|
| fungi | tc-members: there's an office hour afoot | 01:00 |
| fungi | #startmeeting tc | 01:00 |
| openstack | Meeting started Wed Jun 27 01:00:50 2018 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. | 01:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 01:00 |
| *** openstack changes topic to " (Meeting topic: tc)" | 01:00 | |
| openstack | The meeting name has been set to 'tc' | 01:00 |
| mnaser | o/ | 01:00 |
| fungi | #topic Office Hour | 01:00 |
| zaneb | oh it's that time | 01:00 |
| *** openstack changes topic to "Office Hour (Meeting topic: tc)" | 01:00 | |
| * fungi is already a touch sleepy | 01:01 | |
| mnaser | #chair zaneb mnaser | 01:02 |
| mnaser | i cant do that can i | 01:02 |
| fungi | #chair zaneb mnaser | 01:02 |
| openstack | Current chairs: fungi mnaser zaneb | 01:02 |
| fungi | now you could but it would be redundant | 01:02 |
| zaneb | lol | 01:02 |
| mnaser | :) | 01:02 |
| zaneb | no more reviews from our alleged bot came in today | 01:04 |
| fungi | i still owe everyone a summary of points from last thursday's office hour around icla vs dco, implications on sso, et cetera. haven't forgotten, just haven't gotten to it yet | 01:05 |
| pabelanger | o/ | 01:07 |
| mnaser | #chair pabelanger | 01:08 |
| openstack | Current chairs: fungi mnaser pabelanger zaneb | 01:08 |
| zaneb | \o it's been real | 02:00 |
| fungi | #endmeeting | 02:01 |
| *** 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/" | 02:01 | |
| openstack | Meeting ended Wed Jun 27 02:01:08 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 02:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-27-01.00.html | 02:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-27-01.00.txt | 02:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-06-27-01.00.log.html | 02:01 |
| fungi | indeed! | 02:01 |
| scas | i would have mused more about my small but growing problem, but dinner precluded any sort of deceased equestrian percussion | 02:15 |
| *** ricolin has quit IRC | 02:40 | |
| *** ricolin has joined #openstack-tc | 02:41 | |
| *** dklyle has quit IRC | 03:32 | |
| *** dklyle has joined #openstack-tc | 04:11 | |
| *** dklyle has quit IRC | 04:52 | |
| *** dklyle has joined #openstack-tc | 04:57 | |
| *** amrith has quit IRC | 05:15 | |
| *** tdasilva has quit IRC | 05:21 | |
| *** tdasilva has joined #openstack-tc | 05:33 | |
| *** e0ne has joined #openstack-tc | 05:35 | |
| *** e0ne has quit IRC | 05:36 | |
| *** amrith has joined #openstack-tc | 05:47 | |
| *** amrith is now known as Guest2110 | 05:47 | |
| *** ricolin has quit IRC | 06:20 | |
| *** jaosorior has quit IRC | 07:23 | |
| *** tosky has joined #openstack-tc | 07:40 | |
| *** e0ne has joined #openstack-tc | 07:53 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/project-team-guide master: Add FirstContact SIG liaison duty for PTL https://review.openstack.org/578306 | 08:00 |
| *** jpich has joined #openstack-tc | 08:02 | |
| *** dtantsur|afk is now known as dtantsur | 08:22 | |
| *** ricolin has joined #openstack-tc | 08:43 | |
| *** e0ne has quit IRC | 08:46 | |
| ttx | dhellmann: corporate bus factor is pretty close to what we've been doing. Individual bus factor (scroll down) is new. Basically it reframes the information in terms of risk, rather than just saying "diverse" or "single vendor" and let people draw conclusions. Corporate bus factor is the impact if the largest-involved organization drops. Individual bus factor is the impact if the most active | 08:48 |
| ttx | developer/reviewer abandons. | 08:48 |
| ttx | notmyname: I picked 66% (2/3) for corporate bus factor and 50% for individual bus factor | 08:49 |
| ttx | It's part of a discussion on the future of team diversity tags, since they are of questionable usefulness in recent updates | 08:52 |
| ttx | But I'm getting more and more convinced that between a questionable data source and a wide variety of situations (large/small, active dev/maintenance...) a simple metric is useless and should just be abandoned | 08:54 |
| ttx | Like is the 67.4% of SwiftStack commits in Swift really comparable to the 67.9% of NTT in Masakari ? | 08:56 |
| ttx | I think not: Masakari is at a development stage where its health depends more on new commits than Swift. | 08:57 |
| ttx | So my view now is that we should use such metrics as red flags to raise questions and discuss in more detail in a healthcheck discussion | 08:59 |
| ttx | Not as badges | 08:59 |
| *** ianychoi has quit IRC | 09:14 | |
| *** ianychoi has joined #openstack-tc | 09:15 | |
| *** cdent has joined #openstack-tc | 09:17 | |
| *** jaosorior has joined #openstack-tc | 10:18 | |
| *** e0ne has joined #openstack-tc | 10:41 | |
| *** e0ne has quit IRC | 11:29 | |
| *** e0ne has joined #openstack-tc | 11:42 | |
| *** dtantsur is now known as dtantsur|brb | 12:06 | |
| *** ttx has quit IRC | 12:09 | |
| *** ttx has joined #openstack-tc | 12:22 | |
| *** mriedem has joined #openstack-tc | 12:39 | |
| *** edmondsw has joined #openstack-tc | 12:57 | |
| *** edmondsw has quit IRC | 12:57 | |
| *** edmondsw has joined #openstack-tc | 12:57 | |
| dhellmann | I'm less sure that's a good move. | 12:59 |
| dhellmann | In the swift case, it's unlikely that SwiftStack is going to lose interest in swift. | 12:59 |
| dhellmann | But in other cases, if we have a company doing 60+% of the work maintaining a project and they drop it, that's bad. | 13:00 |
| dhellmann | or at least it could be | 13:00 |
| dhellmann | context does matter, but where the project is in its development lifecycle isn't the only kind of context | 13:01 |
| cdent | I think it's also the case that percentages need to be scaled relative to total reviews/commits | 13:01 |
| cdent | 2 out of 3 means something much different from 200 out of 300 | 13:01 |
| dhellmann | yes, absolutely | 13:02 |
| dhellmann | or relatively, I guess ;-) | 13:02 |
| cdent | which I guess just supports the case of "we're not going to get a one size fits all technical solution for tracking this kind of stuff" | 13:03 |
| cdent | which I think is good and reasonable | 13:03 |
| dhellmann | sure | 13:04 |
| smcginnis | I think most projects go through an arc of initial idea and implementation, general growth, then "stable" mode where there is less need for activity and therefore participation. | 13:08 |
| *** ian_ott has joined #openstack-tc | 13:08 | |
| smcginnis | At least thinking in terms of something like searchlight that is for the most part "done", in those cases it may be OK to have a high bus factor. | 13:08 |
| * cdent lives ever in hope that nova will achieve that arc | 13:09 | |
| * cdent rotflcoptors | 13:09 | |
| smcginnis | cdent, the eternal optimist. :) | 13:09 |
| *** e0ne has quit IRC | 13:26 | |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: write up the python3-first goal https://review.openstack.org/575933 | 13:26 |
| openstackgerrit | Merged openstack/project-team-guide master: Add FirstContact SIG liaison duty for PTL https://review.openstack.org/578306 | 13:32 |
| ttx | dhellmann: I think a good trade-off is to run a report regularly (say after every release, or twice per cycle) and use that to expose potential issues in the HealthCheck tracker, for the TC liaison to investigate | 13:33 |
| ttx | but I feel like the current tags should be dropped. | 13:34 |
| *** dtantsur|brb is now known as dtantsur | 13:35 | |
| dhellmann | tc-members: I've been experimenting with tracking goal progress using storyboard. For the python 3 goal I want to track each repo, not just each team. When I create 1 story with a task for each repo, the storyboard UI becomes quite slow. So I have modified the script for creating goal tracking stories so that it creates 1 story per team and then 1 task per repo and uses a tag to link them all together. You can see the | 13:35 |
| dhellmann | results at https://storyboard-dev.openstack.org/#!/board/56 and I would appreciate your feedback on the change. | 13:35 |
| dhellmann | ttx: I agree with the idea of moving away from the tag. I'm just not sure we want to say it's OK for small teams to lack diversity. | 13:35 |
| dhellmann | The 3 most active members of the Oslo team are Red Hat employees, and that makes me uncomfortable as a Red Hatter myself and from the community angle. | 13:36 |
| cdent | dhellmann: seems reasonable. I need to come up to speed on the board part of storyboard | 13:36 |
| dhellmann | cdent : the stories will change columns on the board automatically depending on progress on the work | 13:37 |
| dhellmann | so that's pretty nice | 13:37 |
| *** e0ne has joined #openstack-tc | 13:38 | |
| fungi | as for performance loading a story with lots of tasks, i wonder if that's another case of a missing table index | 13:38 |
| ttx | dhellmann: alternate solution in storyboard is to use task notes to track individual repos | 13:38 |
| ttx | i.e. one task per team, one line in task note per repo | 13:38 |
| dhellmann | fungi : I couldn't tell if it was that or a rendering issue on the client side. either way, the UI wasn't very usable with that much data on one screen | 13:39 |
| fungi | yep, that much i get | 13:39 |
| dhellmann | ttx: it's harder to track "done" that way, though, isn't it? | 13:39 |
| fungi | lp was similarly problematic when you added 20+ affected projects to a single bug | 13:39 |
| ttx | dhellmann: less granular definitely | 13:40 |
| dhellmann | giving each team their own story also lets them add their own tasks, if they choose to do so | 13:40 |
| TheJulia | dhellmann: your example seems functional | 13:40 |
| cdent | granularity++ | 13:40 |
| cdent | TheJulia: you don't normally, but that response made you sound like a robot | 13:40 |
| dhellmann | fungi: yeah, I wasn't entirely surprised that storyboard's ability to "scale to more" didn't exactly handle "scale to all" :-) | 13:40 |
| cdent | which is great, btw | 13:40 |
| TheJulia | cdent: jet lag, ftw | 13:41 |
| cdent | \o/ | 13:41 |
| TheJulia | bad... bad... bad jet lag | 13:41 |
| fungi | TheJulia: affirmative, data accepted | 13:41 |
| dhellmann | TheJulia : I look forward to reading your trip report from Beijing when you've recovered enough to write it. | 13:42 |
| ttx | TheJulia: welcome back! | 13:42 |
| TheJulia | dhellmann: I was feeling moderately human on Sunday and submitted something to superuser | 13:43 |
| dhellmann | oh, nice | 13:43 |
| dhellmann | ++ | 13:43 |
| TheJulia | other than that, I need to make a long post to the ml on ironic. I finally picked up the requisite beer to achieve that post last night | 13:48 |
| cdent | i've considered using beer as a lubricant for the tc reports, but not worked that out in my mind yet | 13:53 |
| TheJulia | everyone is different :) | 14:00 |
| cdent | thank goodness | 14:02 |
| TheJulia | Also, everyone has their own self contained context of what community is because it is built upon their perspective and experiences | 14:06 |
| cdent | is that a sequitur or a sort of tangent based on thinking about your posts? | 14:07 |
| fungi | seems relevant to the continuation of the thread from the latest of cdent's tc reports | 14:08 |
| cdent | well that's kind of why I asked because it seems relevant to a _lot_ of things | 14:09 |
| TheJulia | It was more of a continuation of the main thing I gathered visiting beijing | 14:13 |
| cdent | TheJulia: I seem to recall a tweet in that regard | 14:13 |
| fungi | super-cdent: did you see zuul has a new pipeline manager algorithm named after you? | 14:15 |
| cdent | Sadly no, with the advent of hayfever season my ability to consume all the infos has tapered | 14:16 |
| cdent | I reckon I may need to add that to my list of rolling twitter nicks | 14:17 |
| * cdent reads https://docs.openstack.org/infra/zuul/user/config.html#value-pipeline.manager.supercedent | 14:17 | |
| cdent | ah, that makes very good sense | 14:18 |
| TheJulia | cdent: the perceptions there are also of that they have no way of really getting integrated into the larger community because they are not "big names" and thus can't drive any efforts or push for any features to be added to projects | 14:19 |
| cdent | a) it's a shame they feel that way, b) I'm not surprised they do. When I was new in OpenStack I was extremely frustrated with the mechanics of reputation building. In large part because it seemed like you needed to a) be at the midcyles/summits/etc, b) shout | 14:21 |
| cdent | both of these things are extremely difficult to do if you are not a north amercan white male | 14:21 |
| cdent | and/or your employer happens to not want to fund new people going to events | 14:21 |
| cdent | I think we need for our efforts at inclusion to be active, not passive, but I'm unclear on how. Did you get any ideas while you were the TheJulia ? | 14:24 |
| fungi | i too am curious what sort of active inclusivity efforts would be culturally acceptable | 14:29 |
| TheJulia | cdent: Well, I think we need some sort of outreach mechanism to (a) educate that we are a meritocracy, (b) that the way to convince a team that something is worthwhile and makes sense is to convey your context. Both were things I ended up doing with firms in Beijing that indicated that they felt small compared to the the other companies that have historically contributed to projects. | 14:43 |
| TheJulia | culturally acceptable in what regard? Adapting our perception of culture? The behaviors of our culture? The culture at large? | 14:44 |
| *** evrardjp has quit IRC | 14:45 | |
| *** evrardjp has joined #openstack-tc | 14:45 | |
| *** hongbin has joined #openstack-tc | 14:52 | |
| TheJulia | I guess, ultimately I agree, more active in regards to context sharing and enabling. | 14:56 |
| *** mriedem is now known as mriedem_afk | 14:57 | |
| zaneb | ricolin: any thoughts on ^ ? | 14:58 |
| scas | chef has been notoriously hard to attract new contributors since the austin summit. i always assume it to be a me-thing, since i don't hear anything either way and the channel is often reduced to a long irc monologue interspersed with joins/parts/modes/changes. i haven't been able to attend very many summits/midcycles/ptgs for a number of reasons, which seems kind of antithetical to how 'openstack, the | 15:00 |
| scas | community' operates | 15:00 |
| *** evrardjp has quit IRC | 15:02 | |
| *** evrardjp has joined #openstack-tc | 15:03 | |
| ricolin | I think what they need is more chance to reach out and encourage to try, To translate the Enterprise Guide is a start(once we have a Enterprise guide), also bring Summit/PTG close Asia might be another way (At least that what K8s will done in this year). | 15:08 |
| mnaser | scas: is it funding? travel support program should be able to support you in the case, unless time is a thing. | 15:17 |
| scas | mnaser: sometimes funding, sometimes unbelievable luck | 15:17 |
| TheJulia | I believe, since the US travel ban is now in force, I feel like future events really ought to avoid the united states... at least events that are not committed yet. | 15:17 |
| cdent | TheJulia++ | 15:17 |
| ricolin | TheJulia, +1 | 15:18 |
| mnaser | unfortunate we can't bring that up in denver | 15:18 |
| TheJulia | scas: I feel like it might be an issue of awareness. Bringing awareness that something exists is one of the barriers that we have. | 15:18 |
| scas | mnaser: vancouver was quashed on account of a family death, as an example of my amazing luck | 15:18 |
| mnaser | scas: sorry about that | 15:18 |
| scas | TheJulia: awareness is probably a big part. not having something to point someone to has been an issue until i've been able to dedicate the time to make something to point to | 15:19 |
| TheJulia | scas: sorry to hear that :( | 15:20 |
| TheJulia | Yeah, and then still finding the communications channel (not just meaning IRC... I'm not even sure direct irc connections are possible from behind the great firewall. I only know git review had issues and I couldn't access anything google related. irccloud intermittently worked. | 15:21 |
| ricolin | I only know slack is not to through great wall:) | 15:22 |
| mnaser | except it's down today | 15:22 |
| mnaser | :P | 15:22 |
| scas | yup. some of my more recent contributors have been behind the great firewall, so there's not a great feedback loop | 15:22 |
| TheJulia | ricolin: not to? not through? | 15:22 |
| mnaser | TheJulia: i think that must have been a really good experience to know what the contributor experience like for apac regions | 15:23 |
| scas | like the well-meaning five-char patch that i've had to explain is behind dealt with by <insert 12 reviews> | 15:23 |
| ricolin | TheJulia, can't go through:) | 15:23 |
| TheJulia | it is kind of painful right now since our tooling to make it easy doesn't support it out of the box | 15:23 |
| scas | s/behind/being/ | 15:23 |
| scas | i sat down and mashed together something that could be construed as documentation to kick the tires as of the more recent tooling changes, but it's yet to be published because i haven't had time until, like, today to sit down and figure out how to get it published | 15:26 |
| TheJulia | I have a mental note to amend the contributor docs to at least point out how to at least be able to push, and what information might be needed. Not sure if I'll ever get to it | 15:28 |
| scas | i'm not even sure how it'll look on docs.o.o since it started in one repo and got lifted into another repo, and hasn't had a ton of eyes look at it | 15:28 |
| TheJulia | So I guess this brings a question to how might we better improve the feedback loop? Do we all need to have wechat or something? | 15:30 |
| clarkb | TheJulia: fwiw http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html is the first duckduckgo result for "openstack push to gerrit behind great firewall" (I realize users unlikely to duckduckgo behind great firwall, maybe we just need to make that part of inframanual or contributor guide) | 15:31 |
| ricolin | TheJulia, how about strong the connect with local user group, instead of force you all to learn Chinese?:) | 15:32 |
| smcginnis | ricolin: 谢谢 | 15:32 |
| scas | it appears i restarted tmux at some point \o/ | 15:32 |
| ricolin | smcginnis, 不客气 lol (you're welcome) | 15:33 |
| *** edmondsw has quit IRC | 15:33 | |
| dhellmann | clarkb : adding it to docs and giving git-review an option to switch to https both seem like they might be helpful | 15:34 |
| TheJulia | clarkb: I was thinking contributor guide | 15:34 |
| smcginnis | I seem to recall switching to https being added to git-review. | 15:34 |
| smcginnis | Unless I'm mixing it up with something similar, which is entirely possible. | 15:35 |
| clarkb | smcginnis: dhellmann yes its fully supported as noted in that email | 15:35 |
| clarkb | I personally don't want to go recommending it because it is less secure | 15:35 |
| dhellmann | clarkb : right, I mean something like "git review -s --use-https" | 15:35 |
| dhellmann | instead of having to add the remote yourself | 15:35 |
| clarkb | dhellmann: it can't be that simple you have to have a full remote url location | 15:35 |
| scas | as far as i understand, from an outsider's perspective, irc is actively blocked behind the great firewall. that does make it harder to connect with those people, no matter if we speak the same language | 15:36 |
| clarkb | dhellmann: you can update the .gitrevie wconfig | 15:36 |
| clarkb | but that is mostly equivalent to just adding the remote yourself | 15:36 |
| dhellmann | yeah | 15:36 |
| TheJulia | ricolin: I was thinking about maybe more about emissary (not to the profits, for those that have watched Star Trek DS9) that would be able to help bridge some of the gaps. Just my wechat id showing up in a slide deck resulted in a few people making contact and asking follow-up questions w/r/t ironic. | 15:36 |
| clarkb | and I would be -2 on globally changing .gitreview because those http passwords are less secure than ssh keys because gerrits implementation is poor | 15:36 |
| dhellmann | yeah, there's no reason to make this global | 15:36 |
| clarkb | basically you cna't infer the https url from the ssh endpoint unfortunately | 15:37 |
| clarkb | so a simple toggle isn't enough | 15:37 |
| dhellmann | it seems like we ought to be able to take a combination of data from .gitreview along with maybe some options from a ~/.dotfile and build the URL properly | 15:37 |
| clarkb | dhellmann: we can't because http may not be hosted under the same root as ssh repos | 15:37 |
| clarkb | dhellmann: software factory is an example of this iirc | 15:37 |
| dhellmann | it is for us, isn't it? | 15:37 |
| clarkb | it is for us but git review isn't an openstack tool | 15:38 |
| dhellmann | make the simple things easy... | 15:38 |
| clarkb | or rather not an openstack specific assuming tool. It has many Gerrit users | 15:38 |
| ricolin | TheJulia, like the idea of emissary, but I also think it's easier if we just try to bring some of our event close to Asia and not just once in two year. | 15:38 |
| clarkb | dhellmann: thats fine if you can do so without breaking other users and that toggle will simply break for software factory for example | 15:38 |
| dhellmann | yeah, like I said, combine it with ~/.user-config-for-git-review or whatever | 15:38 |
| ricolin | When you find TheJulia is so close to you, you will try to make she answering your question right away! | 15:39 |
| clarkb | (mostly I worry that if we solve this very specific issue, we'll make life worse for the larger group of git review users. We need to carefully handle existing users and make alternate remotes easy) | 15:39 |
| TheJulia | ricolin: lol | 15:40 |
| clarkb | I do want to say you can already provide a user specific override for .gitreview remotes, fungi may know | 15:40 |
| clarkb | but setting that may be the easiest thing then its edit ~/.gitconfig && git review -s or something | 15:40 |
| fungi | oh, wow, more scrollback | 15:40 |
| TheJulia | clarkb: ++ | 15:40 |
| dhellmann | TheJulia : your comments about wechat on twitter last week were interesting, too. I sort of suspected we had divided communication channels in the overall community, but the confirmation is useful. | 15:41 |
| dhellmann | I'm not sure how I feel about signing up for another service as a way to deal with that. | 15:41 |
| dhellmann | Where does that approach end? | 15:42 |
| dhellmann | OTOH, if IRC doesn't work... | 15:42 |
| TheJulia | Wechat does have some limitations, like a maximum of 500 users in a groupchat | 15:42 |
| TheJulia | and that groupchat is invite-only | 15:42 |
| clarkb | it also has massive security concerns | 15:42 |
| fungi | TheJulia: culturally acceptable as in i wouldn't want to actively reach out in ways that turned out to be insulting due to culturally insensitivity on my part. i'm at least aware some sorts of more direct approaches are liable to cause embarrassment in certain cultures, at least | 15:42 |
| ricolin | s/make she/make her/:) | 15:42 |
| TheJulia | fungi: That is a good point. I think part of the key is a dialog and context of the fellow humans such that if one does hit something that might be insensitive or abrasive to their culture, that the recipients can at least know there is not malice nor ill intent, and this have the ability to better guide/correct the initiator. | 15:45 |
| zaneb | clarkb: I guess upstream gerrit doesn't support client certificates? reading that email thread, it sounds like that would be a much easier way to use it | 15:46 |
| clarkb | dhellmann: TheJulia looks like ~/.config/git-review/git-review.conf is an ini file and you can set [gerrit]\nscheme = https and I think that may get you there for our installation (since we host http and ssh at the same root) | 15:46 |
| clarkb | zaneb: I don't think gerrit supports client cert auth | 15:47 |
| dhellmann | clarkb : well that's something then. nice :-) | 15:47 |
| fungi | clarkb: dhellmann: git-review could be taught to use the gerrit rest api to perform project lookups, i guess. is that the reason it needs a full remote url now instead of being able to construct one itself like it does for ssh+git://? | 15:47 |
| clarkb | fungi: it is because some sites like software factory host https under a different root than / | 15:47 |
| clarkb | fungi: and so you have to get that additional data into the system somehow | 15:48 |
| fungi | clarkb: dhellmann: oh, right, for specific url overrides i think there is a git option... something like [url "https://review.openstack.org/"] insteadOf = git+ssh://review.openstack.org/ | 15:49 |
| *** mriedem_afk is now known as mriedem | 15:50 | |
| clarkb | zaneb: implementing that would require gerrit to manage a CA and process CSRs right? | 15:50 |
| clarkb | in theory doable I just haven't seen anything that would support that in gerrit | 15:50 |
| zaneb | clarkb: couldn't you just upload a public key in the same way you do for SSH? | 15:51 |
| * zaneb is admittedly not an expert on client certs | 15:51 | |
| clarkb | zaneb: yes, but thta public key has to be signed by a CA that both sides trust iirc | 15:52 |
| clarkb | zaneb: its basically how ssl certs work for https servers but in reverse | 15:52 |
| fungi | not necessarily | 15:52 |
| fungi | you can simply use the cert as a public key | 15:52 |
| clarkb | ah ok | 15:52 |
| fungi | similar to self-signed server certs, just other direction | 15:53 |
| fungi | client applications don't like self-signed server certs because they have an ulterior mission of propping up the certificate authority industry | 15:53 |
| zaneb | right, yeah that's the kind of thing I was imagining | 15:53 |
| clarkb | all of the implementations I've seen involve a CA so that you can invalidate users credentials after the fact | 15:54 |
| clarkb | but that isn't strictly necessary | 15:54 |
| fungi | however, the "right" (for some indistry-accepted definition of that term) solution would indeed be for clients tup send a csr to gerrit which would then send them back a cert signed by an internal ca or proxied along to a separate ca (over the network or in a local hsm) | 15:55 |
| zaneb | fungi: I believe Fedora (the project) does that | 15:55 |
| fungi | it could probably be accomplished with an apache module handling authentication and then getting gerrit to rely on apache envvars for user identification | 15:56 |
| clarkb | really we just need fido2 to end up everywhere and call it a day | 15:56 |
| fungi | rather than expecting gerrit to implement all that inside its jvm | 15:56 |
| zaneb | this answered all of my questions: https://security.stackexchange.com/questions/168799/usage-of-self-signed-certificates-for-client-authentication | 15:59 |
| zaneb | tl;dr it sounds easier to not use a CA, but in the long term it will bite you | 16:00 |
| fungi | right, in the case of the gerrit scenario described, it's not much different than the problems with ssh public key authentication though | 16:08 |
| fungi | effectively all keys are being individually whitelisted | 16:09 |
| fungi | and revocation happens by removing a key from the database | 16:09 |
| *** edmondsw has joined #openstack-tc | 16:09 | |
| fungi | i think the point is that x.509 provides a lot of advantages, and so by using individually whitelisted self-signed client certs you're basically not benefiting from those advantages | 16:10 |
| *** e0ne has quit IRC | 16:13 | |
| *** annabelleB has joined #openstack-tc | 16:15 | |
| *** tosky has quit IRC | 16:29 | |
| *** tosky has joined #openstack-tc | 16:29 | |
| *** jpich has quit IRC | 16:29 | |
| *** cdent has quit IRC | 16:34 | |
| *** edmondsw has quit IRC | 16:43 | |
| *** edmondsw has joined #openstack-tc | 16:44 | |
| *** edmondsw has quit IRC | 16:44 | |
| *** dtantsur is now known as dtantsur|afk | 17:04 | |
| *** annabelleB has quit IRC | 17:10 | |
| *** annabelleB has joined #openstack-tc | 17:30 | |
| fungi | are tc members who interact with wechat installing https://github.com/geeeeeeeeek/electronic-wechat or some questionable proprietary client application? | 17:55 |
| fungi | and if the latter, are you using some sort of isolation to prevent the chinese government from tracking you and backdooring your systems? | 17:56 |
| fungi | just curious what compromises you end up making there | 17:56 |
| fungi | i mean, i won't install webex or google hangouts or zoom clients on my systems for security reasons, and wechat seems similarly challenging in that regard | 17:58 |
| *** edmondsw has joined #openstack-tc | 18:01 | |
| *** edmondsw has quit IRC | 18:06 | |
| smcginnis | fungi: Yes, I uses electronic-wechat while I was using that platform more. | 18:14 |
| smcginnis | Luckily I've been able to get away from it for the most part. | 18:14 |
| smcginnis | fungi: I would not trust it any more than Hangouts or Webex for sure. | 18:14 |
| *** e0ne has joined #openstack-tc | 18:16 | |
| fungi | good to know | 18:20 |
| zaneb | if electronic-wechat is just a wrapper around the web client then couldn't you just use the webclient? I'd have thought a bigger blocker is that you first need to install the app to auth to the web client, which I assume applies to electronic-wechat also | 18:20 |
| fungi | looks like it needs you to use some tool to scan a qr code to authenticate? so maybe depends on having the phone client app installed initially | 18:22 |
| zaneb | source: https://en.wikipedia.org/wiki/WeChat#Platforms | 18:22 |
| fungi | "...it is not possible to get onto the WeChat network if you do not possess a suitable smartphone with the app installed..." | 18:23 |
| fungi | yep | 18:23 |
| fungi | so not something i'll be willing/able to participate in | 18:23 |
| smcginnis | Yeah, it's supplemental to the mobile client. | 18:24 |
| smcginnis | Like 99% of transactions in China, you need to scan a QR code with your phone for it. | 18:24 |
| smcginnis | Login is pretty slick in that regard. Just scan from your phone and verify it's you and you're logged in. | 18:24 |
| smcginnis | But no way to just have a sandboxed client only in that regard. | 18:25 |
| fungi | yeah, but basically requires that you've allowed them to backdoor your (burner?) phone | 18:25 |
| *** annabelleB has quit IRC | 18:25 | |
| smcginnis | Yep | 18:25 |
| fungi | it's unfortunate that people are stuck in a situation where that platform is their only suitable means of communication, and i can sympathize as i'm not really keen on a lot of the choices my government has made with regards to personal freedoms either, but i think the real solution is to each fight our respective governments' choices rather than give in and play by their rules | 18:26 |
| fungi | so i'll fight from here using irc and they can fight from there using wechat, and hopefully one day we can get governments out of the picture and interact on equal footing | 18:27 |
| fungi | but definitely sucks that having ideals means it's harder to work together to get things done in the meantime | 18:28 |
| *** annabelleB has joined #openstack-tc | 18:32 | |
| *** e0ne has quit IRC | 18:32 | |
| *** ricolin has quit IRC | 18:39 | |
| fungi | all because some people none of us have ever met are afraid of each other | 18:42 |
| * TheJulia sighs | 18:43 | |
| *** e0ne has joined #openstack-tc | 18:44 | |
| *** annabelleB has quit IRC | 18:59 | |
| jroll | not sure I understand why we tell users to use specific releases of tempest against a specific version of openstack, but we don't do stable branches for those. what happens when the "pike" version of tempest bitrots? why shouldn't users use master or the latest release against their pike cloud? | 19:32 |
| jroll | maybe I should be asking in that thread, but it's a long divergent chain | 19:32 |
| tosky | jroll: better read it; the current version of tempest always support all supported releases of openstack | 19:36 |
| tosky | so there is no pike branch, only releases from time to time | 19:37 |
| jroll | tosky: right, I read it, I just don't know where to interject that question | 19:37 |
| jroll | it seems odd to me that we say master tempest should work against any version of openstack, but then tell users to use a specific release | 19:38 |
| clarkb | jroll: not any version of openstack just the versions it was tested against | 19:38 |
| clarkb | which is the list of currently supported branches | 19:38 |
| jroll | must work against those, should work against any :) | 19:39 |
| tosky | no, because some tests could have dropped support for the non-supported openstack branches | 19:39 |
| jroll | so the answer is, we tell people to use a specific release for a specific version of openstack, because it will always work? | 19:40 |
| jroll | (until it doesn't, and we don't have a stable branch to fix) | 19:40 |
| fungi | tempest has a sliding support window for openstack apis which covers a range of history | 19:49 |
| *** edmondsw has joined #openstack-tc | 19:50 | |
| fungi | it does deprecate and remove tests over time, and add new ones which may depend on new api features, so they try to tag the repository state to signal when support for old stuff is dropped and new stuff is added | 19:50 |
| fungi | refstack relies on being able to tie specific niteroperability trademark specification versions to specific versions of tempest which have the tests necessary to check them | 19:51 |
| fungi | s/niteroperability/interoperability/ | 19:51 |
| * jroll puts niteroperability in his words to try to use more bucket | 19:52 | |
| fungi | so just saying "always use master" doesn't work for that use case as master may have increasingly picky tests or may no longer check things the old trademark specification required | 19:52 |
| jroll | sure, that all makes sense | 19:53 |
| * jroll needs to re-re-re-read why tempest can't have stable branches | 19:53 | |
| jroll | just seems odd to target releases at a specific version, but refuse to have a stable branch for those | 19:54 |
| smcginnis | jroll: I've found it a futile exercise. | 19:54 |
| jroll | and having a stable branch would make this whole discussion much simpler - every plugin shall cut a stable branch | 19:54 |
| jroll | smcginnis: :) | 19:54 |
| fungi | tempest is mostly written to be a client application. you similarly woudln't want a stable/queens branch of openstackclient | 19:54 |
| fungi | for a lot of the same reasons | 19:54 |
| *** edmondsw has quit IRC | 19:54 | |
| fungi | people would begin to assume you need to use the stable/queens branch of tempest to test clouds deployed with stable/queens and the stable/pike branch of tempest to test clouds deployed with stable/pike. and what if your cloud has a mix of those? which version of tempest do you use in that case? | 19:56 |
| jroll | but we are telling people to use the 17.0.0 release of tempest to test clouds deployed with stable/pike. what's the difference, other than we can't fix bugs in 17.0.0? | 19:57 |
| fungi | the biggest reason is historically we let breaking api changes slip into services because the tempest tests for their respective branches were changed to match the differing api behaviors | 19:57 |
| fungi | so branching the test implementations increases the risk that they no longer test your api remains consistent across release boundaries, or worse, on stable branches after release | 19:59 |
| fungi | when you use a single version of tempest tests to test all changes to your supported branches, you have a greater assurance you'll expose changes in behavior between branches | 20:00 |
| jroll | branching tempest doesn't preclude using master tempest for testing stable branches upstream :) | 20:01 |
| jroll | I'm suggesting we branch for the users, continue using master only for upstream tests | 20:01 |
| fungi | however if you're not going to test the stable branches of tempest, why would you have them and what guarantees would you have that they're any more usable than an old tag of master? | 20:01 |
| jroll | they could be tested | 20:03 |
| jroll | I'm just asking questions, to be clear | 20:03 |
| fungi | i understand | 20:04 |
| fungi | keep in mind that we _were_ branching it for years. the change to non-branching wasn't taken lightly | 20:04 |
| dhellmann | someone needs to write all of this down somewhere in the qa docs so we can stop answering the question :-) | 20:05 |
| dhellmann | not that asking is wrong; it's just hard to remember all the details each time | 20:05 |
| jroll | fungi: was tempest intended for end users when we changed to non-branching? | 20:05 |
| fungi | i believe tempest has always been intended for end users | 20:05 |
| fungi | is openstackclient intended for end users? openstacksdk? | 20:05 |
| jroll | ok | 20:06 |
| dhellmann | having tempest be branchless also makes it easier to ensure that we don't break APIs as we move across stable branch boundaries in service projects, doesn't it? | 20:06 |
| jroll | dhellmann: using the master version of tempest to test all supported branches makes it easier to ensure that we don't break APIs ... | 20:07 |
| jroll | whether it's branchless or not | 20:07 |
| fungi | right, as i mentioned above that was the main driver for changing. we had in the past inadvertently branched what was being tested so that we no longer tested they were consistent | 20:07 |
| dhellmann | sure. and if we branch, then zuul checks out that branch to test changes in that branch in other repos. | 20:07 |
| jroll | yeah, I guess it removes some special-casing | 20:07 |
| dhellmann | it moves it to another place (remembering not to branch) but yeah | 20:08 |
| fungi | there are ways to force zuul to always use master of a required-project even if there are stable branches, though that is additional complexity | 20:08 |
| fungi | and back in zuul v2 time, that complexity was buried in shell scripts in devstack-gate which we managed to screw up more often than we'd have liked | 20:09 |
| fungi | so we could reintroduce stable branches to tempest and then avoid using them, but at that point it would leave me questioning why that's any better than tags | 20:10 |
| jroll | I see it as "to test your pike cloud, install tempest==17.0.0, ironic-tempest-plugin==4.0.0, designate-tests=7.0.0" versus "to test your pike cloud, install the stable/pike release of tempest and any plugins you want" | 20:12 |
| jroll | which now that I write that out, isn't very compelling, I guess. pip doesn't give you ==stable/pike | 20:12 |
| dhellmann | right | 20:13 |
| dhellmann | what you want is a requirements file that lists all of those versions | 20:13 |
| jroll | okay, I guess I get it enough not to have a strong opinion now :) | 20:13 |
| dhellmann | but "any plugins you want" means you can't just include them all | 20:13 |
| jroll | unless the plugin enables/disables the tests based on the service catalog :) | 20:14 |
| jroll | (dunno if any plugins do that, but it would be cool) | 20:14 |
| dhellmann | I'm not sure how that would work with the refstack use case | 20:14 |
| jroll | fair | 20:14 |
| dhellmann | it could be made to, I just don't know what it does now | 20:15 |
| fungi | that was part of the upshot of the discussion about whether tests for services covered by the newer trademark programs needed to remain in tempest or could reside in plugin repos | 20:21 |
| *** e0ne has quit IRC | 20:42 | |
| *** ian_ott has quit IRC | 20:59 | |
| *** edmondsw has joined #openstack-tc | 21:38 | |
| *** edmondsw has quit IRC | 21:43 | |
| *** mriedem has quit IRC | 21:51 | |
| *** ian_ott has joined #openstack-tc | 22:21 | |
| openstackgerrit | Eric Fried proposed openstack/governance master: Fix doc output path in PTI reference https://review.openstack.org/578573 | 22:22 |
| *** hongbin has quit IRC | 22:27 | |
| *** ianychoi has quit IRC | 23:16 | |
| *** ianychoi has joined #openstack-tc | 23:19 | |
| *** edmondsw has joined #openstack-tc | 23:27 | |
| *** edmondsw has quit IRC | 23:32 | |
| *** tosky has quit IRC | 23:35 | |
| *** annabelleB has joined #openstack-tc | 23:36 | |
| zaneb | what is the verdict on meeting before the PTG? Are we definitely going with the 3bis option? | 23:41 |
| *** annabelleB has quit IRC | 23:47 | |
| *** alex_xu has quit IRC | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!