Wednesday, 2018-03-07

dmsimardsmcginnis: yeah the two first PTG days are kinda awesome00:24
*** david-lyle has joined #openstack-tc01:10
*** lbragstad has quit IRC01:27
fungiit'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
pabelangernever seems to be01:46
*** david-lyle has quit IRC01:47
*** mriedem_afk has quit IRC02:03
*** harlowja has quit IRC02:13
smcginnisfeedback 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
smcginnisIf we reworded the first couple days at least it would be slightly more encouraging.05:07
smcginnisThey 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
smcginnisI 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
smcginnisWe could have a couple overlapping days, then two separate tracks the rest of the week.05:10
smcginnisIt would allow for some cross polination, and it could benefit our sponsorship/funding situation.05:10
smcginnisI would rather have some of the challenges that brings than merging the PTG back into the Summit.05:11
*** ykarel has joined #openstack-tc05:49
*** david-lyle has joined #openstack-tc05:59
*** ykarel has quit IRC06:20
*** kfox1111 has quit IRC06:47
*** ykarel has joined #openstack-tc07:05
*** ykarel has quit IRC07:11
*** ykarel has joined #openstack-tc07:37
ttxIf 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
ttxwhich would result in ops being potentially available for other team discussions (like anyone else)08:20
ttxBut 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 fine08:23
ttxIt's the context switch between inward & outward that is imho costly.08:24
*** cdent has joined #openstack-tc09:34
*** dtantsur|afk is now known as dtantsur09:45
*** cdent has quit IRC10:32
*** cdent has joined #openstack-tc10:56
persiattx: Excellent language.  Yes: explicity having the previously described "ops sessions" at PTG makes sense to me.11:19
*** diablo_rojo has quit IRC11:57
*** ykarel_ has joined #openstack-tc12:18
*** ykarel has quit IRC12:18
*** ykarel_ has quit IRC12:18
*** ykarel_ has joined #openstack-tc12:18
*** lbragstad has joined #openstack-tc12:39
dmsimardsmcginnis: 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
dmsimardit 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 IMO13:17
*** lbragstad has quit IRC14:15
*** diablo_rojo has joined #openstack-tc14: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-tc14:21
persiaI 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
persiaI think the general messaging is that all folk involved in a technical capacity should be around as long as possible.14:27
cmurphyhaving ops in the keystone room both wednesday and thursday was really useful for us14:29
TheJuliaThat 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 context14:31
TheJuliapersia: ++, 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 productive14:32
persiaI 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
*** mriedem has joined #openstack-tc14:45
*** pabelanger has quit IRC15:04
*** kumarmn has joined #openstack-tc15:04
*** cdent has quit IRC15:05
openstackgerritLance Bragstad proposed openstack/governance master: Create a new project called oslo.limit
*** pabelanger has joined #openstack-tc15:17
*** hongbin has joined #openstack-tc15:40
fungihrm... 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
mugsiedoes horizon not use mod_wsgi?15:53
fungiwould 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 that15:53
*** david-lyle has quit IRC15: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
fungiit's possible i'm misreading the bullet point there15:55
fungior taking it out of context15:56
mugsieI read it the same way15:56
mugsiethey don't currently require eventlet or oslo.service so hopefully we can avoid it :)15:57
*** cdent has joined #openstack-tc16:00
dhellmannwhy did I think horizon was being rewritten in javascript?16:36
*** ykarel_ has quit IRC16:38
dtroyerdhellmann: 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 list16:38
cmurphythat will make it hard for vertical projects to contribute feature support to it :/16:39
mugsieit does. trying to find what causes any errors is a pain, and I have no idea how to add anything to ours16:43
ttxData: 402 attendees at PTG. 94% of registered people showed up, which is pretty good16:50
dtroyermore data: ~9 snowmen, 1 snow angel16:53
dtroyer(unofficial of course)16:53
pabelangerI think the stadium made it feel like a much smaller number, but when we moved into the hotel, there was a lot of people16:53
cdentare the kata people aware that the slack is shutting down irc gateways?16:55
cdentonly 1 snow angel!!?? I am so alone16:55
dtroyercdent: maybe that's what goes on the commemorative sticker16:56
cmurphyslack is getting rid of irc gateways?16:58
cdenti tried to get to the referenced page (from here ) but it needs auth and I couldn't be bothered16:59
mugsiefrom what I understand the XMPP / IRC gateway was problematic for them, and relied on a single maintainer internally17:16
*** david-lyle has joined #openstack-tc17:16
openstackgerritRuby Loo proposed openstack/governance master: Remove ironic-inspector-tempest-plugin
ttxmugsie: yes I'm pretty sure it jhas nothing to do with ensuring a uniform user experience17:18
mugsieWell, I am sure that is part of it :) but I say the pain / cost has now passed the reward point17:19
*** david-lyle has quit IRC17:33
*** ykarel_ has joined #openstack-tc17:58
*** ykarel_ has quit IRC18:18
*** david-lyle has joined #openstack-tc18:21
*** david-lyle has quit IRC18:35
*** dtantsur is now known as dtantsur|afk18:48
*** david-lyle has joined #openstack-tc19:03
openstackgerritChris Dent proposed openstack/governance master: Clarify testing for interop programs
cdentzaneb, jroll, dhellmann, mugsie, others: that's effort to distill the interop thing to something simpler19:08
dhellmanncdent : "whereas"19:11
cdenti had to do it19:11
cdentI couldn't help myself19:11
dhellmannI think we said that was grounds for dismissal, but that might have only applied to mordred19:12
dhellmanncdent : 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 all19:13
* cdent is secretly begging to be dismisded19:13
cdentdhellmann: I don't think that form will satisfy some of the concerns presented by all the people19:14
cdentthe structure helps to insure that changes people want to make are possible and are not going to be resisted again19:14
cdentand again19:14
dhellmannbecause 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
cdentand again19:14
cdentthus the "in consultation"19:14
cdentand that was mostly being polite19:14
cdentmy assumption is that any relatively new project will always choose to go the plugin route, except for designate19:15
mugsiecdent: 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 fault19:15
dhellmannthe 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 again19:15
cdentmugsie: yeah, good point19:15
cdentdhellmann: 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
dhellmanndo we need to spell out the constraints?19:16
mugsiehonestly, 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 them19:16
mugsieall *trademark tests*19:16
dhellmannif 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
cdentdhellmann: I think we do, because the constraints could provide safety against future arguments19:17
dhellmannthe current constraints did not provide that protection19:17
cdentbecause they are out of date19:18
cdentwe changed things, lots of things19:18
cdentand that's okay19:18
dhellmannthat is one interpretation19:18
cdentwe _want_ change19:18
cdentand we're here to help facillitate it, in part by revising resolutions19:18
dhellmannI have no problem with changing this policy. I just don't like the end-run method being used to do it.19:18
cdentthe rules are for changing19:18
dhellmannand the lack of ownership on the part of the people in the interop wg19:19
cdentand end-runs will always happen because people need change faster than we are willing to provide it19:19
dhellmannthat's a disappointing viewpoint19:19
dhellmannI mean, I don't feel like we were even asked19:19
dhellmannwhich is even more bleak19:19
mugsiecdent: putting fingers in ears and not listening when someone says "this is not right" for a year works pretty well as well.19:19
dhellmannI 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 directly19:20
cdentdhellmann: 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 situation19:20
cdentof course people will just do something else when that happens19:20
dhellmanna lot of those conversations were not about interop tests, though, they were about regular functional and integration tests19:21
cdentdhellmann: 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
mugsiecdent: we havent *really* discussed interop, just tempest itself19:21
mugsiejust the list of projects that they need to consider19:21
cdentmugsie: interop has been under our baleful eye for at least several months hasn't it?19:21
dhellmanncdent : we are responsible for listing "designated sections" of the code to be included, and we do that by giving projects the tc-approved-release tag19:21
cdentI've certainly had conversations about it since before last july19:22
mugsiethe review has been there since november19:22
mugsieI have been talking about since Austin I think?19:22
mugsiewhat was between Austin and Boston?19:22
dhellmannI 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
mugsiebut 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
mugsiepushing tests in generic project repos *will* blow up in our faces, but if interop are ok with it, so be it19:25
cdentdhellmann: 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
cdentI'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 things19:25
cdentBy providing some preferred ways, we give a kind of technical leadership that we ought to be doing.19:26
*** harlowja has joined #openstack-tc19:26
dhellmannI'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
mugsiecdent: the replies on the ML seem to indicate that QA do not want to do reviews on <project>-trademark-plugin repos19:26
dhellmannIt feels a bit like what happened with the docs team, really.19:26
mugsiedhellmann: ++19:26
cdentmugsie: that's fine, they don't _have_ to19:26
cdentbut they will be able to19:26
cdentthat's the crucial difference19:26
dhellmannAnd 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 past19:26
mugsiebut the docs team innovated and pushed everything out to projects and started maintaining just tools19:26
dhellmanncdent : 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 tests19:27
dhellmannif 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 rules19:28
dhellmannand we need to keep training them in the face of turnover19:28
cdentI think we are overstating the amount of review these tests need. Lots at the start, and then not.19:28
mugsiecdent: its not the tests, it is underlying tooling that will be the issue19:29
dhellmannyou'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
cdentdhellmann: 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 http19:30
mugsiee.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 break19:30
dhellmannwhich 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 rules19:30
mugsieand unless we train people to watch for that (or even care) we will break tests19:30
dhellmanncdent : if the behaviors being tested were limited to APIs, that would work.19:30
cdentif the trademark programs are testing something other than apis, how do they work on random clouds?19:31
dhellmannthose clouds have to act like an openstack cloud does when you do things like boot an instance and then try to login to it19:31
dhellmannpart of the purpose of the tests is to show that the cloud acts like openstack, and that's more than the API inputs and outputs19:32
mugsiebetter 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 failing19:32
dhellmannthat's an interesting one19:32
dhellmannthere's a "gentleman's agreement" that folks use the openstack source code; deeper tests is a way of enforcing that19:33
dhellmanncdent :
* mugsie remember's that fight19:34
* dhellmann hears the washing machine finish19:34
cdentI'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
cdentmugsie: 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
mugsieunsafe 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
openstackgerritChris Dent proposed openstack/governance master: Clarify testing for interop programs
cdentmugsie: 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
cdentAs in, once accepted, why would would it change?19:45
mugsiebecause it is a global timeout for all DNS operations, and is defined on a global level19:46
cdentoh you mean a timeout used by the service is being use to control a timeout in tests?19:46
dhellmanncdent : 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 have19:48
dhellmannwhich came about because one of the tests changed and stopped working19:48
dhellmannunless I'm conflating 2 different events19:48
mugsiedhellmann: thats what I remember19:51
mugsiewhatever the command that tempest ran inside the nova instance only worked on linux19:51
cdentwas that command run from the shell somehow, or was it started via the api?19:54
mordreddhellmann: there were grounds for dismissal I could have gotten applied to myself? now you tell me!19:57
cdentrough isn't it?19:58
fungione 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
dhellmanncdent : 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
mugsieI think it was one of those 220:00
cdentthanks mugsie, so a full on ssh into the shell20:01
fungias 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 scratch20:01
cdentfungi: I don't think anyone has a problem with it being tied to tempest as the runner20:01
mugsiefungi: 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 on20:02
dhellmannsome people did, but they aren't here any more20:02
mugsiebut that may be a Vancouver TC/Board meeting item20:02
fungiearly 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 though20:03
persiaOr maybe "work with the QA team" isn't strong enough, and "join the QA team" is necessary.20:04
mugsiepersia: no, they are separate concerns. they should be separate groups. one group just uses a tool the other produces20:05
cdentI 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 success20:05
* mugsie is looking at gabbi, thinks this would have been a much better base for easy to read / review API testing20:05
* cdent sends mugsie a cheque20:06
persiamugsie: 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
mugsiepersia: 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 work20:06
persiaIf 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 IRC20:07
mugsiethe skill sets (of both groups) do not suit the others role in the orgainisation20:08
persiaUsing 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
dtroyerIn 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 board20:08
dhellmannI 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
dtroyershuffling code among repos isn't going to fix the root20:08
persiadhellmann: ++20:08
dhellmannwe do, but at this point the problem isn't fully clear because the task is assigned to the "wrong" team20:09
mugsieno, I am saying that InterOp work should be funded using this lever, and the QA team should be funded, well, for obvious reasons20:09
persiadtroyer: Helping folk who want things understand that doing things is the way to get them done does help the problem.20:09
dhellmannwe may have plenty of people to work on tempest itself if they aren't also tasked with the interop test reviews20:09
dtroyerdhellmann: true, but there is still that bundle of work (interop tests) un-resourced, no matter what team it gets thrown toward20:10
persiaHas anyone done cui bono analysis for why InterOp matters?  Is the beneficiary aware of the problem and prepared to help?20:11
dtroyerthe 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 code20:11
mugsiepersia: 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
dhellmanndtroyer:  of course. it doesn't eliminate the issue, it clarifies it.20:12
dtroyerpersia: the amount of code in Shade could be seen as one measure of why interop is importnat.20:12
dtroyerit is harder to cound how many projects now rely on shade, we know of a number if high-visibility ones20:13
persiamugsie: either :)20:14
mugsieyup, I had (have?) some awful code in kubernetes that was due to weird interop stuff20:14
cdentdtroyer: that's an argument the interop aspects of the tests aren't working; that the trademark protection is too weak20:14
persiadtroyer: Is then the point of InterOp to reduce code in shade?20:14
persiaOr, alternately, to ensure shade works? (in which case, I would think shade tests would be more appropriate)20:15
mugsieWG: 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 way20:15
*** david-lyle has joined #openstack-tc20:15
mugsieotherwise as we add features to interop we could remove clouds that previously had it20:15
dtroyercdent: they are too weak, there are still too many ways that clouds are different, but that's not the point here20:16
mugsiefor I want to jump between clouds, that really matters for end users.20:16
dtroyerpersia: I'm suggesting shade as an indicator, not a goal.  It exists due to the sorts of pain interop is intended to lessen20:17
mugsieI personally think the Trademarks should be drivers for features, not passive market followers, but I thought this debate was a good idea, so YMMV20:17
dtroyerit will never go away because of the knobs we give operators and they tent to tweak20:18
fungia 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 apis20:18
fungier, what dtroyer just said20:18
persiadtroyer: 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 of20:19
persiafoo (if they can be defined) presumably are the right parties to provide resources.20:19
cdentWe seem to be straying away (maybe because it is time for that) from coming up with a way to manage interop tests effectively20:19
cdentWe _know_ we haven't got interop20:19
persiacdent: 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
cdentwe refer to the tests as "trademark tests" for a reason, these day20:20
cdentdespite them being associated with the interop wg20:21
mugsieyeah, I have tried to remove all interop wording over the last while, as they are just trademark tests20:21
mordreddtroyer, fungi, persia: fwiw, it's been quite a while since finding a new cloud has required adding new workarounds to shade20:22
mordredand the newer services have all been _much_ better to work with than the super-early one20:23
dtroyerpersia: 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
cdentthat, at least, is great news20:23
dtroyermordred: 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 care20:24
mordredyah. 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 good20:24
mordreddtroyer: ++20:24
cdentDo 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
mordredWELL ...20:27
dtroyercdent: 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 effect20:27
mordredso, 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 example20: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 cloud20:29
mordred- random weirdness related to the catalog and version discovery and how people did things 6 years ago20:30
mordredas 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 left20:32
fungitrademark 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 how20:32
fungito define and confirm interoperability20:32
mordredwhich 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 progressing20:33
mordredbut that's _totally_ unsupported suppositions / anecdata on my part20:33
fungiand 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 trademark20:33
cdentthanks for that mordred, good to know20:33
persiadtroyer: 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
fungiso while the trademarks do serve as a carrot to some, possible loss of the trademarks ended up being a stick for others20:34
persiaAt 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
mordredfungi: case in point - always popular "clouds should allow users to upload images" battles20:34
fungior "to use the openstack trademark you need to actually be running keystone"20:34
persiadtroyer: 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
fungiso 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 better20:37
pabelangerSo, I'm going though the list of potential names for our S release, 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
dtroyerpabelanger: Given the events of last week I'd be generous on allowing 'schnee'20:45
dtroyerit would be a variation on the "grizzly exception"20:45
pabelanger:) yah, I could see that20:46
pabelangerdtroyer: the issue might be, it was added after our nomination period. According to wiki it was added 6 march 2018:
pabelangerso, we'd need to be okay with that too20:48
dtroyerthere are some good ones already on the list20:49
mordredI'm putting my money on "Solar" being the name chosen from that list20:51
mordredin keeping with our tradition of people selecting names that don't actually evoke the place in question when possible20:51
cdentI really like Shellhaus20:52
cdentit's so accurately descriptive20:52
*** david-lyle has quit IRC20:53
dtroyer"see":  "I thought the Cactus release was a long time ago?"20:54
mordreddtroyer: hahaha20: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 basis20:55
mordredthis is how I choose names to vote for20:55
cdentI think I've been at this long enough. Goodnight all.21:03
*** cdent has quit IRC21:03
* mugsie just looked at the clock21:03
*** ykarel has joined #openstack-tc21:03
fungii'm still holding out hope for my submission, stein21:08
fungimaybe the unicode glyph will sell it21:08
fungiinfra-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:
fungioops, wrong channel!21:47
fungiapologies for the noise21:47
dmsimardmordred: openstack solar would fit kinda well with the whole constellation vision thing :)21:54
mordreddmsimard: :)21:57
*** ykarel has quit IRC21:57
*** lukebrowning has joined #openstack-tc22:00
*** lukebrowning has quit IRC22:06
*** david-lyle has joined #openstack-tc22:08
zanebdhellmann: still reading scrollback, but what do you mean by 'end run'?22:08
dhellmannzaneb : 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
*** openstackstatus has quit IRC22:13
*** openstack has joined #openstack-tc22:15
*** ChanServ sets mode: +o openstack22:15
*** openstackstatus has joined #openstack-tc22:15
*** ChanServ sets mode: +v openstackstatus22:15
dhellmannI'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 tempest22:15
dhellmannthat should have been blocked if we couldn't resolve the issue of copying the tests22:16
zanebdhellmann: both orchestration and dns programs are in draft status still in the interop repo22:17
dhellmannI thought the board approved them at the meeting last week22:17
zanebthe location is not important to the board22:18
zanebthat set of capabilities was approved by the board, yes22:18
dhellmannthe 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
zanebreading the resolution again22: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"future technical direction" is a term the defcore group was using for part of the score where they asked the TC for input22:31
zanebisn't that last part what mugsie has been trying to do since November?22:31
dhellmannthey apparently scored that to 0 for these capabilities22:31
dhellmannwhich is their right; it's just input22:31
dhellmannmy 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 them22:32
dhellmannwe'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
dhellmannso 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 possible22:34
*** dklyle has joined #openstack-tc22:34
mugsiezaneb: the point is that the board should never have approved the programs, while the tests were in plugins22:35
mugsieand the qa / interop solution was to ignore a pre-exiting policy22:36
zanebI 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 status22:37
mugsiewe are not in draft anymore22:37
mugsiewe are in approved.22:37
mugsiethe board meeting on Monday approved the 2 programs as full active trademark programs22:38
zanebother than halt all work on this until the TC or the QA team fixed the discrepancy, I don't know what we could have done22:38
dhellmannand 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 are22:38
dhellmannI need to go make dinner, so I need to drop off22:38
*** kumarmn has quit IRC22:38
zanebdhellmann: 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 IRC22:42
*** openstack has joined #openstack-tc22:44
*** ChanServ sets mode: +o openstack22:44
*** openstackstatus has joined #openstack-tc22:44
*** ChanServ sets mode: +v openstackstatus22:44
zanebwhat 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 over22:45
zanebso 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 nothing22:46
persiaI 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
persiaPersonally, 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
mugsieno, 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
persiaBut I'm not convinced everyone shares that view, because most folk are considerably more pragmatic than I.22:48
persiamugsie: I agree with that reading.22:48
zanebwhile 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 accordingly22:48
mugsieyes, with the caveat from my side that this should *not* be somehting we are fixing over a week after approving the programs22:49
persiazaneb: 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 hard22:50
persiaAs 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
mugsiehence, it living in the QA program22:50
mugsiebut QA seems to have an issue with that now22:51
mugsiebut, I digress, it is 23:00 here, and I need some non IRC time today :)22:52
zanebpersia: 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
persiaWhich 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
persiazaneb: 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
persiaRemember 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-tc22: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 model22:54
*** dklyle has quit IRC22:55
*** kumarmn has joined #openstack-tc22:55
zanebthe 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
persiaYes.  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 IRC23:00
*** kumarmn has joined #openstack-tc23:01
*** kumarmn has quit IRC23:01
*** kumarmn has joined #openstack-tc23:01
zanebfungi: 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
fungiright, that was part of "working with the qa team"23:10
fungiwe wanted the interop effort to drive better testing and not waste cycles building an entirely separate testing framework and body of tests23:10
fungithe hope back then was that interop/qa needs might converge somewhat23:11
fungiit's becoming increasingly apparent that was a pipe dream23:17
fungibut i doubt there exists a sufficiently motivated set of people with the time available to maintain a separate testing solution for interop/trademark qualification23:18
mriedemtonyb: replied in
mriedemwith a summary of sorts23:26
*** annabelleB has joined #openstack-tc23:29
*** annabelleB has quit IRC23:31
*** annabelleB has joined #openstack-tc23:37
*** hongbin has quit IRC23:51
*** annabelleB has quit IRC23:53

Generated by 2.15.3 by Marius Gedminas - find it at!