Tuesday, 2018-08-07

fungiseems like it ought to be possible for glance to have a configuration option to report to clients what image formats the deployment accepts and which ones are preferred? but it's a naive assumption on my part as there's almost certainly a reason why it doesn't have that already00:13
*** harlowja has quit IRC00:26
mriedemalso, what is the thing that actually times out?01:14
mriedemthe user token?01:14
mriedembecause we've had service user tokens since pike01:14
*** mriedem has quit IRC01:15
*** ricolin has joined #openstack-tc01:29
*** lbragstad has quit IRC02:18
*** rosmaita has quit IRC03:13
*** diablo_rojo has quit IRC03:25
*** jaypipes has quit IRC04:02
*** jaypipes has joined #openstack-tc04:02
*** e0ne has joined #openstack-tc05:00
*** jaosorior has quit IRC05:26
*** e0ne has quit IRC05:58
*** e0ne has joined #openstack-tc06:02
*** jaosorior has joined #openstack-tc06:05
*** e0ne has quit IRC07:02
*** e0ne has joined #openstack-tc07:35
*** e0ne has quit IRC07:41
*** tosky has joined #openstack-tc07:42
*** jpich has joined #openstack-tc07:45
*** jaosorior has quit IRC07:49
*** e0ne has joined #openstack-tc07:53
*** e0ne has quit IRC07:53
*** jaosorior has joined #openstack-tc08:02
*** cdent has joined #openstack-tc08:14
ttxdhellmann: re Storlets cmurphy had been in contact with them, so I assumed she was my backup there and covered. But I see now you're my teammate on this one08:28
cmurphyttx: sorry, should have been more clear on that, I was sort of ambushed by the blazar ptl to answer questions for masakari and storlets08:29
ttxheh08:32
ttxI'll reach out today08:33
ttxtc-members , office hour is upon us09:00
* ttx looks up status for leaderless projects09:01
ttxhttps://etherpad.openstack.org/p/stein-leaderless09:01
*** jaosorior has quit IRC09:02
cmurphyhello09:02
cmurphyi'm somewhat caught up on scrollback and email09:03
cdentpaul's message to claudiub got a response. Summary is: Essentially he lost track of time and is  interested in still being PTL and making sure things happen09:03
cdentI'll update the etherpad09:03
ttxyes I'm updating a few entries too09:04
ttxIIRC we got a volunteer for LOCI09:06
ttxso that leaves Freezer and Searchlight09:06
ttxwhich coincidentally have been formally removed from Rocky due to missing most release deadlines this cycle09:07
ttxI'm a bit torn on this, but to be consistent, I'd support their team removal09:07
cdentFor those projects where we've had to volunteers to fill the gaps, what do we need to tell them to do09:07
cdentI think removal is the right thing as well09:07
EmilienMhola09:07
* cdent checks the time09:08
ttxyou mean "no" volunteers?09:08
cmurphyEmilienM: are you in France?09:08
cdentttx no, I mean someone has volunteered so how do we make it official09:08
EmilienMno, I'm just waking up early 😊09:08
ttxcdent: Ask them to propose a change to the governance repo09:08
cdentttx my comments above were two separate lines of thought09:09
ttxThere are really two types of cases. "Whoops my alarm did not go off", and "Oh I really don't want this project to die, let me revive it"09:10
cdentttx: if they are already the PTL is there anything to do?09:10
ttxRefstack being a third corner case scenario09:10
cdent(thinking winstackers here)09:11
ttxcdent: if they are already the PTL, we should ask them to file a change to the election repo, so that we have something to record our agreement on09:11
cdent✔09:11
ttx(see http://git.openstack.org/cgit/openstack/election/tree/doc/source/results/queens/ptl.yaml#n288 for precedent09:11
ttxthat is what we asked Omer to do for Dragonflow09:11
ttxIn the "Oh I really don't want this project to die, let me revive it" case, we have Trove on one side, where the current team is still around, but a new team is stepping up, and elections fall in the middle of that transition. And we have two inactive projects (Freezer, Searchlight) which recently fall under the line of activity required to be part of the release, and where some users would rather not09:13
ttxhave it die, but it's a rather long shot to revive them09:13
* ttx likes to categorize things to rationalize his thinking09:14
cmurphydoes searchlight fall into the dying category or into the maintenance mode/feature complete category?09:14
cdentnot having a PTL and not being official don't definitely mean death09:14
ttxcmurphy: I thought it was the latter, but lack of relese requests (which is basically the bare minimum to stay in the release) tend to point to the former09:15
ttxIt's ok to be low activity, but we still need at least one person to care for the project to be included in the release09:15
cmurphyif they've had very few commits maybe they weren't aware they should still be releasing09:16
ttxand by care I mean, care enough to submit 2 or 3 changes to a YAML file09:16
ttxcmurphy: then they also don't read the multiple warnings that were sent09:16
ttxcmurphy: add to that the fact that nobody proposed to be PTL09:17
cmurphyyeah it doesn't look good09:17
ttxsigns point to "dying"09:17
ttxWe should make it clear that making it unofficial is not killing it -- it's just stopping to associate the official openstack wrapping around it, with all the contraints it creates09:19
ttxand if the project is picked up and has an active team again, it can also re-apply easily09:19
ttxif anything it might wake up its few users09:20
ttxI wish those would step up /before/ we have to take action, but...09:20
ttx"someone else will do the work for me" only goes so far09:21
ttxHaving two projects for backup of cloud resources always sounded overkill to me09:22
ttxheck, "backup of cloud resources" sounds weird to me -- but I was happy to give it a chance to prove me wrong09:23
cmurphywhat's the other one? i always thought freezer was the backup service09:23
ttxKarbor09:23
cdentSince deciding if something is in or out is one of the few powers we have, making something out is a good way to draw attention09:24
ttxFreezer is a wrapper API on top of disaster/restore solutions09:24
ttxKarbor is an openstack-aware thing that backs up OpenStack resources09:24
ttxI've been pushing those two to merge for a few years09:24
ttxFreezer has been mostly run by Saad in his free time since HPE dropped the project09:26
ttxKarbor is more active, developed by a group of APAC contributors09:27
ttxThe reason they could not merge is more due to them only crossing path at the PTG and then not having that much time to dedicate to merging09:27
ttxhmm, Karbor looks pretty deaad too in Rocky09:28
ttxWe should ask the top contributor, a guy named Doug Hellmann09:29
ttxI wish the default rule when there is no formal nomination would have been to give PTLship to the top contributor. Doug would be pretty busy :)09:32
cmurphyheh09:32
eumel8ttx: there are similar UI projects like freezer-web-ui and karbor-dashboard09:46
cmurphyit seems like freezer is in basically the same boat as trove based on https://review.openstack.org/#/c/588645/ there are volunteers to step up so it doesn't seem so dire09:52
* cmurphy sends an internal email to probe about freezer investment10:01
*** jaosorior has joined #openstack-tc10:46
*** ricolin has quit IRC10:58
ttxcmurphy: one (key) difference is that with trove the previous team is still around and publishing a release for rocky11:17
ttxIf we keep freezer "in" and it does not release for rocky that creates a bit of a precedent that "skipping" releases is ok11:17
cmurphythat's true11:18
ttxSo maybe ask them to file early in Stein (before milestone-2) for reinclusion is the right approach11:18
ttxthat way they can be back in Stein if that's really saved11:18
cdentI'm seeing increasing discussion of "k8s and kubevirt are the future, why bother with OpenStack?". This is obviously oversimplified, but do we need to be thinking about it? dims?11:25
cmurphywhy do you think it's increasing?11:28
cmurphymy impression is it's a consistent attitude from people who think that infrastructure just exists by magic11:29
cdentcmurphy: it's sort of a finger on the pulse thing. Increasing mentions in twitter, comments around the world.11:30
cdentThe statement might be more complete if it where s/OpenStack/Nova/11:30
cdentso things like tripleo doing baremetal deployments with ironic and metalsmith ( https://github.com/openstack/metalsmith ) to lay in some baremetal hosts for k8s, upon which kubevirt happes11:32
* cdent is speculating11:32
cdentI'm not suggesting that it is a correct attitude, or anything like that, merely that it is happening11:33
cdentand as much as we would prefer people to rationally evaluate the world, hype and buzz matter :(11:33
cmurphyhow would we go about fixing it? to me, the statement "{OpenStack,Nova} is unnecessary" is factually wrong, is it our problem to reeducate people on that?11:38
cdentIs it factually wrong? Why not orechestrate ironic (without nova) to spin up a large k8s cluster on baremetal and run kubevirt?11:44
cdent(I don't know, I'm asking)11:44
jrollcdent: the only reasons I can come up with are use-case-specific or opinions (features in nova but not kubevirt, "one compute API for VMs and metal is good", etc)11:50
jrollI guess there's probably an argument that nova is more stable11:50
cdentI wonder if we should be more embracing and encouraging instead of defending?11:52
jrollI thikn the defending comes from the comments that say "openstack is dead, k8s is the future"11:53
jrollhard to encourage that :P11:54
TheJuliattx: I would love to see us place value on not releasing something every cycle if there have been no changes or is no need. Right now, across the community we enforce a pattern that may have made sense four years ago... but now perhaps not as much. Granted that makes it more difficult to make a marketable product with stickers on it and everything, but it should really be about how we sell the community and the11:55
TheJuliaperspective, not a versioned release11:55
TheJulia++ for conveying use cases more clearly11:56
cdent("value on not releasing something every cycle if there have been no changes or is no need")++11:57
*** jaosorior has quit IRC11:59
*** edmondsw has joined #openstack-tc12:04
cmurphynova (with keystone) enables self-service access to infrastructure without implying the need for elevated access to baremetal servers, so i guess if kubevirt supports that kind of multitenancy and can work with keystone then it could fill a similar need12:05
TheJuliajroll: I think part of the conundrum (no, nothing happened 7 days ago), is that when one is attempting to sell a product, it becomes a very easy thing to say that something is dead when that statement should be "[my interest][in selling] openstack is dead, k8s is the future [because it is the new kid on the block]"12:15
jrollTheJulia: of course :)12:16
openstackgerritJean-Philippe Evrard proposed openstack/governance master: Split OpenStack-Ansible deliverable  https://review.openstack.org/58944612:17
TheJuliaYou can't really fight that without somehow wow-ing.. which is why I resist the occasional calls to stop feature work because stopping interrupts the pipeline, disenfranchises, and ultimately is self-defeating.12:17
*** jaosorior has joined #openstack-tc12:18
*** jaosorior has quit IRC12:27
dimscdent : you are hitting the sweet spot ... cluster-api is clearly looking for a way to do baremetal easily. which could be what you suggested with ironic.12:32
dimscdent : the other trend here is, folks are not into large clusters. they build small 5-10 node clusters (bare metal or public cloud) for applications. may be slightly bigger ones for devops scenarios12:33
dimscdent : so things are easily to teardown and move to a fresh cluster (instead of upgrading for example)12:34
dimscdent : for application workloads that need existing VM images, yes, kubevirt seems to be gaining steam12:35
dimsTheJulia : jroll : the cluster-api is a declarative way to essentially tell a seed k8s to create new clusters. we have support in a new driver that calls nova to create vm(s) essentially - https://github.com/kubernetes-sigs/cluster-api-provider-openstack. would love to see someone experiment with nova+ironic or ironic directly if there is interest in our community here. The kubernetes folks working on this are definitely interested12:39
dims in that kind of work and no one has stepped up yet.12:39
*** e0ne has joined #openstack-tc12:40
dimsthere's a better picture here - https://github.com/kubernetes-sigs/cluster-api12:41
jrolldims: definitely on my radar already :)12:41
*** jaosorior has joined #openstack-tc12:42
TheJuliaI feel like that might be a good CI test to have...12:43
dims++ jroll TheJulia12:50
*** tellesnobrega has quit IRC12:50
cdentthanks dims12:51
TheJuliaPerhaps it should be a goal for ironic this coming cycle to reduce our pure dsvm test every driver/combination of everything framework, and pare that down while adding "non-traditional integration focused jobs"12:52
*** tellesnobrega has joined #openstack-tc12:54
*** dklyle has quit IRC12:59
ttxTheJulia: re: not releasing things that are not evolving -- beyond releasing, I think it's important to have at least one person/organization caring for the presence of that component in "OpenStack". We need someone to cover for critical bugs, vulnerability issues, or basic evolution of the runtime environment. If there is not a single person/organization willing to cover for that, I'd argue that that13:05
ttxcomponent can exist, but outside of the "official release" that we associate the name "openStack" with13:05
ttxit's a baseline for me13:05
ttxNow a component can totally be feature-complete, but I'd argue one person still needs to sign up to cover for its presence in "OpenStack"13:06
ttxThat is the situation of most of our libraries, for example13:07
TheJuliattx: I agree with your statement13:09
cdentttx: I think that's well understood. I think the point is good though: stability and feature completeness is something we should strive for and celebrate13:09
cdenthasn't had a release for N years + people still use it == great success13:09
ttxtotally. We could even have a team that sheperds (sp?) those in perpetuity, a bit like the Oslo PTL pushes releases and covers for completed libraries13:09
ttxIt;'s ok to be feature complete. It's not ok to be abandoned.13:10
TheJuliathe key is responsibility and point of contact... and so I feel like a shepherding team might be good, but may not fit all cases.13:10
* TheJulia feels consensus13:10
ttxAnd not being able to push 2 or 3 release requests per cycle and apply for PTl is, to me, a sign of "abandoned"13:11
ttxsince it's about 15-min worth of work every 6 months.13:11
*** lbragstad has joined #openstack-tc13:12
TheJuliaI guess I have an issue with the version number needlessly being incremented in those cases, but you raise a very valid point that it does become a good measure13:12
ttxre: Kubevirt -- the way I see it, people deploy small Kubernetes clusters and then realize that they need to run VMs, and that's a shortcut for that13:12
TheJulia"Hi, this is my official check-in commit, I'm still alive!"13:12
ttxheartbeat :)13:12
ttxOpenStack is driven by complexity/size of needs... If we want to be beneath every K8s cluster on Earth we'll have to simplify deployment dramatically13:13
ttxIf you have simple/small needs then it tends to be overkill13:14
*** mriedem has joined #openstack-tc13:16
TheJulia++, different scale of use13:18
scasfrom personal experience, bootstrapping k8s is an exercise in observing the struggle of the human condition. by comparison, the relatively mature tooling in my corner can slap openstack on my laptop in about the time it takes to cook a pizza and burn one's mouth13:23
scasi've also observed that my rehoming efforts for the chef entry point have garnered a slight bit of interest in that i've woken up to them all reviewed in some capacity13:26
* TheJulia wonders if we could somehow get that down to sandwich making ;)13:31
TheJuliascas: yeah, there is something to be said for seeing and interacting with active people to know that software is useful and that there are people there to help13:32
scasTheJulia: the interesting observation that i've made is that some of it seems to be coming from our 99cloud friends, to harken back to the gfw discussion13:34
fungimriedem: following up on the question from last night, what times out is that glance indicates the image was uploaded so we go to nova boot an instance from it right away but the compute nodes take so long to convert it to the format they're going to use that we consider the boot to have failed (not sure if nova reports failure in that case or we just give up waiting on the client end)13:50
zanebthe 'lots of small clusters' thing is I think a result of k8s being designed around a single-tenant model13:51
zanebas k8s gets more multi-tenant support, I'd expect to see more people installing one big k8s cluster and running all their apps on it instead of one per app13:51
mriedemfungi: ok13:52
ttxzaneb: totally13:52
ttxalthough one might argue that it's really feature creep and that would pave the way for the next thing13:53
ttx(multitenant support for a single k8s cluster)13:53
* fungi is catching up on office hour scrollback13:53
zanebthey have a multitenancy SIG. it's only a matter of time13:54
fungii think the rule ought to be "if dhellmann is the top contributor this project is likely dead" (since more often than not that's what it seems to mean)13:54
ttxzaneb: not everyone is happy about that SIG :)13:54
zaneband kubevirt is getting better, although it's not ready for primetime yet aiui13:54
* ttx has seen the amount of "what is kubernetes" discussions jump up lately13:55
dhellmannfungi : I'm not sure I like the phrasing there, but I tend to agree with the sentiment13:57
ttxfuzzy scope is a natural consequence of large open collaborations13:57
zanebthe future of Neutron and Cinder seems assured, since networking and storage vendors won't want to write a whole new abstraction layer when they have a perfectly good one13:57
ttxdhellmann is also the top contributor to the release team.13:57
zanebIronic also seems safe13:57
dhellmanna sure sign that openstack is dead13:57
zanebbut it's not at all clear that there won't ever be viable alternatives to Nova, and everything else in OpenStack pretty much has its cart hitched to Nova13:58
ttxzaneb: the storage k8s SIG people might disagree with that :)13:58
dhellmanntc-members: does anyone have any background on the comments in https://review.openstack.org/588358 about us hosting a fork of ryu?13:59
ttxdhellmann: nothing beyond what's on the review. Ryu is abandoned upstream and we need to maintain some ryu-lib stuff that neutron depends on ?14:00
dhellmannah, if it's abandoned that's one thing14:00
ttxhttps://blueprints.launchpad.net/neutron/+spec/ryu-framework-maintenace-transition14:01
ttxhttps://etherpad.openstack.org/p/neutron-ryu-future-plans14:01
smcginnisThere were some incompatibility issues too with ryu. I think this is the result of trying to sort that out.14:01
ttxthat etherpad gives some insight on the discussion that happened14:02
ttxThe trick is that they depend on parts of Ryu, rather than the whole project14:04
ttx"select components we want to use: ofproto (1.0 and 1.3 only), bgp, part of RyuApp stuff, ryu Event stuff"14:04
fungifwiw, yesterday i temporarily blocked the corresponding project-config dependency to create that repo until there's consensus on what it should be named14:04
ttxfungi: ideally it would be split into multiple libraries, but i can see how that's a second stage and they need a ryu pure fork first14:05
dhellmannI wonder if "os-ryu" is a good name for the new thing.14:06
smcginnisIf they only need parts but not all, that does sound like it maybe has too much all in one library and should be split out.14:06
dhellmannbased on my experience with oslo, that can take quite a bit of work14:07
fungiright, the biggest concern seems to be in avoiding the impression that a) it's a continuation of ryu by the same contributors in a new place and b) that it will retain any sort of backward compatibility vs dropping all the bits neutron doesn't need and changing the things which it needs changed in disruptive ways14:07
dhellmannall-in-one code bases tend to become rather tightly coupled14:07
* dtroyer notices that https://github.com/starlingx-staging/stx-ryu is a thing…14:07
ttxhaha14:07
dhellmanndoes someone want to take the point on expressing our concerns, so it's not a big pile-on job?14:09
dimsdtroyer : did you get a chance to peek at mriedem 's notes on stx/nova?14:21
dtroyerdims: I have, spent most of yesterday trying to match that up with the actual commits.14:22
dimscool!14:23
dimsdtroyer : as mriedem must have mentioned ... bunch of us heading to hq end of this week14:24
dtroyerdims: he did mention the work was for a product group, didn't know y'all were flying…  it's a big company, I was wondering if that might have been the same product group that is/was involved in akraino, guessing not14:26
dimsdtroyer : dunno. we generally get asked about everything that's happening and what may be relevant to work on next14:27
* dtroyer is familiar with that feeling14:27
dims:)14:27
fungidhellmann: asking about expressing our concerns on the ryu fork addition? i haven't looked at it again today but those concerns seemed to already be raised by other neutron contributors so i was hesitant to chip in and let them come to some consensus on how they wanted to do it first14:30
dhellmannfungi : yes, ok, if the neutron team is already dealing with it that' sfine14:30
dhellmannas long as it's being raised14:30
fungibest not to spend our influence when it's not needed ;)14:30
smcginnisWe should probably ask that the TC be updated on how the discussion goes though.14:31
fungiif it seems to start veering off the rails i'm happy to comment14:31
dhellmannsmcginnis : good point14:31
fungiyeah, i expect them to at least follow up in the governance change with outcomes14:32
fungirather, i mean, we need to expect that of them (and not progress on that proposal ourselves until they do)14:32
*** dklyle has joined #openstack-tc14:33
*** hongbin has joined #openstack-tc14:38
*** e0ne has quit IRC14:39
*** annabelleB has joined #openstack-tc14:46
*** rosmaita has joined #openstack-tc14:57
openstackgerritMerged openstack/governance master: add soft validation of extra-atcs  https://review.openstack.org/58858515:01
*** jaosorior has quit IRC15:01
*** mriedem is now known as mriedem_afk15:06
cdentI found the email address of someone who was a maintainer for PasteDeploy for a while, so sent that person some email. Also sent out a 'halp' on twitter.15:38
*** mriedem_afk has quit IRC16:11
*** jaypipes_ has joined #openstack-tc16:16
cdentthat email came back quickly with an "I'm not involved anymore, don't know what's up"16:16
*** jaypipes has quit IRC16:17
*** jaypipes_ has quit IRC16:17
*** annabelleB has quit IRC16:17
*** annabelleB has joined #openstack-tc16:18
*** e0ne has joined #openstack-tc16:18
dhellmannit sounds like we need someone to work out a plan for what to do16:19
cdentI've asked that same person if he has any suggestions of what to do or contacts and what he thinks the response to a impromptu fork would be16:21
cdentAssuming we could get the pypi gang to let us jump on the namespace, I would think a fork wouldn't be too bad16:21
*** jpich has quit IRC16:27
*** jaypipes has joined #openstack-tc16:33
smcginnisI think I've heard that pypi process can be quite long.16:34
smcginnisIf we can get an existing owner to add us then I think that would be best all around.16:34
smcginnisIf even possible.16:34
* cdent is working on it16:35
cdentI seem to be in contact with the most recent maintainer of PasteDeploy (but not Paste) and when he gets to his laptop he's going to do some investigating about who to contact or what to do.16:38
smcginnis\o/16:39
*** tosky has quit IRC16:57
ttxwe have a formal PTL candidate now for Freezer17:00
ttxhttps://review.openstack.org/58864517:00
smcginnisHas anyone checked if they are technically qualifed. I know that doesn't actually matter with an appointed PTL, but would be nice to know if they've actually been involved at all.17:03
mugsiesmcginnis: they are not17:12
mugsietacker seems to their main focus17:12
dhellmannfreezer doesn't even show up on stackalytics17:14
dhellmannI see no contributions or reviews from Trinh Nguyen in freezer in the last year17:20
*** e0ne has quit IRC17:20
dhellmannthat's not a blocker from taking over the project, but may be reason to say we want it moved out of governance first17:20
dhellmannI guess it makes the case somewhat similar to trove's17:20
*** e0ne has joined #openstack-tc17:21
*** e0ne has quit IRC17:22
mugsieyeah, but in troves case the new ptl has at least proposed patches to the project17:24
*** ricolin has joined #openstack-tc17:30
*** harlowja has joined #openstack-tc17:31
*** annabelleB has quit IRC17:38
*** harlowja has quit IRC17:43
*** annabelleB has joined #openstack-tc17:45
*** annabelleB has quit IRC17:55
*** annabelleB has joined #openstack-tc18:01
*** e0ne has joined #openstack-tc18:04
*** diablo_rojo has joined #openstack-tc18:13
*** AlanClark has joined #openstack-tc18:21
fungiworth noting though, from an order of operations standpoint, if the existing maintainers are missing in action we can appoint a ptl and hand over control since it's still an official project18:24
fungiif we remove them from governance first, then we (for the most part) lose the authority to decide such matters18:24
fungienough of a technicality probably nobody would question us doing it in the latter order, but it still seems backwards to me18:26
dhellmanngiven that there isn't anyone else around to approve of a handover, that's a good point18:26
*** ricolin has quit IRC18:27
fungialso, in reflection i'm starting to question whether just cutting an official project loose when it has no leadership any longer is a good idea. how does someone who wants to maintain it and maybe reapply for official status get control later? maybe we should be retiring searchlight if nobody's going to work on it and we're giving up authority to pass it along to someone who might?18:29
fungii suppose as long as at least one person in the relevant groups mentioned in the gerrit acls is still around and agreeable to adding new folks to those groups, then they can manage such a transition that way18:30
dhellmannyeah, that's a fair point. we should at least document the idea that we reserve the right to grant commit access to the repo after it is dropped from governance18:31
fungii could get behind that. what document should it go in?18:32
dhellmannto allow us to resolve that situation18:32
dhellmannhmm18:32
dhellmannmaybe just a resolution?18:32
dhellmannI don't think we have anything formal that talks about dropping projects yet18:32
dhellmannwe have the list of requirements for new projects, but nothing for old projects18:32
fungii'll see what i can come up with18:33
dhellmannthanks18:33
fungibasically it means we have (at least) two classes of removals. one prompted by an active team which wishes to do their work outside tc oversight, and one prompted by abandonment. we need to be able to classify them if we want to be able to say that we retain control in only the latter case and not the former18:35
fungithere's a fuzzy middle ground too, e.g. fuel18:35
dhellmannthere's also the case where a repo is removed from governance but the team remains18:36
fungipeople are still trying to use it and get surprised that it's not viable any longer (because after they left official project status they then fairly rapidly stopped developing it further)18:36
dhellmannI'm not sure what makes the fuel case special?18:36
dhellmannah18:36
smcginnisShould we have a process where we just mark these as retired but still under governance?18:36
dhellmannperhaps we should reserve the right to more fully retire things that used to be under governance, too18:37
fungithat might be a food way to frame it18:37
fungier, a good way18:37
fungii must have skipped lunch today ;)18:37
dhellmannstep 1 is just to move it to legacy, step 2 is to retire it after some delay18:37
smcginnisfungi: :)18:38
dhellmannheh18:38
mugsieplaying devils advocate, but would that not fall under -infra / winterscale (what ever that team becomes) ?18:38
smcginnismugsie: Could you elaborate?18:38
cdenti hear wintermute everytime someone says winterscale18:38
mugsieif we remove them from governance, it would be up to the team hosting the code (like the pypi example from above)18:38
dhellmannmugsie : we could play it that way, but it seems more responsible to say "this used to be ours, we'll deal with future ownership transitions and retirement"18:39
mugsieyeah, thats true.18:40
dhellmannit's one less thing for the winterscale team to have to deal with18:40
mugsieFor cue, we totally retired it afaik. but it didn't have working gates or anything18:42
dhellmannyeah, this is another one of those cases where we need to set up rules that allow us to do what is needed without prescribing that in advance with too much precision, so we have room to use judgement18:48
*** openstackgerrit has quit IRC18:49
fungiright, i'd like to reserve asking the winterscale team to make ambiguous judgement calls which are entirely preventable with a little preparation18:49
fungier, s/reserve/avoid/18:50
fungireserve the need to ask them to make ambiguous judgement calls only in situations we can't easily predict and sidestep18:50
dhellmannright18:50
fungiwinterscale is going to need a policy on resource takeovers, but it's likely to end up being something slow and intentionally painful (a la pep 541)18:52
dhellmannas long as it defers to former owners it should be easy to fit whatever we come up with into that process18:53
dhellmanni.e., the response for something that used to be governed would be "go ask the tc"18:53
smcginnisIn case there's anyone else there scratching their heads trying to remember what winterscale is - http://lists.openstack.org/pipermail/openstack-dev/2018-May/130896.html18:54
*** annabelleB has quit IRC18:54
* fungi thinks we _might_ be very close to finally being able to publicly discuss a great candidate for the actual name of that. fingers crossed18:55
dhellmannthundersnow?18:56
* fungi can neither confirm nor deny18:58
*** diablo_rojo has quit IRC19:02
smcginnisthundercats19:06
*** mriedem has joined #openstack-tc19:24
fungihow'd you guess?19:30
fungii was pulling for voltron, but still not bad19:30
*** e0ne has quit IRC19:32
*** cdent has quit IRC19:42
*** diablo_rojo has joined #openstack-tc20:29
*** annabelleB has joined #openstack-tc20:30
*** AlanClark has quit IRC20:41
-openstackstatus- NOTICE: Due to a bug, Zuul has been unable to report on cherry-picked changes over the last 24 hours. This has now been fixed; if you encounter a cherry-picked change missing its results (or was unable to merge), please recheck now.20:43
*** edmondsw has quit IRC21:29
*** rosmaita has quit IRC22:11
*** hongbin has quit IRC22:39
*** diablo_rojo has quit IRC22:41
*** annabelleB has quit IRC22:41
*** edmondsw has joined #openstack-tc22:54
*** annabelleB has joined #openstack-tc22:58
*** edmondsw has quit IRC22:59

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!