| dmsimard | smcginnis: yeah the two first PTG days are kinda awesome | 00:24 |
|---|---|---|
| dmsimard | +1 | 00:24 |
| *** david-lyle has joined #openstack-tc | 01:10 | |
| *** lbragstad has quit IRC | 01:27 | |
| fungi | it's been office hours for the last 45 minutes and i'm the first to break radio silence. not a busy one i guess! | 01:44 |
| pabelanger | never seems to be | 01:46 |
| *** david-lyle has quit IRC | 01:47 | |
| *** mriedem_afk has quit IRC | 02:03 | |
| *** harlowja has quit IRC | 02:13 | |
| smcginnis | feedback from the ops meetup - some are interested in attending the PTG, but with the way it is defined now it does not sound like they should be there. | 05:07 |
| smcginnis | If we reworded the first couple days at least it would be slightly more encouraging. | 05:07 |
| smcginnis | They have the same issue with the forum/summit as we had with the design summit. They want to be part of design discussions, but they get constant interuptions for presenting talks, customer (or vendor) meetings, etc. | 05:08 |
| smcginnis | I was originally pushing back when they were proposing the desire to colocate the ops meetup with the PTG, but starting to change my mind. | 05:09 |
| smcginnis | We could have a couple overlapping days, then two separate tracks the rest of the week. | 05:10 |
| smcginnis | It would allow for some cross polination, and it could benefit our sponsorship/funding situation. | 05:10 |
| smcginnis | I would rather have some of the challenges that brings than merging the PTG back into the Summit. | 05:11 |
| *** ykarel has joined #openstack-tc | 05:49 | |
| *** david-lyle has joined #openstack-tc | 05:59 | |
| *** ykarel has quit IRC | 06:20 | |
| *** kfox1111 has quit IRC | 06:47 | |
| *** ykarel has joined #openstack-tc | 07:05 | |
| *** ykarel has quit IRC | 07:11 | |
| *** ykarel has joined #openstack-tc | 07:37 | |
| ttx | If we keep separate events, I'd prefer to keep the inward/outward split. BUT that does not prevent the ops meetup from being held at PTG (especially the workgroup gathering part of it) | 08:20 |
| ttx | which would result in ops being potentially available for other team discussions (like anyone else) | 08:20 |
| ttx | But I feel like the whole discussion is old-thinking, devs vs. ops, us vs, them. If you're a contributor (in a large sense) and work in an openstack team (in a large sense) then your team can gather at the PTG. Some teams have a dev focus, (nova) some an ops focus (publiccloudwg), some a mix (upgrades SIG), and it's all fine | 08:23 |
| ttx | It's the context switch between inward & outward that is imho costly. | 08:24 |
| *** cdent has joined #openstack-tc | 09:34 | |
| *** dtantsur|afk is now known as dtantsur | 09:45 | |
| *** cdent has quit IRC | 10:32 | |
| *** cdent has joined #openstack-tc | 10:56 | |
| persia | ttx: Excellent language. Yes: explicity having the previously described "ops sessions" at PTG makes sense to me. | 11:19 |
| *** diablo_rojo has quit IRC | 11:57 | |
| *** ykarel_ has joined #openstack-tc | 12:18 | |
| *** ykarel has quit IRC | 12:18 | |
| *** ykarel_ has quit IRC | 12:18 | |
| *** ykarel_ has joined #openstack-tc | 12:18 | |
| *** lbragstad has joined #openstack-tc | 12:39 | |
| dmsimard | smcginnis: that's odd, it sounds like the first couple days of the PTG would be the most appropriate to have ops around with the cross-project discussions ? | 13:16 |
| dmsimard | it doesn't mean that the scope of these first couple days can't be revisited but if there's any day of the week that is adequate it's the first two IMO | 13:17 |
| *** lbragstad has quit IRC | 14:15 | |
| *** diablo_rojo has joined #openstack-tc | 14:19 | |
| TheJulia | +1 to "ops oriented sessions". One thing that resonated with me last week was that the SIG discussions I was part of seemed to involve some mutual context setting, and an understanding that we're here to work together. That may be a side effect of the PTG, but I think it would be good to try and cultivate that with operators since we're all part of the same community. | 14:20 |
| *** lbragstad has joined #openstack-tc | 14:21 | |
| cmurphy | ++ | 14:22 |
| persia | I found having operators available on *Thursday* last week was incredibly helpful, as introducing operators to teams that were trying to figure out which approach to take for something tended to resolve the conversation quickly. | 14:27 |
| persia | I think the general messaging is that all folk involved in a technical capacity should be around as long as possible. | 14:27 |
| cmurphy | having ops in the keystone room both wednesday and thursday was really useful for us | 14:29 |
| TheJulia | That was one thing we have started doing in ironic, Intentionally letting the operator's needs guide the discussion. It helped remove a lot of barriers that are really just a lack of context | 14:31 |
| cmurphy | ++ | 14:31 |
| TheJulia | persia: ++, I'm happy to spend a couple more days someplace if we're able to build better consensus and leave with people feeling even more productive | 14:32 |
| persia | I don't think it needs much more time: maybe 6 days (three/three instead of two/three) at most. Key is just inviting the right folk. | 14:33 |
| persia | (well, and making sure they feel welcome, etc.) | 14:34 |
| TheJulia | Exactly | 14:37 |
| *** mriedem has joined #openstack-tc | 14:45 | |
| *** pabelanger has quit IRC | 15:04 | |
| *** kumarmn has joined #openstack-tc | 15:04 | |
| *** cdent has quit IRC | 15:05 | |
| openstackgerrit | Lance Bragstad proposed openstack/governance master: Create a new project called oslo.limit https://review.openstack.org/550496 | 15:14 |
| *** pabelanger has joined #openstack-tc | 15:17 | |
| *** hongbin has joined #openstack-tc | 15:40 | |
| fungi | hrm... so horizon decided during the ptg to default to using eventlet (leaving their existing python thread implementation as a configurable alternative for now)? | 15:51 |
| mugsie | does horizon not use mod_wsgi? | 15:53 |
| fungi | would we do well to write up a summary of past/continuing challenges with eventlet in other services and stuff that into a resolution or something? not sure if we have a better place to document (anti-)recommendations like that | 15:53 |
| fungi | http://lists.openstack.org/pipermail/openstack-dev/2018-March/127977.html | 15:54 |
| *** david-lyle has quit IRC | 15:54 | |
| fungi | "we agreed to make go forward with Eventlet by default and make it configurable to allow native Python threads which are used now" | 15:54 |
| fungi | it's possible i'm misreading the bullet point there | 15:55 |
| fungi | or taking it out of context | 15:56 |
| mugsie | I read it the same way | 15:56 |
| mugsie | they don't currently require eventlet or oslo.service so hopefully we can avoid it :) | 15:57 |
| *** cdent has joined #openstack-tc | 16:00 | |
| dhellmann | why did I think horizon was being rewritten in javascript? | 16:36 |
| *** ykarel_ has quit IRC | 16:38 | |
| dtroyer | dhellmann: because part of it is? I doubt the service ever goes away completely though. They talked about the priority of the AngularJS rewrites last week, it isn't at the top of the list | 16:38 |
| cmurphy | that will make it hard for vertical projects to contribute feature support to it :/ | 16:39 |
| mugsie | it does. trying to find what causes any errors is a pain, and I have no idea how to add anything to ours | 16:43 |
| ttx | Data: 402 attendees at PTG. 94% of registered people showed up, which is pretty good | 16:50 |
| dtroyer | more data: ~9 snowmen, 1 snow angel | 16:53 |
| dtroyer | (unofficial of course) | 16:53 |
| pabelanger | I think the stadium made it feel like a much smaller number, but when we moved into the hotel, there was a lot of people | 16:53 |
| cdent | are the kata people aware that the slack is shutting down irc gateways? | 16:55 |
| cdent | only 1 snow angel!!?? I am so alone | 16:55 |
| dtroyer | cdent: maybe that's what goes on the commemorative sticker | 16:56 |
| cmurphy | slack is getting rid of irc gateways? | 16:58 |
| cdent | cmurphy: https://twitter.com/genehack/status/971404236490620928 | 16:59 |
| cdent | i tried to get to the referenced page (from here https://get.slack.help/hc/en-us/articles/201727913-Connect-to-Slack-over-IRC-and-XMPP ) but it needs auth and I couldn't be bothered | 16:59 |
| cmurphy | X( | 16:59 |
| cdent | quite | 17:00 |
| pabelanger | ouch | 17:05 |
| mugsie | from what I understand the XMPP / IRC gateway was problematic for them, and relied on a single maintainer internally | 17:16 |
| *** david-lyle has joined #openstack-tc | 17:16 | |
| openstackgerrit | Ruby Loo proposed openstack/governance master: Remove ironic-inspector-tempest-plugin https://review.openstack.org/550538 | 17:16 |
| ttx | mugsie: yes I'm pretty sure it jhas nothing to do with ensuring a uniform user experience | 17:18 |
| mugsie | Well, I am sure that is part of it :) but I say the pain / cost has now passed the reward point | 17:19 |
| *** david-lyle has quit IRC | 17:33 | |
| *** ykarel_ has joined #openstack-tc | 17:58 | |
| *** ykarel_ has quit IRC | 18:18 | |
| *** david-lyle has joined #openstack-tc | 18:21 | |
| *** david-lyle has quit IRC | 18:35 | |
| *** dtantsur is now known as dtantsur|afk | 18:48 | |
| *** david-lyle has joined #openstack-tc | 19:03 | |
| openstackgerrit | Chris Dent proposed openstack/governance master: Clarify testing for interop programs https://review.openstack.org/550571 | 19:07 |
| cdent | zaneb, jroll, dhellmann, mugsie, others: that's effort to distill the interop thing to something simpler | 19:08 |
| dhellmann | cdent : "whereas" | 19:11 |
| cdent | i had to do it | 19:11 |
| cdent | I couldn't help myself | 19:11 |
| dhellmann | I think we said that was grounds for dismissal, but that might have only applied to mordred | 19:12 |
| dhellmann | :-) | 19:12 |
| dhellmann | cdent : I think it could be simpler by just saying it is up to the interop working group to set guidelines for and select tests for use in the trademark program, and not talk about any technical details at all | 19:13 |
| * cdent is secretly begging to be dismisded | 19:13 | |
| dhellmann | aw | 19:13 |
| cdent | dhellmann: I don't think that form will satisfy some of the concerns presented by all the people | 19:14 |
| cdent | the structure helps to insure that changes people want to make are possible and are not going to be resisted again | 19:14 |
| cdent | and again | 19:14 |
| dhellmann | because I think at this point the choice is *not* up to project teams. The QA team has mostly resisted adding more tests, which means they *must* go somewhere other than tempest. | 19:14 |
| cdent | and again | 19:14 |
| cdent | thus the "in consultation" | 19:14 |
| cdent | and that was mostly being polite | 19:14 |
| cdent | my assumption is that any relatively new project will always choose to go the plugin route, except for designate | 19:15 |
| mugsie | cdent: at this point, I feel like the only people who will object to dhellmann's suggestion is me, and maybe dhellmann. until the first time a trademark program gets broken, at which point it will be the project teams fault | 19:15 |
| dhellmann | the issue I have with including all of the detail is that if some technical thing changes in the future then we have to have the discussion over again | 19:15 |
| cdent | mugsie: yeah, good point | 19:15 |
| cdent | dhellmann: I tried to leave out a great deal of detail while keeping the bits that say "you have options, but they are constrained" | 19:16 |
| dhellmann | do we need to spell out the constraints? | 19:16 |
| mugsie | honestly, if the QA team do not have the bandwidth for more programs, we should move all tests out of QA and ask the InterOP WG to maintain them | 19:16 |
| mugsie | all *trademark tests* | 19:16 |
| dhellmann | if someone decides that what they really want to do is post tests to pastebins because then they're immutable, and tempest supports reading tests from there, they wouldn't be allowed without a tc vote. Since it's the interop team who cares most about the location of the tests (or should), I say let them document what they support. | 19:17 |
| cdent | dhellmann: I think we do, because the constraints could provide safety against future arguments | 19:17 |
| dhellmann | the current constraints did not provide that protection | 19:17 |
| cdent | because they are out of date | 19:18 |
| cdent | we changed things, lots of things | 19:18 |
| cdent | and that's okay | 19:18 |
| dhellmann | that is one interpretation | 19:18 |
| cdent | we _want_ change | 19:18 |
| cdent | and we're here to help facillitate it, in part by revising resolutions | 19:18 |
| dhellmann | I have no problem with changing this policy. I just don't like the end-run method being used to do it. | 19:18 |
| cdent | the rules are for changing | 19:18 |
| dhellmann | and the lack of ownership on the part of the people in the interop wg | 19:19 |
| cdent | and end-runs will always happen because people need change faster than we are willing to provide it | 19:19 |
| dhellmann | that's a disappointing viewpoint | 19:19 |
| dhellmann | I mean, I don't feel like we were even asked | 19:19 |
| dhellmann | which is even more bleak | 19:19 |
| mugsie | cdent: putting fingers in ears and not listening when someone says "this is not right" for a year works pretty well as well. | 19:19 |
| dhellmann | I think your proposal is probably a step in the right direction, but we could go further and just have the interop wg deal with this stuff directly | 19:20 |
| cdent | dhellmann: we've been talking for more than a year that I recall about how to manage tempest tests, including but not limited to trademark tests, and we've failed to improve the situation | 19:20 |
| cdent | of course people will just do something else when that happens | 19:20 |
| dhellmann | a lot of those conversations were not about interop tests, though, they were about regular functional and integration tests | 19:21 |
| cdent | dhellmann: I think some aspect of the charter, bylaws, existing resolutions works against "just having the interop wg dealing with it" as we (the tc) are supposed to signify something (that I can't exactly remember right now) | 19:21 |
| mugsie | cdent: we havent *really* discussed interop, just tempest itself | 19:21 |
| mugsie | just the list of projects that they need to consider | 19:21 |
| cdent | mugsie: interop has been under our baleful eye for at least several months hasn't it? | 19:21 |
| dhellmann | cdent : we are responsible for listing "designated sections" of the code to be included, and we do that by giving projects the tc-approved-release tag | 19:21 |
| cdent | I've certainly had conversations about it since before last july | 19:22 |
| mugsie | the review has been there since november | 19:22 |
| mugsie | I have been talking about since Austin I think? | 19:22 |
| mugsie | what was between Austin and Boston? | 19:22 |
| dhellmann | I see very little point in us establishing detailed policies that people are going to just ignore. So I would prefer us to only specify the amount of detail necessary to make clear how someone should make a decision on what to do about interop tests. Since the answer is "ask the interop wg" we should just say that clearly. | 19:23 |
| mugsie | but each time I brought it up the QA team went "out of scope for tempest", the InterOP WG went "we don't care, just give us test IDs" | 19:23 |
| mugsie | pushing tests in generic project repos *will* blow up in our faces, but if interop are ok with it, so be it | 19:25 |
| cdent | dhellmann: our job as the tc is to resolve that QA/WG that mugsie is describing. We can do that by, in effect, legislating that people can produce tests (mostly) as they like. The "mostly" provides a degree of security such that it's not overly chaotic. | 19:25 |
| cdent | I'm, personally, just fine with tests coming form anywhere (including pastebin if people want that), but I don't think that's good for people who want to not guess on the preferred ways to do things | 19:25 |
| cdent | By providing some preferred ways, we give a kind of technical leadership that we ought to be doing. | 19:26 |
| *** harlowja has joined #openstack-tc | 19:26 | |
| dhellmann | I'm starting to dislike the way the whole interop thing is set up. I'm not sure it should ever have been tied to the QA program. That was a convenience, when that team was bigger and more interested in it than they are now. | 19:26 |
| mugsie | cdent: the replies on the ML seem to indicate that QA do not want to do reviews on <project>-trademark-plugin repos | 19:26 |
| dhellmann | It feels a bit like what happened with the docs team, really. | 19:26 |
| mugsie | dhellmann: ++ | 19:26 |
| cdent | mugsie: that's fine, they don't _have_ to | 19:26 |
| cdent | but they will be able to | 19:26 |
| cdent | that's the crucial difference | 19:26 |
| dhellmann | And I think saying "this group over here cares about it, they need to decide and document it" is exactly what we've done for successful resolutions of these sorts of concerns in the past | 19:26 |
| mugsie | but the docs team innovated and pushed everything out to projects and started maintaining just tools | 19:26 |
| dhellmann | cdent : if they won't, and we make it look like they're going to, then we're not accurately reflecting the level of review and maintenance on those tests | 19:27 |
| dhellmann | if we want to have interop tests, and we want project teams to own them, then we need to train all of those teams on the interop rules | 19:28 |
| dhellmann | and we need to keep training them in the face of turnover | 19:28 |
| cdent | I think we are overstating the amount of review these tests need. Lots at the start, and then not. | 19:28 |
| mugsie | cdent: its not the tests, it is underlying tooling that will be the issue | 19:29 |
| dhellmann | you'd think. except that an innocuous change in a tempest test *not related to the API* broke interop testing and almost led to the interop group forking tempest itself. | 19:29 |
| cdent | dhellmann: well you know what my answer to that is, thus why I'm not particularly safe in this discussion: just use gabbi, then it is only http | 19:30 |
| mugsie | e.g. interop currently supports mitaka. so if a project say bumps the min microversion to ocatas, tempest will run just fine in CI, but the trademark program validation will break | 19:30 |
| dhellmann | which is another approach to solving the problem, but one I think project teams are going to like even less than having to keep up with stricter review rules | 19:30 |
| mugsie | and unless we train people to watch for that (or even care) we will break tests | 19:30 |
| dhellmann | cdent : if the behaviors being tested were limited to APIs, that would work. | 19:30 |
| cdent | if the trademark programs are testing something other than apis, how do they work on random clouds? | 19:31 |
| dhellmann | those clouds have to act like an openstack cloud does when you do things like boot an instance and then try to login to it | 19:31 |
| dhellmann | part of the purpose of the tests is to show that the cloud acts like openstack, and that's more than the API inputs and outputs | 19:32 |
| mugsie | better example - designate's tests actually validate that zones and records created are accessable. we have a wait timeout set for that, which if we reduce may cause $SLOW_CLOUD to start failing | 19:32 |
| dhellmann | that's an interesting one | 19:32 |
| dhellmann | there's a "gentleman's agreement" that folks use the openstack source code; deeper tests is a way of enforcing that | 19:33 |
| dhellmann | cdent : https://governance.openstack.org/tc/resolutions/20151211-bring-your-own-kernel.html | 19:33 |
| * mugsie remember's that fight | 19:34 | |
| * dhellmann hears the washing machine finish | 19:34 | |
| cdent | I'm not sure I got the full thrust of dhellmann's link, unless it is only as an emphasis on "we need to be able to see inside the guest" | 19:35 |
| cdent | mugsie: can you expand on your comment about reducing the timeout. Is that with regard to unsafe changes in tests needing competent review, or in regard to using other tools? | 19:38 |
| mugsie | unsafe changes in tests needing competent review (or even knowledge that this review could impact an old cloud that we will never see in CI) | 19:38 |
| openstackgerrit | Chris Dent proposed openstack/governance master: Clarify testing for interop programs https://review.openstack.org/550571 | 19:44 |
| cdent | mugsie: if a test was accepted, and live in a designated (hah) interop plugin for designate, would there ever be a resason to change the wait timeout in the test? | 19:45 |
| cdent | As in, once accepted, why would would it change? | 19:45 |
| mugsie | because it is a global timeout for all DNS operations, and is defined on a global level | 19:46 |
| cdent | oh you mean a timeout used by the service is being use to control a timeout in tests? | 19:46 |
| mugsie | https://github.com/openstack/designate-tempest-plugin/blob/master/designate_tempest_plugin/config.py#L40-L42 | 19:47 |
| dhellmann | cdent : yeah, that document I linked was the outcome of the attempt by oracle to say that our tests were not fair because they didn't work on the fork of openstack that they have | 19:48 |
| dhellmann | which came about because one of the tests changed and stopped working | 19:48 |
| dhellmann | unless I'm conflating 2 different events | 19:48 |
| mugsie | dhellmann: thats what I remember | 19:51 |
| mugsie | whatever the command that tempest ran inside the nova instance only worked on linux | 19:51 |
| cdent | was that command run from the shell somehow, or was it started via the api? | 19:54 |
| mordred | dhellmann: there were grounds for dismissal I could have gotten applied to myself? now you tell me! | 19:57 |
| cdent | rough isn't it? | 19:58 |
| fungi | one of the challenges that's not really getting touched on (or keeps getting elided/forgotten) is that tempest aims to have a core standard library of tests and the interop effort relies on quite a few of those. under that design, breaking those out of and so decomposing the tempest repo does seem counterproductive (though perhaps the copying/forking suggestion has merit in that regard) | 19:59 |
| dhellmann | cdent : the VM was launched and the test used ssh to login and run a command. I honestly don't remember what it was. Maybe some sort of networking command that is different on Linux vs. Solaris? ISTR it trying to determine that the VM had the expected IP? | 20:00 |
| mugsie | cdent: https://github.com/openstack/tempest/blob/d5f49e2f76a9ca3b1f117c1a9eb349e9976ac222/tempest/api/compute/servers/test_create_server.py#L106-L139 | 20:00 |
| mugsie | I think it was one of those 2 | 20:00 |
| cdent | thanks mugsie, so a full on ssh into the shell | 20:01 |
| mugsie | aye | 20:01 |
| fungi | as for why interop testing is tied to tempest, it's primarily due to the lack of people working on interop. tempest provided a useful set of ready-made feature tests and the interop effort needed something like that but lacked the people to write their own from scratch | 20:01 |
| cdent | fungi: I don't think anyone has a problem with it being tied to tempest as the runner | 20:01 |
| mugsie | fungi: yep, but I think that we should be pushing back on the board - they want this program, they need to fund it, not tack it on | 20:02 |
| dhellmann | some people did, but they aren't here any more | 20:02 |
| mugsie | but that may be a Vancouver TC/Board meeting item | 20:02 |
| fungi | early on in interop infancy i and others pushed them to coordinate with the qa team and work together rather than reinvent wheels we mostly already had. it's possible that model has outlived its usefulness though | 20:03 |
| dhellmann | possibly | 20:03 |
| persia | Or maybe "work with the QA team" isn't strong enough, and "join the QA team" is necessary. | 20:04 |
| mugsie | persia: no, they are separate concerns. they should be separate groups. one group just uses a tool the other produces | 20:05 |
| cdent | I think we need to recognize that any solution we present for this that makes success depend on the existence of more people is not going to result in success | 20:05 |
| * mugsie is looking at gabbi, thinks this would have been a much better base for easy to read / review API testing | 20:05 | |
| * cdent sends mugsie a cheque | 20:06 | |
| persia | mugsie: I am violently agaisnt divisive identities. As soon as we say things like "this person is on this team so can't be on that team", we end up wtih not enough people on teams. | 20:06 |
| mugsie | persia: sure, but 12 people joining the QA team to work on interop stuff still means there is only 4-5 people on non interop QA work | 20:06 |
| persia | If the QA team is responsible for something, and the InterOp team wants it done, and the QA team doesn't have enough folk, asking InterOp folk to join QA to solve the staffing problem seems simple enough. If we can't do that because we want to say "these are separate groups", there should be a good reason we need them to argue to keep them separate. | 20:07 |
| *** david-lyle has quit IRC | 20:07 | |
| mugsie | the skill sets (of both groups) do not suit the others role in the orgainisation | 20:08 |
| persia | Using the InterOp team's need to work with the QA team as a lever to get non-InterOp stuff funded seems disingenious to me. | 20:08 |
| dtroyer | In the end this is basically a "we don't have enough people" problem, be that on the QA team or on the interop team. And we seem to have difficulty solving this class of problem across the board | 20:08 |
| dhellmann | I don't think designating a task as the responsibility of a team excludes anyone from joining that team to work on that task. | 20:08 |
| dtroyer | shuffling code among repos isn't going to fix the root | 20:08 |
| persia | dhellmann: ++ | 20:08 |
| dhellmann | we do, but at this point the problem isn't fully clear because the task is assigned to the "wrong" team | 20:09 |
| mugsie | no, I am saying that InterOp work should be funded using this lever, and the QA team should be funded, well, for obvious reasons | 20:09 |
| persia | dtroyer: Helping folk who want things understand that doing things is the way to get them done does help the problem. | 20:09 |
| dhellmann | we may have plenty of people to work on tempest itself if they aren't also tasked with the interop test reviews | 20:09 |
| dtroyer | dhellmann: true, but there is still that bundle of work (interop tests) un-resourced, no matter what team it gets thrown toward | 20:10 |
| persia | Has anyone done cui bono analysis for why InterOp matters? Is the beneficiary aware of the problem and prepared to help? | 20:11 |
| dtroyer | the conditions that were true when we pushed interop to leverage Tempest have most certainly changes, as fungi noted a bit ago, and there are divergent assumptions on the use of that code | 20:11 |
| mugsie | persia: InterOp WG or general "I have an OpenStack cloud, and I want to test on my friends OpenStack cloud, they should work basically the same" interop ? | 20:12 |
| dhellmann | dtroyer: of course. it doesn't eliminate the issue, it clarifies it. | 20:12 |
| dtroyer | persia: the amount of code in Shade could be seen as one measure of why interop is importnat. | 20:12 |
| dtroyer | it is harder to cound how many projects now rely on shade, we know of a number if high-visibility ones | 20:13 |
| dtroyer | s/cound/count/ | 20:13 |
| persia | mugsie: either :) | 20:14 |
| mugsie | yup, I had (have?) some awful code in kubernetes that was due to weird interop stuff | 20:14 |
| cdent | dtroyer: that's an argument the interop aspects of the tests aren't working; that the trademark protection is too weak | 20:14 |
| persia | dtroyer: Is then the point of InterOp to reduce code in shade? | 20:14 |
| persia | Or, alternately, to ensure shade works? (in which case, I would think shade tests would be more appropriate) | 20:15 |
| mugsie | WG: doesn't really impact interop for new features - the tests are for features that are in stuff as old as mitaka, are widely deployed, and deployed in an already interop way | 20:15 |
| *** david-lyle has joined #openstack-tc | 20:15 | |
| mugsie | otherwise as we add features to interop we could remove clouds that previously had it | 20:15 |
| dtroyer | cdent: they are too weak, there are still too many ways that clouds are different, but that's not the point here | 20:16 |
| mugsie | for I want to jump between clouds, that really matters for end users. | 20:16 |
| dtroyer | persia: I'm suggesting shade as an indicator, not a goal. It exists due to the sorts of pain interop is intended to lessen | 20:17 |
| mugsie | I personally think the Trademarks should be drivers for features, not passive market followers, but I thought this debate was a good idea, so YMMV | 20:17 |
| dtroyer | it will never go away because of the knobs we give operators and they tent to tweak | 20:18 |
| fungi | a good chunk of shade is also less due to clouds being deployed in ways not meeting the trademark standards, but because we also have a history of allowing deployers to make all sorts of differentiating choices in configuration while failing to give them ways to expose those choices in discoverable ways through the apis | 20:18 |
| fungi | er, what dtroyer just said | 20:18 |
| persia | dtroyer: Understood. The backlog (and wider context) seems to indicate "there is a mandate to do foo, which is assigned to team bar. Team bar doesn't have enough folk to do it, so refuses. Group baz supports and coordinates the mandate with the board. Group quux has been handed the mess and asked to make it work." As such, I would expect group quux to dig into the why, as the underlying issue seems to be resourcing, and the beneficiaries of | 20:19 |
| persia | foo (if they can be defined) presumably are the right parties to provide resources. | 20:19 |
| cdent | We seem to be straying away (maybe because it is time for that) from coming up with a way to manage interop tests effectively | 20:19 |
| cdent | We _know_ we haven't got interop | 20:19 |
| persia | cdent: Yes. This is why I ask "why do we want interop"? If we answer that, we can move to "who gains from interop", and then we know who to ask for folk to help make it happen. | 20:20 |
| cdent | we refer to the tests as "trademark tests" for a reason, these day | 20:20 |
| cdent | despite them being associated with the interop wg | 20:21 |
| mugsie | yeah, I have tried to remove all interop wording over the last while, as they are just trademark tests | 20:21 |
| mordred | dtroyer, fungi, persia: fwiw, it's been quite a while since finding a new cloud has required adding new workarounds to shade | 20:22 |
| mordred | and the newer services have all been _much_ better to work with than the super-early one | 20:23 |
| mordred | ones | 20:23 |
| dtroyer | persia: applying that logic means I need to be soliciting resources from CLI users to staff OSC? I've been told by a (former) Platinum CEO that clients do not matter. It turns out they do matter but like most of our work, the ultimate beneficiaries are not in a position to fund the work, they pay for a service and move that up the stack, so to speak. | 20:23 |
| cdent | that, at least, is great news | 20:23 |
| dtroyer | mordred: and I see that as an indicator that some of this has had a positive effect. Other things enter in to that too, of course, but cloud ops who need to market their cloud do seem to care | 20:24 |
| mordred | yah. things for the most part seem to be progressing towards a reasonable state - the bulk of the extra crazy stuff is to deal with hysterical raisins - those raisins are still out there and in the wild, mind you, but they're not _growing_ - so that's good | 20:24 |
| mordred | dtroyer: ++ | 20:24 |
| cdent | Do we have any anecdata to know how much of it is related to the trademark and how much is related to other kinds of info sharing/marketing/improved awareness of the gestalt/whatever? | 20:25 |
| mordred | WELL ... | 20:27 |
| dtroyer | cdent: I'm not sure how we would measure that, but the fact that consumers of interop tests care when they break show that they have some effect | 20:27 |
| mordred | so, the largest set of issues we've hit fall into a few buckets: | 20:27 |
| cdent | (shit I brought out the big WELL) | 20:28 |
| mordred | - pain of early service choice migrations... nova-network -> neutron being the clear example | 20:28 |
| mordred | - glance v1 -> v2 being essentially completely different, coupled with the v2 task interface being infinitely pluggable yet only actually used by one public cloud | 20:29 |
| mordred | - random weirdness related to the catalog and version discovery and how people did things 6 years ago | 20:30 |
| mordred | as those have fallen off (people have rolled out glance v2, nova-net is mostly gone)- we're left with floating-ip-required/floating-ip-optional/floating-ip-unpossible as really the only _hard_ bit left | 20:32 |
| fungi | trademark is ostensibly tied to interoprtability because lots of companies came to the foundation wanting to use the openstack trademark (or were already using it in a variety of ways) and we knew that interoperability between providers/deployments was terrible at that time so we saw trademark usage grants as a carrot to encourage improved interoperability. the challenge came in trying to figure out how | 20:32 |
| fungi | to define and confirm interoperability | 20:32 |
| mordred | which is to say - I *think* a good amount of alignment that I've seen feels like a natural result of more clouds just being newer and openstack progressing | 20:33 |
| mordred | but that's _totally_ unsupported suppositions / anecdata on my part | 20:33 |
| fungi | and also in the various ways our attempts to define it got pushback from some member companies who saw they would have to do a lot of work to be able to continue using said trademark | 20:33 |
| cdent | thanks for that mordred, good to know | 20:33 |
| persia | dtroyer: I don't care about membership levels or job titles. In practice, the needs of clients matter, but they mostly matter to operators who seek to have folk use their clouds, vendors who seek to demonstrate their cloud deployment software works well with a wide tooling ecosystem, and large end-users who wish to have vendor neutrality when purchasing cloud. | 20:33 |
| fungi | so while the trademarks do serve as a carrot to some, possible loss of the trademarks ended up being a stick for others | 20:34 |
| persia | At least *some* of those folk are likely to see that (or there probably wouldn't be an InterOp WG), and some of them may be able to help cause things to happen. | 20:34 |
| mordred | fungi: case in point - always popular "clouds should allow users to upload images" battles | 20:34 |
| fungi | or "to use the openstack trademark you need to actually be running keystone" | 20:34 |
| mordred | yah | 20:34 |
| persia | dtroyer: To address the other half, *yes*. CLI users may well be the right folk to fund OSC. I know of at least one company consuming a lot of cloud that runs a private fork of OSC, despite my arguments they should join the community. They have a small operator team, but the fork is managed by the development teams. | 20:36 |
| fungi | so anyway, the intended goal is for this to be interoperability testing and for the trademarks to serve as incentive (positive or negative) toward improving interoperability. the result so far has been that the available tests the interop team could draw from to check this weren't really written with that as their original intent, and they didn't (and likely still don't) have people to write better | 20:37 |
| fungi | replacements | 20:37 |
| pabelanger | So, I'm going though the list of potential names for our S release, https://wiki.openstack.org/wiki/Release_Naming/S_Proposals The proposed names all seem fine to me, using a generous interpretation of the rules. Does anybody think we could consider adding any of the names in the do not meet the criteria section of the wiki? | 20:43 |
| dtroyer | pabelanger: Given the events of last week I'd be generous on allowing 'schnee' | 20:45 |
| dtroyer | it would be a variation on the "grizzly exception" | 20:45 |
| pabelanger | :) yah, I could see that | 20:46 |
| pabelanger | dtroyer: the issue might be, it was added after our nomination period. According to wiki it was added 6 march 2018: https://wiki.openstack.org/w/index.php?title=Release_Naming/S_Proposals&diff=prev&oldid=160032 | 20:48 |
| pabelanger | so, we'd need to be okay with that too | 20:48 |
| dtroyer | ack | 20:48 |
| dtroyer | there are some good ones already on the list | 20:49 |
| mordred | I'm putting my money on "Solar" being the name chosen from that list | 20:51 |
| mordred | in keeping with our tradition of people selecting names that don't actually evoke the place in question when possible | 20:51 |
| cdent | I really like Shellhaus | 20:52 |
| cdent | it's so accurately descriptive | 20:52 |
| *** david-lyle has quit IRC | 20:53 | |
| dtroyer | "see": "I thought the Cactus release was a long time ago?" | 20:54 |
| mordred | dtroyer: hahaha | 20:54 |
| * mordred wants Saatwinkel or Schoenholz to win - mostly because it feels like those will be the most fun to make ttx say on a regular basis | 20:55 | |
| mordred | this is how I choose names to vote for | 20:55 |
| cdent | I think I've been at this long enough. Goodnight all. | 21:03 |
| *** cdent has quit IRC | 21:03 | |
| * mugsie just looked at the clock | 21:03 | |
| *** ykarel has joined #openstack-tc | 21:03 | |
| fungi | i'm still holding out hope for my submission, stein | 21:08 |
| fungi | maybe the unicode glyph will sell it | 21:08 |
| fungi | infra-root: i've approved a couple of meetbot additions just now, but there's still one lingering which needs a second core review and would be good to get in at roughly the same time: https://review.openstack.org/522711 | 21:44 |
| fungi | oops, wrong channel! | 21:47 |
| fungi | apologies for the noise | 21:47 |
| dmsimard | mordred: openstack solar would fit kinda well with the whole constellation vision thing :) | 21:54 |
| mordred | dmsimard: :) | 21:57 |
| *** ykarel has quit IRC | 21:57 | |
| *** lukebrowning has joined #openstack-tc | 22:00 | |
| *** lukebrowning has quit IRC | 22:06 | |
| *** david-lyle has joined #openstack-tc | 22:08 | |
| zaneb | dhellmann: still reading scrollback, but what do you mean by 'end run'? | 22:08 |
| dhellmann | zaneb : sorry, us football expression. Folks went around every possible interpretation of the rules and did not engage with the TC and just did whatever they wanted. | 22:11 |
| dhellmann | https://www.merriam-webster.com/dictionary/end%20run | 22:11 |
| *** openstackstatus has quit IRC | 22:13 | |
| *** openstack has joined #openstack-tc | 22:15 | |
| *** ChanServ sets mode: +o openstack | 22:15 | |
| *** openstackstatus has joined #openstack-tc | 22:15 | |
| *** ChanServ sets mode: +v openstackstatus | 22:15 | |
| dhellmann | I'm not sure how else to interpret us ending up in a situation where we have board approved sets of tests used for a trademark program that do not live in tempest | 22:15 |
| dhellmann | that should have been blocked if we couldn't resolve the issue of copying the tests | 22:16 |
| zaneb | dhellmann: both orchestration and dns programs are in draft status still in the interop repo | 22:17 |
| dhellmann | I thought the board approved them at the meeting last week | 22:17 |
| zaneb | the location is not important to the board | 22:18 |
| zaneb | that set of capabilities was approved by the board, yes | 22:18 |
| dhellmann | the tc was asked to give "future technical direction" and we did and it was ignored, so clearly it's not important. That's why I propose we stop talking about the location of tests and let the interop team worry about that. | 22:19 |
| zaneb | reading the resolution again | 22:30 |
| zaneb | "The TC therefore encourages the DefCore committee to consider it an indication of future technical direction that we do not want tests outside of the `Tempest repository`_ used for trademark enforcement, and that any new or existing tests that cover capabilities they want to consider for trademark enforcement should be placed in Tempest." | 22:31 |
| dhellmann | right | 22:31 |
| dhellmann | "future technical direction" is a term the defcore group was using for part of the score where they asked the TC for input | 22:31 |
| zaneb | isn't that last part what mugsie has been trying to do since November? | 22:31 |
| dhellmann | they apparently scored that to 0 for these capabilities | 22:31 |
| dhellmann | which is their right; it's just input | 22:31 |
| dhellmann | my point is just that if they're going to take tests from any repo, we should stop trying to specify rules and let them define them | 22:32 |
| dhellmann | we've been trying, unsuccessfully, to get the qa team to take designate and heat tests. The interop group should have waited until that was resolved, or raised the issue as a higher priority. That didn't happen and trademark programs are now in place. | 22:33 |
| dhellmann | so clearly the policy we had in place isn't working, because the pressure to add the programs was greater than the pressure to extend the qa team to make doing those reviews possible | 22:34 |
| *** dklyle has joined #openstack-tc | 22:34 | |
| zaneb | http://git.openstack.org/cgit/openstack/interop/tree/add-ons/orchestration.next.json#n60 | 22:34 |
| mugsie | zaneb: the point is that the board should never have approved the programs, while the tests were in plugins | 22:35 |
| mugsie | and the qa / interop solution was to ignore a pre-exiting policy | 22:36 |
| zaneb | I get the point, but the interop folks have made clear that there's no obstacle to changing the location of the tests prior to flipping out of draft status | 22:37 |
| mugsie | we are not in draft anymore | 22:37 |
| mugsie | we are in approved. | 22:37 |
| mugsie | the board meeting on Monday approved the 2 programs as full active trademark programs | 22:38 |
| zaneb | other than halt all work on this until the TC or the QA team fixed the discrepancy, I don't know what we could have done | 22:38 |
| dhellmann | and yet we can't get the project teams and qa teams to agree on how to do that, so if the interop group is ok with the tests where they are now then let's just remove the tension and leave them where they are | 22:38 |
| dhellmann | I need to go make dinner, so I need to drop off | 22:38 |
| *** kumarmn has quit IRC | 22:38 | |
| zaneb | dhellmann: I think we have different idea about the purpose of the original resolution, and that's why we don't agree (let me be the first to say that your reading is better supported by the text) | 22:42 |
| *** openstackstatus has quit IRC | 22:42 | |
| *** openstack has joined #openstack-tc | 22:44 | |
| *** ChanServ sets mode: +o openstack | 22:44 | |
| *** openstackstatus has joined #openstack-tc | 22:44 | |
| *** ChanServ sets mode: +v openstackstatus | 22:44 | |
| zaneb | what is does do is tell project teams that if they want to have interop tests, they should be in tempest for solid technical reasons... which is something the TC does actually have jurisdiction over | 22:45 |
| zaneb | so dhellmann is saying that the audience of the resolution is refstack, and that if they're not going to listen (which indeed, they're not technically obliged to) then we should say nothing | 22:46 |
| persia | I read dhellmann as saying "If the various teams involved in the discussion (qa, project teams, refstack, etc.) can't agree, and there is a workaround acceptable to the Interop folk, then leave it alone until it becomes a problem for more than formal reasons. | 22:47 |
| persia | Personally, I think it is a problem for more than formal reasons, because I don't think everyone has thought about the ACLs involved, or the "these tests may never change" bit. | 22:47 |
| mugsie | no, I think dhellmann's (sorry for putting words in your mouth doug) is that if interop is going to ignore a tc policy, the tc policy should be "go ask interop" | 22:48 |
| persia | But I'm not convinced everyone shares that view, because most folk are considerably more pragmatic than I. | 22:48 |
| persia | mugsie: I agree with that reading. | 22:48 |
| zaneb | while mugsie and I are saying that the audience is the technical community and that we should continue to require them to do it in the way we believe minimises the risk of breakage, again for solid technical/organisational reasons, but that circumstances have changed and our instructions need to be updated accordingly | 22:48 |
| mugsie | yes, with the caveat from my side that this should *not* be somehting we are fixing over a week after approving the programs | 22:49 |
| persia | zaneb: The trick there is the word "require": the model in place grants significant autonomy to project teams, including autonomy regarding what will be in their repos, and how that content changes. | 22:49 |
| * mugsie realises that this is *boring* and that getting invested it hard | 22:50 | |
| persia | As a result, without a change to the governance model, there exists no body beyond individual project teams that can require any particular aspect of the content of project team repos. | 22:50 |
| mugsie | hence, it living in the QA program | 22:50 |
| mugsie | but QA seems to have an issue with that now | 22:51 |
| mugsie | but, I digress, it is 23:00 here, and I need some non IRC time today :) | 22:52 |
| zaneb | persia: significant autonomy yes, but signing up to be an official project means that projects agree to place themselves under the TC's governance (and in turn they get a vote) | 22:52 |
| persia | Which means that possible solutions include 1) those interested in the issue building consensus with QA, 2) those interested building consensus with another project team (or starting one), 3) technical leadership assisting with building consensus with one of the teams in (1) or (2). | 22:52 |
| persia | zaneb: Governance, in the sense of compliance with TC resolutions, not in the sense of "do whatever the TC says". The TC could pass a resolution that the QA team MUST do something. The chance of having anyone on the QA team after that, if the QA team is united in disagreement is very low. | 22:53 |
| persia | Remember that all resources in OpenStack are elastic: people are only in teams because they are incented to do so. If the incentives are not strong enough, or being on the team is sufficiently unpleasant, they will go do something else. | 22:53 |
| *** david-lyle has joined #openstack-tc | 22:54 | |
| * persia has no idea if the QA team is united in disagreement, but is only using that possibility to illustrate the limitations of the governance model | 22:54 | |
| *** dklyle has quit IRC | 22:55 | |
| *** kumarmn has joined #openstack-tc | 22:55 | |
| zaneb | the bottom line is that there *was* consensus among all the projects (although not everybody within them, including regrettably the current QA PTL had been brought up to speed) for the current proposal, but the is *no* consensus for the 'leave it to refstack' proposal (I'd be ok with it, but it would leave designate out in the cold) | 22:57 |
| persia | Yes. A solution needs a new consensus. "Leave it to the TC" is not a substitute, although the TC has previously had success forging consensus. Unfortunately, it takes a while, and that the teams do not appear to be working together directly likely frustrates some TC members,. | 22:59 |
| *** kumarmn has quit IRC | 23:00 | |
| *** kumarmn has joined #openstack-tc | 23:01 | |
| *** kumarmn has quit IRC | 23:01 | |
| *** kumarmn has joined #openstack-tc | 23:01 | |
| zaneb | fungi: fwiw I was told by DefCore folks at the time that the reason interop is tied to tempest was an explicit attempt to incentivise new projects to write tests for tempest (at a time when only the core projects really had functional tests) | 23:09 |
| fungi | right, that was part of "working with the qa team" | 23:10 |
| fungi | we wanted the interop effort to drive better testing and not waste cycles building an entirely separate testing framework and body of tests | 23:10 |
| fungi | the hope back then was that interop/qa needs might converge somewhat | 23:11 |
| fungi | it's becoming increasingly apparent that was a pipe dream | 23:17 |
| fungi | but i doubt there exists a sufficiently motivated set of people with the time available to maintain a separate testing solution for interop/trademark qualification | 23:18 |
| mriedem | tonyb: replied in https://review.openstack.org/#/c/548916/ | 23:26 |
| mriedem | with a summary of sorts | 23:26 |
| *** annabelleB has joined #openstack-tc | 23:29 | |
| *** annabelleB has quit IRC | 23:31 | |
| *** annabelleB has joined #openstack-tc | 23:37 | |
| *** hongbin has quit IRC | 23:51 | |
| *** annabelleB has quit IRC | 23:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!