Sunday, 2018-05-20

*** ricolin has joined #openstack-tc00:44
*** diablo_rojo has quit IRC01:03
*** spsurya has joined #openstack-tc01:11
*** ricolin has quit IRC01:20
*** edmondsw has joined #openstack-tc01:31
*** edmondsw has quit IRC01:35
*** ricolin has joined #openstack-tc04:03
*** ricolin has quit IRC04:34
*** edmondsw has joined #openstack-tc05:07
*** edmondsw has quit IRC05:12
*** spsurya has quit IRC05:15
*** edmondsw has joined #openstack-tc06:56
*** edmondsw has quit IRC07:00
*** dklyle has quit IRC07:05
*** dklyle has joined #openstack-tc07:05
*** persia has quit IRC07:36
*** persia has joined #openstack-tc07:36
*** diablo_rojo has joined #openstack-tc15:33
*** lbragstad has joined #openstack-tc16:11
*** mriedem has joined #openstack-tc16:17
*** mriedem is now known as hansmoleman16:36
*** EvilienM is now known as EmilienM16:50
mugsie - the foundation are hosting a fork of openstack ?17:03
fungia distribution17:03
mugsietitanium cloud has diverged from upstream17:04
fungiedge-focused, previously proprietary openstack distro developed inside a vendor, working to upstream as much the divergence they're carrying as quickly as they can17:04
mugsie(based on their own marketing)17:04
mugsiestill, I am not sure how I feel about the foundation pushing a fork of the openstack project17:05
fungiyeah, i expect them to not tout that as a good thing going forward. sounds like their dev team wants that to eventually just be tools and configuration for upstream openstack17:05
mnaseri'd like to wait until i see code pop up17:06
mnaserand see how much of a fork we're talking about17:06
mnasercause it's still not there yet17:06
mugsieYeah, thats true17:06
fungithe way i see it, this is a positive development since press releases up to this point were that the linux foundation was going to be hosting this "fork" of openstack17:06
mnasermaybe it could be a good first step to working together with the actual upstream teams to allow for these projects to avoid having to fork things17:07
fungithis is what they're saying they want17:07
mnaserex: <x> team learns about how stx needed to fork to do <y>, so <x> team can help drive changes to increase flexibility so that their fork becomes a "driver" or "Extension" of upstream17:07
mnaserit's a win for both if that's the path it goes towards17:07
mugsiefungi: wind river have had at least 5 years to do that17:08
fungiyep, but more recently efforts in that area are being pushed by dtroyer and davidlyle17:08
mtreinishsounds like a good thing I skipped the board meeting today...17:09
fungiagain, if they're going to switch to working on it in the open, it seems better to me that they do it within and together with our community rather than as part of an effort at some other foundation (which judging from press releases seems to have been the plan up until less than a week ago)17:11
smcginnisUs hosting a fork I suppose is better than LF hosting a fork.17:12
smcginnisBut still doesn't feel right to me17:12
*** gcb has joined #openstack-tc17:12
smcginnisI appreciate they're wanting to now work in the open, but I would have liked to see some activity earlier trying to get these downstream changes into the community.17:12
TheJuliaThere are many feelings, but it is a learning experience that we can leverage.17:12
smcginnisMaybe that has happened and I just haven't seen it.17:13
smcginnisTheJulia: That is true.17:13
fungiwhen dtroyer's not on a plane, he can probably speak authoritatively to what things they already got into our services without it being a really high-profile involvement17:19
TheJuliaI seem to remember some patches occasionally get pushed up into some of the projects, but client demands can easily cause divergence. We should take it as a learning experience and remain positive.17:22
mnaserTheJulia: i agree, we have to keep users in mind and maybe this is an exercise for projects to try and learn that we need to be more flexible or people will diverge to serve their users17:23
mnaseri'm not a licensing expert, but it looks like they want to import some gplv2 and gplv3 code17:23
mnaser and
smcginnismnaser: That caught my eye too.17:24
smcginnisI'm trying to approach this with a positive mindset, but I also am concerned about setting this precedent.17:25
smcginnisI know other distros that carry downstream patches for their specific customer needs.17:25
mnaserthat might interest you personally and to have an overall idea at the project17:26
smcginnisIf we have multiple ones like this that need to do this but want to be open, are we going to end up hosting multiple forks.17:26
TheJuliasmcginnis: true, but precedent of rejecting or not encouraging convergence also has repercussions17:27
smcginnisI agree. It's just a concern I think we need to at least consider.17:28
mugsiemy view is that (especially wind river) have had the oportunity to do this for years.17:28
fungiare you sure they haven't already upstreamed at least some features?17:30
fungikeep in mind their contributions may have been coming from intel employees17:30
TheJuliabut the financial cost of maintaining might have finally become too much. When I was at HPE, after a particularly painful few months I went through to identify and nuke downstream patches. I can see differences starting as being minor disagreements where contributors want things in a very precise way that is just a highly opinionated $thing.17:30
fungiso could have looked like "intel contributions"17:30
smcginnisLooking at the commit mnaser pointed me at, this has never been proposed to Cinder even though I don't think it would be too contentious of a new feature to add.17:31
smcginnisAnd it would be done with microversions that wouldn't result in a divergent API experience for end users.17:31
mnasersmcginnis: i tihnk that's one squashed commit of all their changes on top of a branch.. some which actaully seem to be pretty useful user facing features17:32
hansmolemancfriesen works at wind river and pushes up some stuff when we can, but it's not been a secret that they fork a lot of nova17:32
hansmolemanand then use upstream for support / Q&A17:32
fungiyeah, i think dtroyer would be the best person to advocate this piece, but he's in transit until later today17:32
mnaserbut again we shouldn't "punish" them for not doing things in a way from the start...17:32
mnaserthis could be the start of them doing things the way we do things, or we can learn things together17:32
smcginnismnaser: That's my concern - they are useful user facing features that have not be proposed to the upstream community.17:32
mnaserthis is a good first step from their side17:32
mugsieI just think that before we add something like this, the community voice *should* have been more prevailent17:32
mnaserso i hope it's a good step in a good direction17:33
* fungi applauds mriedem's simpsonsesque altnick17:33
smcginnisI'm not -1 at this point (other than a lot of things in the Cinder code I would have asked to be changed before merging) but willing to hope it's the first step in the right direction.17:34
TheJuliaLooking at the ironic repo, I could see one of those changes being problematic for the contributors, but I also don't have context to why wind river did their changes. That would better help, and maybe this is a case by case thing17:34
dhellmannyeah, I imagine it will be17:35
smcginnisHopefully we can either add their features upstream or find a good way to meet their user needs in a way that will fit with what's acceptable upstream.17:35
TheJuliaWell, ironic seems minimal, still don't understand the why17:35
mnaseri think this would be the same if redhat published their spec files with all the patches they carry on top of their customers17:36
fungiit sounds like they started off forking more aggressively than was reasonable, realized that was a poor choice and began working to upstream as much of it as they could but there was a lot to get through, and very recent events have caused them to want to finish doing that with their existing patches presented openly rather than keeping them secret while they continue finding available developer time to17:36
fungisubmit them to the corresponding upstream repos17:36
mnaserbut the difference is the patches are *already* applied in a sense17:36
EmilienMso OpenStack was forked and now it's asked to move the forked repos into OpenStack?17:40
EmilienMand these repos will be maintained by 2 separated teams, testing 2 separated set of CI jobs, etc etc?17:41
* EmilienM sad face17:41
dtroyerEmilienM: not quite really...17:41
mnaseroh yay we have dtroyer to speak about it here now :)17:42
dtroyerwe are starting with a building shipping commercial product, with a lot of market-specific additions17:42
dtroyer((on a plane, on my way to the meeting))17:42
dtroyersome of the bits have been upstreamed, many have not for lots-o-reasons17:42
EmilienMwhy moving the repos to OpenStack?17:43
TheJuliaI think, at least on a case by case basis, teams should look at these changes and see if they make sense to pull in, which ultimately makes sense. Some of the changes in cinder actually look more along the lines of hardening17:43
dtroyerand yes, the assessment that carrying custom code did finally catch up with them, that wasn't the driver here but is an accurate descripion17:43
mugsiethere is API incompatibility between them - so this i going to be an interesting discussion17:43
dtroyermugsie: yeah, that part pisses me off actually, and I may be the first in line to attempt to remove it17:44
dansmithdoes the request to use openstack CI infra come with money to increase quota? because it feels like we're running really thin as it is...17:44
smcginnisWhich brings me back to the concern about having several other vendors with downstream patches potentially wanting to follow this lead as a way to get community help with their product maintenance.17:44
dtroyerTheJulia: we have a long list of those patches and many have actually been looked at by current open stack devs.17:44
smcginnisAnd the API incompat is almost a show stopper IMO.17:44
dtroyersome are ripe to be pushed, many will need work, some just are not going to go17:44
dhellmannmaybe we should consider importing these patches as a community goal?17:45
TheJuliadtroyer: yeah, I've seen wind river folks pop up every so often in the past, so not surprising.17:45
dhellmann"let's welcome StarlingX by helping upstream their improvements"17:45
TheJuliadhellmann: +117:45
mtreinishdhellmann: why? how is this different then any other product team's fork?17:45
mugsiemtreinish: ++17:45
dhellmannmtreinish : because they're trying to join us17:45
EmilienM"StarlingX" isn't the first "commercial product" which has special needs17:45
TheJuliaWell, this goes back to each team needs to better understand17:45
dtroyerI'd love the help dhellmann… that is a big part of my immediate future17:45
EmilienMand AFIK there is no precedent in having forks of OpenStack being imported into OpenStack namespace17:46
mnaserdtroyer: just an fyi, repos might need a bit more scrubbing --
dhellmannthe first step is to understand exactly what differences exist17:46
clarkbEmilienM: we've done it before, debian packaging was effectively a fork in our hosting17:46
EmilienMclarkb: it wasn't a commercial product17:46
dtroyerEmilienM: no there isn't and I'm not going in to the whys of that here… this is an Edge focus area project that is using the infra, unlike Kata whis is doing their own thing17:46
clarkbEmilienM: correct but it was a fork17:46
mugsieclarkb: deb packaging didn't change the API17:46
TheJuliaSo each team should take time and try to understand, and kind of work from there to help them reduce their debt while reflecting where things might have not worked that caused the differences to begin with.17:47
clarkbmugsie: I'm not arguing the merrits or details just pointing out we have (and actually continue to) host an existing fork of openstack17:47
dhellmannI need to focus on the in-person meeting, but I imagine this will be a big topic for us to discuss over the near future as we learn more about it17:47
fungialso it's worth pointing out that the current proposal is _not_ for starlingx to become part of openstack the project, it's to upstream the divergence from upstream openstack repositories but the starlingx project is simply seeking guidance and support from the openstack foundation at this point17:47
smcginnisBut deb packaging did not change the API and make a bunch of incompatible differences.17:47
EmilienMI guess my question is why do you want these forked repos part of OpenStack?17:47
mugsiefungi: this is problem with the foundation and the project having the same name17:47
*** edmondsw has joined #openstack-tc17:47
fungii predict the foundation may attempt to distance itself from the openstack name in time17:48
fungito help avoid further confusion in that regard17:48
smcginnisfungi: I was half expecting that to happen today.17:48
TheJuliafungi: I would make the same prediction17:49
dtroyerso, did this and airship get brought up at the meeting already?17:49
mnaserdtroyer: yes17:49
mnasernot discussed much in person however17:49
EmilienMin some slides17:49
TheJuliaairship was mentioned briefly, but not in great detail17:49
mnasermostly discussed on IRC only in here and #openstack-board17:49
dtroyerI'll trade a nice description of how that went for as many questions as I can answer, in person, tonight...17:49
EmilienMdtroyer: are them related from eath other?17:50
EmilienMare they*17:50
mnasermaybe those who have specific questions answered can add them to and dtroyer could take time to draft up answers?17:50
dtroyerthat's for story time, but the short answer is they know each other17:50
dtroyermnaser: thanks for re-posting that17:51
EmilienMdtroyer: is the long term goal to integrate all the features into their upstream repos and get rid of the forks?17:51
EmilienMif yes, why do we want to move the forks into infra? to use infra tools? (gerrit, zuul, etc)17:52
dtroyerEmilienM: as many as possible.  you will hear people say all, bt realistically that isn't going to happen for $REASONS17:52
*** edmondsw has quit IRC17:52
dtroyerEmilienM: this is where the foundation hosts things. Kata could have done the same thing but chose to use github and slack and whatnot17:53
dtroyeroh, so #starlingx is a thing too, fyi17:53
dtroyerpretty quiet so far and not logged yet (on my list)17:53
EmilienMand why moving the repos?17:55
EmilienMerr irc refresh error, sorry, I saw your answer now17:55
smcginnisGood to add to the question etherpad if it's not there since I'm sure these are all going to be very common questions.17:56
fungiyes, the foundation executives and marketing team are also going to be very eager to have answers for those sorts of questions since i'm sure they're going to need to field a lot of the same ones17:57
dtroyerWRS+Intel marketing types have a sheet of answers, but mostly not at this level of tech detail.17:59
* dtroyer goes back to pushing out staging repos so zuul goes green18:00
EmilienMI'm afraid to set a precedent if we warmly welcome stx. (my opinion now ->) I don't think like it's done the right way, if a product has feature it should be proposed in the open, with the community, and not proposed in a forked repo to the community18:01
mugsieEmilienM: ++18:01
EmilienMwe have been working HARD over the last years to make people work in the open18:01
mugsieand I really do think that this is one area or project addition, that the foundation should have discussed in advance18:01
EmilienMand now, we're discussing about introducing a new project that use forks of OpenStack18:01
EmilienMI'm probably missing context here but so far the idea sounds terrible to me.18:02
mugsierather than "surprise - there is mailing lists and repos are being added"18:02
* TheJulia is worried we're focusing far too much on an effort to reconcile debt which may have resulted as a resistance to change or an inability to cycle a patch 15-70 times18:02
mugsieTheJulia: as smcginnissaid before, none of the cinder  changes were pushed upstream18:02
TheJuliacan we say that for every single line?18:03
TheJuliaacross every changeset revision ?18:03
EmilienMI've been in hundreds of discussions where we said people to push their stuff upstream first18:03
fungimugsie: to be fair to "the foundation" they found out a couple of days ago that this team wanted to seek their guidance rather than following their previous plan to host it with a different foundation18:03
fungiit was going to be opened up either way18:03
EmilienMI've joined the TC for that reason in fact, to keep pushing this idea18:03
EmilienMif we go down to the path where we are ok with this model of contribution18:04
fungithe other foundation was eager to host "an improved openstack"18:05
hansmolemanwe tell windriver people to upstream stuff in nova all the time,18:05
hansmolemanthe response is that they are dev constrained for time to do that18:05
hansmolemansometimes things get pushed up, reviewed and merged,18:05
hansmolemansometimes they have problems, don't move forward and are abandoned18:05
dansmithwell, and to be fair to them and us, some of the stuff they want are things we reject as out of scope or against our other approaches18:05
dansmithbut, that also tells you what I think about bringing in all their forked changes18:06
dansmiththe bits they propose which are appropriate definitely get ignored as "meh, they didn't take it within two revisions so I give up"18:07
TheJuliaPerhaps it is time to re-evaluate approaches or scope as well18:07
TheJuliabut that is a pre-project, in-project discussion18:07
dtroyerEmilienM: does RDO carry _any_ patches to openstack code (asking because I actually don't know)18:08
EmilienMdtroyer: not AFIK, if you find one please let me know18:08
dansmithdtroyer: speaking from the OSP nova perspective, we aim to have zero non-bug non-backport changes18:08
fungiat least some distros backport patches from newer branches18:08
dansmithdtroyer: nothing that is a feature before it has landed upstream or will never land18:08
EmilienMdtroyer: and if we do, we don't fork repos, we have .patch files in the rpm repos18:08
dtroyerok, I just haven't looked yet but someone asked me18:08
EmilienMdtroyer++ yes exactly18:08
EmilienMerr, dansmith++ exactly18:09
fungibut yeah, i agree that having features which aren't upstream and api incompatibilities is way different from backporting bug fixes from newer branches that upstream didn't backport18:09
dtroyerEmilienM: yup, and stx has a lot of those too.  they are all 'small', I'm not sure how they decided when to make a repo.18:11
dtroyerso question for the group, if we carried all of this debt as patch files and applied them in the build is it diffferent?18:11
EmilienMRDO is really about consuming upstream repos here18:11
dansmithdtroyer: it makes reasoning about the delta quite a bit easier18:11
EmilienMdtroyer: it would be better, IMHO18:12
dtroyerdansmith: I'll have a pile of patch files you can look through soon18:12
dtroyerEmilienM: is it better just because it isn't in the same form as upstream?18:12
dansmithdtroyer: patches against an upstream tend to be well-cultivated and rationalized, and not just a stream of fixup commits you make against your branch18:13
dtroyerie, would a pre-patched tarball be the same as a repo or as individual patch files?18:13
dansmithdtroyer: just generating the commit delta from a fork branch is very different from cultivated deltas18:13
dtroyerdansmith: I understand that, it isn't the technical process that I thought was the issue18:14
dansmithdtroyer: that said, I'm not likely to ever look at that set of patches unless it's to try to reason about the nefarity of things going on there, because the way I evaluate changes against the projects I work in is via patches in gerrit against the upstream repo :)18:15
dansmithor specs for larger changes18:16
dtroyerdansmith: totally.  these are against pike, and we have a lot of work to do to resolve 2 releases of change18:16
* fungi is trying to figure out if the alternatives at this point (hosting the same modified openstack distro with lf, or continuing to keep it private) are options our community would have preferred18:18
dansmithI think importing it into the openstack namespace implies (to may of us) some level of support for the direction at least,18:18
dansmithwhich is my reaction to it18:18
fungii really want to get rid of that namespace18:19
dansmithI hope it's not an ultimatum sort of thing where if we don't own it, another foundation will "get" it18:19
fungito the contrary, press releases made by that other foundation were already saying they were hosting it18:20
fungiand the devs on it seemed to prefer to seek guidance from the openstack foundation than to have it managed by lf18:20
dansmithbeing hosted by LF makes it oddly seem like a competitor, which would be unfortunate18:21
fungimy sentiments as well18:21
dansmithbut it also feels like a big slap in the face to those of us working upstream to have "our" foundation bless it, when I think most of us feel like that's the wrong way to contribute18:21
fungii'd rather help them fix this than to have lf talking about their improved openstack that the openstack community rejected18:22
EmilienMdansmith: I really feel the same thing as you described18:22
dansmithfungi: I guess I'm not sure why we have to choose between them going to LF and competing, or us blessing it.. if what they really want is counsel and collaboration, I would think we could do that without them needing to join one or the other18:23
EmilienMdtroyer: imho it would be better to have .patch files per repo and per feature/bug (no squad)18:23
* TheJulia makes mental note to buy dtroyer a drink because this must be very stressful at the moment18:24
fungidansmith: corporate pressure on large projects like that usually is that there needs to be a foundation on hand to deal with the trademark issues18:24
dansmithfungi: like, meaning, I hope they're not shopping one against the other if their intentions are really noble18:24
dansmithfungi: well, I guess that's part of my question.. if the goal is keep the trademark and have this live on as a thing, then that really affects my feeling of what we should do with it :)18:24
dtroyerEmilienM: the squash is a legal requirement by the code owners, I did manage to get them to let me release a curated set of commits as docs, otherwise upstreaming is just not possible from that squash18:25
dtroyerthose will be out later just due to time constraints18:25
mugsieThe trademark issue is the exact problem for me - we have used the trademark program to hold distros to account, and now that is not a tool for the starlingx repos18:26
dansmithmugsie: exactly18:26
dtroyerdansmith: those choices don't get made for the reasons you and I think about unfortuantely… I hoestly do not know what went in to that decision18:26
fungito reiterate, they're not proposing to have it become part of the openstack project, but yes having the openstack foundation handle their trademarks and legal needs does muddy that perception (as does our technical baggage of having "openstack" stamped all over our infrastructure, which i hope to help fix soon, some is already underway)18:26
dansmithdtroyer: yeah I know :)18:26
*** mgagne has quit IRC18:27
*** dansmith has quit IRC18:27
*** mgagne has joined #openstack-tc18:27
dtroyermugsie: WRS was/is working on passing refstack, but with the api mods it is impossible…18:27
*** mgagne is now known as Guest7432218:27
*** dansmith has joined #openstack-tc18:28
*** dansmith is now known as Guest9204918:28
fungimugsie: i wasn't referring to the openstack trademark, but rather distinct trademarks for the separate project18:30
fungie.g., a "starlingx" wordmark and related logos18:31
*** Guest92049 is now known as dansmith18:31
fungiobviously having it claim to be openstack or use the openstack logo without meeting openstack trademark requirements would be a definite no-no18:32
EmilienMfungi++ thanks for explaining that, it makes more sense.18:37
mugsiedoes the LF host the Wind River linux kernel forks?18:38
dtroyermugsie: no, or I should say I'm not aware of anything else from wrs hosted at LF18:41
fungithis has been one of my concerns... i'm mildly worried about perceptions if we host forks of ceph and qemu, but i don't know if the starlingx devs have approached those projects about hosting those18:41
dtroyerstx is the complete Titanium, kernel and all18:41
EmilienMdtroyer: you flying to YVR? hope we can discuss more in person, maybe today18:41
dtroyerfungi: no we haven't.  the considerations are all the same18:41
dtroyerEmilienM: about to land, I'm headed to the board meeting18:42
fungithanks dtroyer!18:42
*** tbarron has quit IRC18:43
*** amotoki has quit IRC18:43
*** amotoki has joined #openstack-tc18:44
*** tbarron has joined #openstack-tc18:44
fungifrom an infra team perspective i don't have any significant concerns with the proposal to host these repos (though it does increase the urgency for reducing the "openstackiness" of our infrastructure). with my tc hat on, starlingx is not asking to be part of openstack itself and so wouldn't be governed by the openstack tc18:44
dansmithfungi: you're not worried about lack of resources?18:45
fungii do think our (tc members) opinions matter because it's related to openstack, but it isn't entirely tc jurisdiction18:45
fungidansmith: resource consumption will be mostly determined by the volume of contributions/change proposals their repositories get18:45
smcginnisfungi: Would it be possible to host these repos NOT under the openstack namespace?18:45
dtroyerdansmith: resources do matter, and I am concerned about that too18:46
mugsiefungi: as members of the foundation, our opinions matter18:46
fungimugsie: i concur18:46
dansmithfungi: right, if it's ignored then no real change, but if not...18:46
clarkbreality is ~3 projects eat like 80% of our resources18:47
mugsieand as members of the community, who build the reputation, and the legitimacy in the open infra space, we should have a say on who we allow to share that with18:47
fungismcginnis: it's possible to host them in a different git namespace on gerrit today, but we'd rather just work on getting rid of the namespacing18:47
clarkbeverything else is an extremely long tail so I typically don't worry about new projects18:47
clarkb(nova neutron tripleo if you are wondering)18:47
dansmithclarkb: I guess it's the precedent I'm concerned about18:47
fungismcginnis: and we already have solutions to put them on their own git servers, documentation site, mailing list site, et cetera with no mention of openstack18:47
smcginnisfungi: Seems more of a reason to not put them under the openstack namespace if we want to move things out of there anyway.18:47
dansmithincreasing or fattening the long tail of things we give quota to which are loosely related to openstack18:47
mnaserdansmith: hopefully we can have multiple tenants inside zuul so specific providers can decide/agree to provide quota to the "umbrella" of projects that they'd want to give resources to18:48
fungismcginnis: so the "openstack" namespace is mainly relevant to gerrit itself18:48
fungi(that is, if you ignore github, which we'd like to get someone else to manage so we can stop replicating everything there ourselves)18:49
smcginnisfungi: On a technical level. But I also think the openstack namespace for this is relevant for a mindset/perception level.18:49
dansmithmnaser: that'd be nice -- I can see some providers of quota not wanting to contribute to a forked ceph development, for example18:49
fungismcginnis: "namespace" where, is what i wonder18:49
mnaserbecause as things continue and if OSF onboards more projects, the infra donations that are for "openstack" (the cloud software) start being used by other things under the "openstack" (the foundation)18:49
dansmithmnaser: yeah18:50
dansmithmnaser: it used to be more clear, but lately that line is getting super fuzzy :)18:50
smcginnisI would be slightly more inclined to be supportive of this if we arent putting it under something that makes it look like it is OpenStack.18:50
dansmithsmcginnis: that was my point before.. there's a lot of unwritten implication behind putting it under openstack/ even if that isn't really technically important18:50
smcginnisPrivacyScreenStack maybe. :)18:50
mnaseri think if openstack "the foundation" was called something else.. we'd all be a bit happier overall18:50
clarkbfwiw the tc explicitly agreed to that use o fthe namespace iirc18:50
clarkblike I get the concern but infra implemented what the tc asked for18:51
clarkbits painful to change that all again at hte direction of the tc18:51
clarkb(granted some of that was via input from the infra team saying moving thing saround every week was painful)18:51
fungismcginnis: the other big change is that most of the shared services need to be renamed to a domain which isn't so that we don't imply things using/relying on those are part of openstack18:51
smcginnisI'm fine with it using resources and libs from openstack, as long as we are not implicitly conveying that it IS openstack.18:52
clarkbsmcginnis: right there is a tc resolution that killed stackforge/ and uses openstack/ globally instead related to that18:52
fungithere are lots of things the infra team would like to do in the vein of de-openstacking services, but there is also only so much we can do to influence what random people might assume18:53
smcginnisI feel like two different things are getting lumped into one here.18:54
smcginnisI'm not talking about the overall removal of the openstack namespace.18:54
smcginnisI'm saying this particular set of repos only, just adding it under a different namespace would make a difference to a lot of people.18:54
*** mriedem has joined #openstack-tc18:54
clarkbsmcginnis: right and I'm saying the existing tc resolution is to not do that18:55
smcginnisSo removal of stackforge/ doesn't seem relevant here.18:55
clarkbstackforge would've been the lace we hosted this if it still existed18:55
mugsieclarkb: that is for the TC projects - nothign to do with the OSF18:55
clarkbmugsie: no...18:55
*** hansmoleman has quit IRC18:55
clarkbit literally said unofficial projects no longer go in stackforge/ they go in openstack/18:55
mtreinishclarkb: I dont think there is anything in that tc resolution about adding new namespaces. IIRC its just about moving stackforge into openstack/18:56
smcginnisOK... but I still don't think any of that is relevant here.18:56
fungismcginnis: for what's already been done, see and and for examples of a non-openstack project avoiding making itself look like openstack but still sharing common infrastructure. kata, airship and starlingx can get similar treatment18:56
smcginnisfungi: ++18:56
fungiand that effort is already underway in those cases18:56
clarkbright we'd do ^ with the gerrit (and consequently github side) still being openstack/ until we dropped the namespacing entirely18:57
fungifor other stuff like gerrit, where we'd probably not like to be stuck running a bunch of separate gerrits, is to move it to some neutral (non-openstack) domain name18:57
smcginnisclarkb: But is there a technical reason to have to do that?18:57
clarkbsmcginnis: yes repo replication and my sanity18:57
clarkbsmcginnis: if we weren't consistent every project would need a config entry in gerrit to tell it where ti replicate18:58
clarkbnd anytime a ne wproject was added gerrit would have to be restarted18:58
clarkbuntil such a time as we can remove the namespacing entirely and use pull rather than push replication18:58
smcginnisOK, that's at least a technical reason.18:59
fungiyeah, dropping management of github replication and letting someone else take care of deciding what github orgs get which projects (even if the infra team hosts whatever daemon/process is configured to perform the shuffling) would make things saner18:59
*** cesarlara has joined #openstack-tc19:00
fungii suppose we _could_ transfer all the openstack namespace repos on gh to a neutral org namespace and leave the openstack namespace empty there, but there's no good api to automate that in gh so the manual work to do that for ~2k repos would be monumental19:01
mtreinishfungi: heh, I've automated things like that using selenium to push buttons in the ui :)19:02
clarkbexpect for the web19:02
fungibut noted19:03
smcginnisfungi loves GUIs.19:04
mtreinishfungi: sdague actually maintains a lib for something like that for his chevy bolt, to harvest data from their terrible website:
dansmithselenium is amazing, fwiw19:09
dansmithI use it to automate a stupid web ui for a bunch of devices19:10
clarkbas far as dropping namespaces entirely goes the big need there is the replicaton tool that can pull to push rather than relying on the built in gerrit configs aiui. Then we'll need a flag day since chances are some redirects will break and things will get sad for a little while. Nothing in that task requires infra root or really any infra involvement beyond making sure openstack is replicated to where19:10
clarkbwe want it afterwards19:10
clarkbI think ttx was going to work on this in his bounty of freetime?19:11
clarkbmaybe we need to resync on that and find someone who can spend a few days getting that done and go from there?19:12
*** lbragstad has quit IRC19:18
*** diablo_rojo has quit IRC19:27
*** cesarlara has quit IRC19:28
*** edmondsw has joined #openstack-tc19:36
*** edmondsw has quit IRC19:41
*** lbragstad has joined #openstack-tc20:28
ttxmnaser: +1... I feel like if the Foundation was called something else, people would be a lot less concerned20:50
ttxalso if we had completed the git namespace flattening20:50
ttxstarlingx is not meant to be a part of openstack, it's just the start of an open collaboration on an edge-oriented / IoT-oriented distro of openstack20:51
ttxBut being piloted under the "OpenStack foundation" you can read it as blessed by "OpenStack"20:52
ttxAnyway, looking forward to discussing with dtroyer how to set it up so that we encourage convergence rather than divergence20:53
EmilienMso it wouldn't be part of OpenStack but blessed by OpenStack?20:53
ttxdefine "OpenStack"20:53
ttxnot a part of OpenStack the product20:53
ttxsuported by the OpenStack Foundation20:54
EmilienMI have 404 on now, (it was working this morning) - dtroyer: did you move it?21:04
cmurphyeven if the openstack foundation was called something different, i don't like the idea of the foundation supporting a fork of their founding project (openstack), it feels like a dismissal of their roots21:05
mtreinishcmurphy: ++21:06
smcginnisAnd a dismissal of the work some have done to get features merged upstream in a community accepted way rather than just doing it on their own and getting their customers using it, then throwing it back to the community as now something that needs to be accepted or look like we don't care about these user's needs.21:08
mugsie(the gerrit review has the wrong org)21:09
EmilienMmugsie: thx :)21:10
dtroyerEmilienM: it was up when the wifi shutdown on the plane, I'll go look, nothing intentional21:17
dtroyeroh, it's starlingx-staging  note the x21:17
dansmithttx: an "edge oriented *distro* of openstack" is quite different from "a fork of openstack with incompatible changes...for edge"21:18
dtroyermugsie: thanks, it'll be in the next rev21:19
smcginnisdansmith: ++21:19
mugsiedansmith: ++21:19
dtroyerso what process would you all suggest if you were writing the rules today?  Start with a 4 year old proprietary product with users and the need for backward compatibility, then bring the good bits upstream and deal with the rest after that…21:20
dtroyersome folk who are not so open source conversant think this is telling us to go away21:20
smcginnisYeah, I'd like to see the necessary functionality brought in to normal upstream, then the downstream figure out how to migrate their users to the "standardized" way.21:21
dansmithdtroyer: the need for backward compatibility for your users that you sold a fork to is the price you pay for having taken the easy early path of "meh just fork". it's going to be hard and expensive21:21
dtroyersmcginnis: ++21:21
dansmithsmcginnis: right, migration is the fork's cross to bear21:22
smcginnisUnless they propose the feature, we can't tell them to go away. ;)21:22
dtroyerdansmith: right.  how do we start?  given the thought that we migrate off the oddball functionality,do we have to be perfect before we come here?21:22
dtroyerdo those comments address the concerns you raised earlier?21:22
dansmithdtroyer: I think the process is (1) get enough stuff into upstream that you're willing to switch (2) figure out how to switch21:22
dtroyerI'm trying to decide which conversation we need to have first21:23
EmilienMsmcginnis: ++21:23
fungia big part of the question though... are they supposed to keep their modified source code secret while they work to upstream parts of it?21:23
mugsiethey can, or not, it is up to them21:24
smcginnisGitHub repos are free.21:24
dtroyerI can point to how that worked for 4 years, not well21:24
fungior just form their own foundation to take responsibility for it in the meantime?21:24
dansmithfungi: making it unsecret is great for sure, but needing it to be owned by OSF is a different thing21:24
*** edmondsw has joined #openstack-tc21:24
fungismcginnis: github repos don't cover legal needs21:24
smcginnisSince it's currently a proprietary fork of OpenStack, what do they need for governance other than their own existing business processes?21:25
mugsiefungi: for a product that is moving into open source, there is no need to have a foundation21:25
mugsieit is still owned by wind river21:25
fungithey're not going to form their own foundation for it, and the responsible organizations are going to force them to put it under a foundation, so the question is whether it goes under the same foundation we're under, or another existing foundation (and which one would you suggest as more appropriate?)21:25
dansmithI guess the cynic in me assumes the real reason they want the foundation umbrella is for the free marketing and free instant legitimacy21:26
dansmithnot for real legal reasons, but IANAL and IANACIO21:26
dansmith(thank goodness)21:26
fungicompanies like intel are not going to be in favor of their source code not covered by a foundation21:26
mugsiefungi: the tooling for deployment - sure that makes sense for edge focus areas in the foundation21:26
smcginnisWhich is fine21:26
mugsieforks of the code, not so much21:26
smcginnisAnd why they should propose those features upstream.21:26
mugsiefungi: and if they can't get the feature in upstream, deal with it like every other vendor21:27
fungiother vendors in that situation aren't trying to make their versions open21:28
smcginnisFor me, this still comes back to setting an incredibly bad precedent.21:28
mugsieand the optics look *terrible*21:28
smcginnisIf other vendors in that situation see this success for them as a way to push their downstream changes, that would be Very Bad.21:28
dansmithsmcginnis: yeah, like big company X can force their stuff into the upstream by open-sourcing their proprietary product and making it uncomfortable for everyone until we absorb the delta21:28
dansmithsmcginnis: exxxxxactly21:29
mtreinishfungi: having things be truly open and publishing a fork on github are different21:29
*** edmondsw has quit IRC21:29
fungii still feel like their original plan to have lf host their openstack distribution was even less great21:29
pabelangersmcginnis: ++21:29
mugsiethe community couldn't do it, so we have to get Wind River to do it, and make it a separate thing from the rest of openstack21:29
fungiyep, separate thing from the rest of openstack is important here21:29
mugsiefungi: it would not look like the foundation has decided that the community can't do edge, that it has to be this group of other people21:30
fungishould we expect openstack contributors to be doing everything? does zuul being a separate project mean the foundation has decided the openstack community can't do ci/cd?21:31
dansmithfungi: no, we're not saying that everything has to be in openstack to be good21:32
mugsieno, but no one forked zuul, and then pushed that fork into a new project, while the original is still being developed by the original devs21:32
dansmithfungi: clearly that's not true, it's the approach that matters21:32
*** lbragstad has quit IRC21:34
fungiwould this conversation be different if the openstack foundation had a different name?21:35
mugsieNo, it would be less of an issue, but it is still an issue21:36
mugsieit would be*21:36
mtreinishnot for me21:36
mugsieI would think hosting a fork of your own software is not great21:36
EmilienMmugsie: very good point21:36
mnaseri like to imagine the name of the openstack foundation.. as say.. open infrastructure foundation.  and then projects sit inside of it21:37
mnaseri don't feel as super opposed to it when it's labeled as that21:37
dansmithmugsie: unless you're hosting the "this is before we cleaned up our game" or "this is where we're headed" which is exactly why it's confusing here I think21:37
mnaserbecause starlingx is just a project of the "open infrastructure foundation", so is kata, so is airship, so is zuul21:37
mugsiedansmith: yeah - that can be normal21:39
fungidoes, e.g., kata's choice to use github/jenkins for their code review and testing while still being managed by the same foundation make that distinction from the openstack project easier?21:40
mugsiefungi: and the scopes don't overlap21:40
mugsieone is a CRI, one is an IaaS21:40
fungidoes airship's overlap with existing official openstack projects not pose similar concerns?21:41
dansmithfungi: if kata came out of some company forking an openstack component making changes and then coming _back_ to the foundation to say "we made this thing better, so now it's a new thing" such that it overlapped with the original thing instead of just collaborating, then it would be the same thing21:41
dtroyerso one thing LF was going to require for DCO-like reasons was to squash all of the upstream history under the new code squash.  would that help in the messaging for anyone?  It wouldn't look nearly as much like the upstream repo21:41
dansmithfungi: that there are different things with different scopes, or even some overlapping scopes, but that were built from different bones is not a problem for me21:41
dansmithdtroyer: it's mechanics, which isn't really relevant to the actual messaging I think21:42
dtroyerok, I couldn't decide how that would come across21:42
mugsiedtroyer: it might depend on the commit messages :)21:43
fungiso if the starlingx team had written an openstack competitor to focus on edge computing use cases rather than starting from a basis of reusing (and modifying) openstack, that would have been an okay thing for the openstack foundation to manage?21:43
mugsienot OK, but better imho, yeah21:44
dansmithfungi: I think it'd be a different conversation21:44
dtroyerbased on our history of not really liking any overlap, that would be a bigger "no"… how can you attempt to bring things together in that situation?21:44
fungiso we'd rather see competing but separate implementations rather than building on the source code openstack has published?21:45
dtroyerin this case I believe the intention of the sponsors, it is certainly my intention, is to bring everything back upsream that makes sense and is beneficial21:45
dansmithfungi: I think you're headed down a path of assuming or implying that we don't like competition, and that's not really it at all21:45
dtroyerI chose this solution, help me find the one that works here if this isn't it21:45
fungii get that the way they initially built their solution on top of openstack was not a great way to go about it21:46
dtroyerdansmith: the TC votes over the years make that one clear21:46
mugsiepublishing 2 OpenStack (image|orchestration|server) APIs from the same foundation is not OK21:46
dansmithfungi: I, at least, see this as a very dangerous way that wind river/intel would have somewhat forced our hand on things by taking the easy way out initially, and then a subsequent easy way out of making their changes our problem by heading this way21:46
dtroyerso what if it had been the TC's idea to "adopt" a project to bring it into the fold?  would it be different if then?21:47
smcginnisKind of like showing at a keynote something that you just rewrote and saying it's better than what everyone is there for.21:47
dtroyerdansmith: the easy way out is to not open it up, honestly. the lat 6 months have shown me that first hand21:47
fungii concur, but it doesn't change my opinion on the options that i see. the alternative ways this can play out still seem worse to me21:47
dtroyersmcginnis: I xan neither confirm not deny my agreement on that…21:48
dtroyerit still pisses me off21:48
dansmithdtroyer: depends on what the desired end goal is, I was assuming the end goal is getting things upstream, not to customers21:48
dansmithlucky for all of you, I'm about to get on a plane with no wifi :)21:48
dtroyerit is both.  get the code upstream, serve the community, sell to customers, all the usual stuff21:49
dtroyerthere will be changes that can not come upstream, even if it just rbanding21:49
dtroyersome of them could have been better thought out, many of them were done in kilo and liberty and have not gone away yet21:49
dtroyerfly safe dan21:50
fungisee you soon dansmith!21:50
EmilienMI like the intent, dtroyer22:02
EmilienMcould we add that topic on maybe?22:03
EmilienMmaybe capture a bit of what was said this week, so we have food for thoughts this week when we meet in merson22:03
dtroyerI'll be there either way22:04
dtroyerTheJulia: love the shades!22:04
TheJuliadtroyer: thanks, migraines are fun \o/22:05
dtroyeromg, you are on the wrong side of the room for that!22:06
TheJuliai know :(22:06
TheJuliaI should have moved once it started to set in, but *shrugs*22:06
fungithere's an open seat between anni and zaneb22:06
TheJuliathey raised all the blinds after the session started, I guess they only wanted to cut down on sunrise/early morning light22:06
TheJuliaI think at this point it doesn't really matter.22:07
fungilooks like there might be an open seat next to spotz too22:07
fungiahh, well bummer about the headache22:07
ttxPersonally I'm happy that (1) that code is open sourced, (2) that they are happy doing it on our project infra, and (3) that they want to upstream all the delta. We should facilitate that upstreaming rather than making it more difficult...22:23
ttxand (4) create an open collaboration on that going forward, too22:23
fungii've also got a (5) that they decided openstack was a basis worth building that on rather than rewriting their edge suite from scratch22:24
mriedemthey can easily follow the same upstream process everyone else does, by proposing their changes22:24
fungiand sounds like they will22:24
mriedembut they will not get prioritized any higher than anything else simply because they did a big code dump22:25
fungii wouldn't expect their changes to be prioritized higher than anyone else's, and i hope they don't expect that either22:26
* fungi thinks back to all our early projects (besides swift) which also started out as forks of nova22:27
mriedemcinder was nova-volume yeah?22:29
mriedemsplit out / decomp isn't the same as a fork imo22:29
fungisure, functionality was able to get deleted from nova afterward22:29
fungiwhich is again not really the same at this case22:29
fungier, not really the same _as_ this case22:30
fungiso anyway, as the openstack tc we have the opportunity to tell the openstack foundation either that we acknowledge this is a non-ideal situation but we're not opposed to them managing it, or that we're opposed to it and would rather they tell the starlingx team to go somewhere else22:33
fungithe whole community has the opportunity to express opinions on these sorts of choices really, though the tc can as a body draft a resolution or something if we feel strongly about it22:34
fungiwe're not being asked to govern it, we're just being asked to coexist with it22:35
*** lbragstad has joined #openstack-tc22:59
dtroyermriedem: we don't expect special treatment, was planning to spec/blueprint the features, and submit bugs.  I couldn't do that before yesterday…23:01
ttxthe idea is to facilitate convergence -- those patches should not get priority just because they are part of the stx delta23:03
*** diablo_rojo has joined #openstack-tc23:10
*** edmondsw has joined #openstack-tc23:13
mriedemdtroyer: ack23:13
mriedemregarding "we're not being asked to govern it, we're just being asked to coexist with it" i will need to call saul23:14
dtroyersorry, I already called him, he'll have to recuse23:16
*** edmondsw has quit IRC23:17
*** diablo_rojo has quit IRC23:19
*** pabelanger has quit IRC23:38
*** pabelanger has joined #openstack-tc23:38
*** gcb has quit IRC23:46
*** lbragstad has quit IRC23:54

Generated by 2.15.3 by Marius Gedminas - find it at!