Wednesday, 2018-06-27

*** ricolin has joined #openstack-tc00:49
openstackgerritMichael Johnson proposed openstack/governance master: Octavia asserts supports-accessible-upgrade
fungitc-members: there's an office hour afoot01:00
fungi#startmeeting tc01:00
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.01:00
*** openstack changes topic to " (Meeting topic: tc)"01:00
openstackThe meeting name has been set to 'tc'01:00
fungi#topic Office Hour01:00
zaneboh it's that time01:00
*** openstack changes topic to "Office Hour (Meeting topic: tc)"01:00
* fungi is already a touch sleepy01:01
mnaser#chair zaneb mnaser01:02
mnaseri cant do that can i01:02
fungi#chair zaneb mnaser01:02
openstackCurrent chairs: fungi mnaser zaneb01:02
funginow you could but it would be redundant01:02
zanebno more reviews from our alleged bot came in today01:04
fungii 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 yet01:05
mnaser#chair pabelanger01:08
openstackCurrent chairs: fungi mnaser pabelanger zaneb01:08
zaneb\o it's been real02:00
*** 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"02:01
openstackMeeting ended Wed Jun 27 02:01:08 2018 UTC.  Information about MeetBot at . (v 0.1.4)02:01
openstackMinutes (text):
scasi would have mused more about my small but growing problem, but dinner precluded any sort of deceased equestrian percussion02:15
*** ricolin has quit IRC02:40
*** ricolin has joined #openstack-tc02:41
*** dklyle has quit IRC03:32
*** dklyle has joined #openstack-tc04:11
*** dklyle has quit IRC04:52
*** dklyle has joined #openstack-tc04:57
*** amrith has quit IRC05:15
*** tdasilva has quit IRC05:21
*** tdasilva has joined #openstack-tc05:33
*** e0ne has joined #openstack-tc05:35
*** e0ne has quit IRC05:36
*** amrith has joined #openstack-tc05:47
*** amrith is now known as Guest211005:47
*** ricolin has quit IRC06:20
*** jaosorior has quit IRC07:23
*** tosky has joined #openstack-tc07:40
*** e0ne has joined #openstack-tc07:53
openstackgerritGhanshyam Mann proposed openstack/project-team-guide master: Add FirstContact SIG liaison duty for PTL
*** jpich has joined #openstack-tc08:02
*** dtantsur|afk is now known as dtantsur08:22
*** ricolin has joined #openstack-tc08:43
*** e0ne has quit IRC08:46
ttxdhellmann: 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 active08:48
ttxdeveloper/reviewer abandons.08:48
ttxnotmyname: I picked 66% (2/3) for corporate bus factor and 50% for individual bus factor08:49
ttxIt's part of a discussion on the future of team diversity tags, since they are of questionable usefulness in recent updates08:52
ttxBut 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 abandoned08:54
ttxLike is the 67.4% of SwiftStack commits in Swift really comparable to the 67.9% of NTT in Masakari ?08:56
ttxI think not: Masakari is at a development stage where its health depends more on new commits than Swift.08:57
ttxSo my view now is that we should use such metrics as red flags to raise questions and discuss in more detail in a healthcheck discussion08:59
ttxNot as badges08:59
*** ianychoi has quit IRC09:14
*** ianychoi has joined #openstack-tc09:15
*** cdent has joined #openstack-tc09:17
*** jaosorior has joined #openstack-tc10:18
*** e0ne has joined #openstack-tc10:41
*** e0ne has quit IRC11:29
*** e0ne has joined #openstack-tc11:42
*** dtantsur is now known as dtantsur|brb12:06
*** ttx has quit IRC12:09
*** ttx has joined #openstack-tc12:22
*** mriedem has joined #openstack-tc12:39
*** edmondsw has joined #openstack-tc12:57
*** edmondsw has quit IRC12:57
*** edmondsw has joined #openstack-tc12:57
dhellmannI'm less sure that's a good move.12:59
dhellmannIn the swift case, it's unlikely that SwiftStack is going to lose interest in swift.12:59
dhellmannBut 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
dhellmannor at least it could be13:00
dhellmanncontext does matter, but where the project is in its development lifecycle isn't the only kind of context13:01
cdentI think it's also the case that percentages need to be scaled relative to total reviews/commits13:01
cdent2 out of 3 means something much different from 200 out of 30013:01
dhellmannyes, absolutely13:02
dhellmannor relatively, I guess ;-)13:02
cdentwhich 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
cdentwhich I think is good and reasonable13:03
smcginnisI 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-tc13:08
smcginnisAt 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 arc13:09
* cdent rotflcoptors13:09
smcginniscdent, the eternal optimist. :)13:09
*** e0ne has quit IRC13:26
openstackgerritDoug Hellmann proposed openstack/governance master: write up the python3-first goal
openstackgerritMerged openstack/project-team-guide master: Add FirstContact SIG liaison duty for PTL
ttxdhellmann: 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 investigate13:33
ttxbut I feel like the current tags should be dropped.13:34
*** dtantsur|brb is now known as dtantsur13:35
dhellmanntc-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 the13:35
dhellmann results at!/board/56 and I would appreciate your feedback on the change.13:35
dhellmannttx: 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
dhellmannThe 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
cdentdhellmann: seems reasonable. I need to come up to speed on the board part of storyboard13:36
dhellmanncdent : the stories will change columns on the board automatically depending on progress on the work13:37
dhellmannso that's pretty nice13:37
*** e0ne has joined #openstack-tc13:38
fungias for performance loading a story with lots of tasks, i wonder if that's another case of a missing table index13:38
ttxdhellmann: alternate solution in storyboard is to use task notes to track individual repos13:38
ttxi.e. one task per team, one line in task note per repo13:38
dhellmannfungi : 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 screen13:39
fungiyep, that much i get13:39
dhellmannttx: it's harder to track "done" that way, though, isn't it?13:39
fungilp was similarly problematic when you added 20+ affected projects to a single bug13:39
ttxdhellmann: less granular definitely13:40
dhellmanngiving each team their own story also lets them add their own tasks, if they choose to do so13:40
TheJuliadhellmann: your example seems functional13:40
cdentTheJulia: you don't normally, but that response made you sound like a robot13:40
dhellmannfungi: yeah, I wasn't entirely surprised that storyboard's ability to "scale to more" didn't exactly handle "scale to all" :-)13:40
cdentwhich is great, btw13:40
TheJuliacdent: jet lag, ftw13:41
TheJuliabad... bad... bad jet lag13:41
fungiTheJulia: affirmative, data accepted13:41
dhellmannTheJulia : I look forward to reading your trip report from Beijing when you've recovered enough to write it.13:42
ttxTheJulia: welcome back!13:42
TheJuliadhellmann: I was feeling moderately human on Sunday and submitted something to superuser13:43
dhellmannoh, nice13:43
TheJuliaother 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 night13:48
cdenti've considered using beer as a lubricant for the tc reports, but not worked that out in my mind yet13:53
TheJuliaeveryone is different :)14:00
cdentthank goodness14:02
TheJuliaAlso, everyone has their own self contained context of what community is because it is built upon their perspective and experiences14:06
cdentis that a sequitur or a sort of tangent based on thinking about your posts?14:07
fungiseems relevant to the continuation of the thread from the latest of cdent's tc reports14:08
cdentwell that's kind of why I asked because it seems relevant to a _lot_ of things14:09
TheJuliaIt was more of a continuation of the main thing I gathered visiting beijing14:13
cdentTheJulia: I seem to recall a tweet in that regard14:13
fungisuper-cdent: did you see zuul has a new pipeline manager algorithm named after you?14:15
cdentSadly no, with the advent of hayfever season my ability to consume all the infos has tapered14:16
cdentI reckon I may need to add that to my list of rolling twitter nicks14:17
* cdent reads
cdentah, that makes very good sense14:18
TheJuliacdent: 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 projects14:19
cdenta) 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) shout14:21
cdentboth of these things are extremely difficult to do if you are not a north amercan white male14:21
cdentand/or your employer happens to not want to fund new people going to events14:21
cdentI 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
fungii too am curious what sort of active inclusivity efforts would be culturally acceptable14:29
TheJuliacdent: 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
TheJuliaculturally acceptable in what regard? Adapting our perception of culture? The behaviors of our culture? The culture at large?14:44
*** evrardjp has quit IRC14:45
*** evrardjp has joined #openstack-tc14:45
*** hongbin has joined #openstack-tc14:52
TheJuliaI guess, ultimately I agree, more active in regards to context sharing and enabling.14:56
*** mriedem is now known as mriedem_afk14:57
zanebricolin: any thoughts on ^ ?14:58
scaschef 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, the15:00
scascommunity' operates15:00
*** evrardjp has quit IRC15:02
*** evrardjp has joined #openstack-tc15:03
ricolinI 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
mnaserscas: is it funding? travel support program should be able to support you in the case, unless time is a thing.15:17
scasmnaser: sometimes funding, sometimes unbelievable luck15:17
TheJuliaI 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
ricolinTheJulia, +115:18
mnaserunfortunate we can't bring that up in denver15:18
TheJuliascas: 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
scasmnaser: vancouver was quashed on account of a family death, as an example of my amazing luck15:18
mnaserscas: sorry about that15:18
scasTheJulia: 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 to15:19
TheJuliascas: sorry to hear that :(15:20
TheJuliaYeah, 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
ricolinI only know slack is not to through great wall:)15:22
mnaserexcept it's down today15:22
scasyup. some of my more recent contributors have been behind the great firewall, so there's not a great feedback loop15:22
TheJuliaricolin: not to? not through?15:22
mnaserTheJulia: i think that must have been a really good experience to know what the contributor experience like for apac regions15:23
scaslike the well-meaning five-char patch that i've had to explain is behind dealt with by <insert 12 reviews>15:23
ricolinTheJulia, can't go through:)15:23
TheJuliait is kind of painful right now since our tooling to make it easy doesn't support it out of the box15:23
scasi 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 published15:26
TheJuliaI 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 it15:28
scasi'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 it15:28
TheJuliaSo 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
clarkbTheJulia: fwiw 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
ricolinTheJulia, how about strong the connect with local user group, instead of force you all to learn Chinese?:)15:32
smcginnisricolin: 谢谢15:32
scasit appears i restarted tmux at some point \o/15:32
ricolinsmcginnis, 不客气 lol (you're welcome)15:33
*** edmondsw has quit IRC15:33
dhellmannclarkb : adding it to docs and giving git-review an option to switch to https both seem like they might be helpful15:34
TheJuliaclarkb: I was thinking contributor guide15:34
smcginnisI seem to recall switching to https being added to git-review.15:34
smcginnisUnless I'm mixing it up with something similar, which is entirely possible.15:35
clarkbsmcginnis: dhellmann yes its fully supported as noted in that email15:35
clarkbI personally don't want to go recommending it because it is less secure15:35
dhellmannclarkb : right, I mean something like "git review -s --use-https"15:35
dhellmanninstead of having to add the remote yourself15:35
clarkbdhellmann: it can't be that simple you have to have a full remote url location15:35
scasas 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 language15:36
clarkbdhellmann: you can update the .gitrevie wconfig15:36
clarkbbut that is mostly equivalent to just adding the remote yourself15:36
TheJuliaricolin: 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
clarkband I would be -2 on globally changing .gitreview because those http passwords are less secure than ssh keys because gerrits implementation is poor15:36
dhellmannyeah, there's no reason to make this global15:36
clarkbbasically you cna't infer the https url from the ssh endpoint unfortunately15:37
clarkbso a simple toggle isn't enough15:37
dhellmannit 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 properly15:37
clarkbdhellmann: we can't because http may not be hosted under the same root as ssh repos15:37
clarkbdhellmann: software factory is an example of this iirc15:37
dhellmannit is for us, isn't it?15:37
clarkbit is for us but git review isn't an openstack tool15:38
dhellmannmake the simple things easy...15:38
clarkbor rather not an openstack specific assuming tool. It has many Gerrit users15:38
ricolinTheJulia, 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
clarkbdhellmann: thats fine if you can do so without breaking other users and that toggle will simply break for software factory for example15:38
dhellmannyeah, like I said, combine it with ~/.user-config-for-git-review or whatever15:38
ricolinWhen 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
TheJuliaricolin: lol15:40
clarkbI do want to say you can already provide a user specific override for .gitreview remotes, fungi may know15:40
clarkbbut setting that may be the easiest thing then its edit ~/.gitconfig && git review -s or something15:40
fungioh, wow, more scrollback15:40
TheJuliaclarkb: ++15:40
dhellmannTheJulia : 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
dhellmannI'm not sure how I feel about signing up for another service as a way to deal with that.15:41
dhellmannWhere does that approach end?15:42
dhellmannOTOH, if IRC doesn't work...15:42
TheJuliaWechat does have some limitations, like a maximum of 500 users in a groupchat15:42
TheJuliaand that groupchat is invite-only15:42
clarkbit also has massive security concerns15:42
fungiTheJulia: 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 least15:42
ricolins/make she/make her/:)15:42
TheJuliafungi: 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
zanebclarkb: 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 it15:46
clarkbdhellmann: 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
clarkbzaneb: I don't think gerrit supports client cert auth15:47
dhellmannclarkb : well that's something then. nice :-)15:47
fungiclarkb: 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
clarkbfungi: it is because some sites like software factory host https under a different root than /15:47
clarkbfungi: and so you have to get that additional data into the system somehow15:48
fungiclarkb: dhellmann: oh, right, for specific url overrides i think there is a git option... something like [url ""] insteadOf = git+ssh://
*** mriedem_afk is now known as mriedem15:50
clarkbzaneb: implementing that would require gerrit to manage a CA and process CSRs right?15:50
clarkbin theory doable I just haven't seen anything that would support that in gerrit15:50
zanebclarkb: 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 certs15:51
clarkbzaneb: yes, but thta public key has to be signed by a CA that both sides trust iirc15:52
clarkbzaneb: its basically how ssl certs work for https servers but in reverse15:52
funginot necessarily15:52
fungiyou can simply use the cert as a public key15:52
clarkbah ok15:52
fungisimilar to self-signed server certs, just other direction15:53
fungiclient applications don't like self-signed server certs because they have an ulterior mission of propping up the certificate authority industry15:53
zanebright, yeah that's the kind of thing I was imagining15:53
clarkball of the implementations I've seen involve a CA so that you can invalidate users credentials after the fact15:54
clarkbbut that isn't strictly necessary15:54
fungihowever, 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
zanebfungi: I believe Fedora (the project) does that15:55
fungiit could probably be accomplished with an apache module handling authentication and then getting gerrit to rely on apache envvars for user identification15:56
clarkbreally we just need fido2 to end up everywhere and call it a day15:56
fungirather than expecting gerrit to implement all that inside its jvm15:56
zanebthis answered all of my questions:
zanebtl;dr it sounds easier to not use a CA, but in the long term it will bite you16:00
fungiright, in the case of the gerrit scenario described, it's not much different than the problems with ssh public key authentication though16:08
fungieffectively all keys are being individually whitelisted16:09
fungiand revocation happens by removing a key from the database16:09
*** edmondsw has joined #openstack-tc16:09
fungii 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 advantages16:10
*** e0ne has quit IRC16:13
*** annabelleB has joined #openstack-tc16:15
*** tosky has quit IRC16:29
*** tosky has joined #openstack-tc16:29
*** jpich has quit IRC16:29
*** cdent has quit IRC16:34
*** edmondsw has quit IRC16:43
*** edmondsw has joined #openstack-tc16:44
*** edmondsw has quit IRC16:44
*** dtantsur is now known as dtantsur|afk17:04
*** annabelleB has quit IRC17:10
*** annabelleB has joined #openstack-tc17:30
fungiare tc members who interact with wechat installing or some questionable proprietary client application?17:55
fungiand if the latter, are you using some sort of isolation to prevent the chinese government from tracking you and backdooring your systems?17:56
fungijust curious what compromises you end up making there17:56
fungii 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 regard17:58
*** edmondsw has joined #openstack-tc18:01
*** edmondsw has quit IRC18:06
smcginnisfungi: Yes, I uses electronic-wechat while I was using that platform more.18:14
smcginnisLuckily I've been able to get away from it for the most part.18:14
smcginnisfungi: I would not trust it any more than Hangouts or Webex for sure.18:14
*** e0ne has joined #openstack-tc18:16
fungigood to know18:20
zanebif 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 also18:20
fungilooks 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 initially18:22
fungi" is not possible to get onto the WeChat network if you do not possess a suitable smartphone with the app installed..."18:23
fungiso not something i'll be willing/able to participate in18:23
smcginnisYeah, it's supplemental to the mobile client.18:24
smcginnisLike 99% of transactions in China, you need to scan a QR code with your phone for it.18:24
smcginnisLogin is pretty slick in that regard. Just scan from your phone and verify it's you and you're logged in.18:24
smcginnisBut no way to just have a sandboxed client only in that regard.18:25
fungiyeah, but basically requires that you've allowed them to backdoor your (burner?) phone18:25
*** annabelleB has quit IRC18:25
fungiit'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 rules18:26
fungiso 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 footing18:27
fungibut definitely sucks that having ideals means it's harder to work together to get things done in the meantime18:28
*** annabelleB has joined #openstack-tc18:32
*** e0ne has quit IRC18:32
*** ricolin has quit IRC18:39
fungiall because some people none of us have ever met are afraid of each other18:42
* TheJulia sighs18:43
*** e0ne has joined #openstack-tc18:44
*** annabelleB has quit IRC18:59
jrollnot 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
jrollmaybe I should be asking in that thread, but it's a long divergent chain19:32
toskyjroll: better read it; the current version of tempest always support all supported releases of openstack19:36
toskyso there is no pike branch, only releases from time to time19:37
jrolltosky: right, I read it, I just don't know where to interject that question19:37
jrollit seems odd to me that we say master tempest should work against any version of openstack, but then tell users to use a specific release19:38
clarkbjroll: not any version of openstack just the versions it was tested against19:38
clarkbwhich is the list of currently supported branches19:38
jrollmust work against those, should work against any :)19:39
toskyno, because some tests could have dropped support for the non-supported openstack branches19:39
jrollso 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
fungitempest has a sliding support window for openstack apis which covers a range of history19:49
*** edmondsw has joined #openstack-tc19:50
fungiit 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 added19:50
fungirefstack relies on being able to tie specific niteroperability trademark specification versions to specific versions of tempest which have the tests necessary to check them19:51
* jroll puts niteroperability in his words to try to use more bucket19:52
fungiso 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 required19:52
jrollsure, that all makes sense19:53
* jroll needs to re-re-re-read why tempest can't have stable branches19:53
jrolljust seems odd to target releases at a specific version, but refuse to have a stable branch for those19:54
smcginnisjroll: I've found it a futile exercise.19:54
jrolland having a stable branch would make this whole discussion much simpler - every plugin shall cut a stable branch19:54
jrollsmcginnis: :)19:54
fungitempest is mostly written to be a client application. you similarly woudln't want a stable/queens branch of openstackclient19:54
fungifor a lot of the same reasons19:54
*** edmondsw has quit IRC19:54
fungipeople 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
jrollbut 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
fungithe 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 behaviors19:57
fungiso 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 release19:59
fungiwhen 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 branches20:00
jrollbranching tempest doesn't preclude using master tempest for testing stable branches upstream :)20:01
jrollI'm suggesting we branch for the users, continue using master only for upstream tests20:01
fungihowever 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
jrollthey could be tested20:03
jrollI'm just asking questions, to be clear20:03
fungii understand20:04
fungikeep in mind that we _were_ branching it for years. the change to non-branching wasn't taken lightly20:04
dhellmannsomeone needs to write all of this down somewhere in the qa docs so we can stop answering the question :-)20:05
dhellmannnot that asking is wrong; it's just hard to remember all the details each time20:05
jrollfungi: was tempest intended for end users when we changed to non-branching?20:05
fungii believe tempest has always been intended for end users20:05
fungiis openstackclient intended for end users? openstacksdk?20:05
dhellmannhaving 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
jrolldhellmann: using the master version of tempest to test all supported branches makes it easier to ensure that we don't break APIs ...20:07
jrollwhether it's branchless or not20:07
fungiright, 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 consistent20:07
dhellmannsure. and if we branch, then zuul checks out that branch to test changes in that branch in other repos.20:07
jrollyeah, I guess it removes some special-casing20:07
dhellmannit moves it to another place (remembering not to branch) but yeah20:08
fungithere are ways to force zuul to always use master of a required-project even if there are stable branches, though that is additional complexity20:08
fungiand 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 liked20:09
fungiso 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 tags20:10
jrollI 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
jrollwhich now that I write that out, isn't very compelling, I guess. pip doesn't give you ==stable/pike20:12
dhellmannwhat you want is a requirements file that lists all of those versions20:13
jrollokay, I guess I get it enough not to have a strong opinion now :)20:13
dhellmannbut "any plugins you want" means you can't just include them all20:13
jrollunless 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
dhellmannI'm not sure how that would work with the refstack use case20:14
dhellmannit could be made to, I just don't know what it does now20:15
fungithat 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 repos20:21
*** e0ne has quit IRC20:42
*** ian_ott has quit IRC20:59
*** edmondsw has joined #openstack-tc21:38
*** edmondsw has quit IRC21:43
*** mriedem has quit IRC21:51
*** ian_ott has joined #openstack-tc22:21
openstackgerritEric Fried proposed openstack/governance master: Fix doc output path in PTI reference
*** hongbin has quit IRC22:27
*** ianychoi has quit IRC23:16
*** ianychoi has joined #openstack-tc23:19
*** edmondsw has joined #openstack-tc23:27
*** edmondsw has quit IRC23:32
*** tosky has quit IRC23:35
*** annabelleB has joined #openstack-tc23:36
zanebwhat is the verdict on meeting before the PTG? Are we definitely going with the 3bis option?23:41
*** annabelleB has quit IRC23:47
*** alex_xu has quit IRC23:59

Generated by 2.15.3 by Marius Gedminas - find it at!