| fungi | seems 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 already | 00:13 |
|---|---|---|
| *** harlowja has quit IRC | 00:26 | |
| mriedem | also, what is the thing that actually times out? | 01:14 |
| mriedem | the user token? | 01:14 |
| mriedem | because we've had service user tokens since pike | 01:14 |
| *** mriedem has quit IRC | 01:15 | |
| *** ricolin has joined #openstack-tc | 01:29 | |
| *** lbragstad has quit IRC | 02:18 | |
| *** rosmaita has quit IRC | 03:13 | |
| *** diablo_rojo has quit IRC | 03:25 | |
| *** jaypipes has quit IRC | 04:02 | |
| *** jaypipes has joined #openstack-tc | 04:02 | |
| *** e0ne has joined #openstack-tc | 05:00 | |
| *** jaosorior has quit IRC | 05:26 | |
| *** e0ne has quit IRC | 05:58 | |
| *** e0ne has joined #openstack-tc | 06:02 | |
| *** jaosorior has joined #openstack-tc | 06:05 | |
| *** e0ne has quit IRC | 07:02 | |
| *** e0ne has joined #openstack-tc | 07:35 | |
| *** e0ne has quit IRC | 07:41 | |
| *** tosky has joined #openstack-tc | 07:42 | |
| *** jpich has joined #openstack-tc | 07:45 | |
| *** jaosorior has quit IRC | 07:49 | |
| *** e0ne has joined #openstack-tc | 07:53 | |
| *** e0ne has quit IRC | 07:53 | |
| *** jaosorior has joined #openstack-tc | 08:02 | |
| *** cdent has joined #openstack-tc | 08:14 | |
| ttx | dhellmann: 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 one | 08:28 |
| cmurphy | ttx: sorry, should have been more clear on that, I was sort of ambushed by the blazar ptl to answer questions for masakari and storlets | 08:29 |
| ttx | heh | 08:32 |
| ttx | I'll reach out today | 08:33 |
| ttx | tc-members , office hour is upon us | 09:00 |
| * ttx looks up status for leaderless projects | 09:01 | |
| ttx | https://etherpad.openstack.org/p/stein-leaderless | 09:01 |
| *** jaosorior has quit IRC | 09:02 | |
| cmurphy | hello | 09:02 |
| cmurphy | i'm somewhat caught up on scrollback and email | 09:03 |
| cdent | paul'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 happen | 09:03 |
| cdent | I'll update the etherpad | 09:03 |
| ttx | yes I'm updating a few entries too | 09:04 |
| ttx | IIRC we got a volunteer for LOCI | 09:06 |
| ttx | so that leaves Freezer and Searchlight | 09:06 |
| ttx | which coincidentally have been formally removed from Rocky due to missing most release deadlines this cycle | 09:07 |
| ttx | I'm a bit torn on this, but to be consistent, I'd support their team removal | 09:07 |
| cdent | For those projects where we've had to volunteers to fill the gaps, what do we need to tell them to do | 09:07 |
| cdent | I think removal is the right thing as well | 09:07 |
| EmilienM | hola | 09:07 |
| * cdent checks the time | 09:08 | |
| ttx | you mean "no" volunteers? | 09:08 |
| cmurphy | EmilienM: are you in France? | 09:08 |
| cdent | ttx no, I mean someone has volunteered so how do we make it official | 09:08 |
| EmilienM | no, I'm just waking up early 😊 | 09:08 |
| ttx | cdent: Ask them to propose a change to the governance repo | 09:08 |
| cdent | ttx my comments above were two separate lines of thought | 09:09 |
| ttx | There 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 |
| cdent | ttx: if they are already the PTL is there anything to do? | 09:10 |
| ttx | Refstack being a third corner case scenario | 09:10 |
| cdent | (thinking winstackers here) | 09:11 |
| ttx | cdent: 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 on | 09:11 |
| cdent | ✔ | 09:11 |
| ttx | (see http://git.openstack.org/cgit/openstack/election/tree/doc/source/results/queens/ptl.yaml#n288 for precedent | 09:11 |
| ttx | that is what we asked Omer to do for Dragonflow | 09:11 |
| ttx | In 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 not | 09:13 |
| ttx | have it die, but it's a rather long shot to revive them | 09:13 |
| * ttx likes to categorize things to rationalize his thinking | 09:14 | |
| cmurphy | does searchlight fall into the dying category or into the maintenance mode/feature complete category? | 09:14 |
| cdent | not having a PTL and not being official don't definitely mean death | 09:14 |
| ttx | cmurphy: 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 former | 09:15 |
| ttx | It's ok to be low activity, but we still need at least one person to care for the project to be included in the release | 09:15 |
| cmurphy | if they've had very few commits maybe they weren't aware they should still be releasing | 09:16 |
| ttx | and by care I mean, care enough to submit 2 or 3 changes to a YAML file | 09:16 |
| ttx | cmurphy: then they also don't read the multiple warnings that were sent | 09:16 |
| ttx | cmurphy: add to that the fact that nobody proposed to be PTL | 09:17 |
| cmurphy | yeah it doesn't look good | 09:17 |
| ttx | signs point to "dying" | 09:17 |
| ttx | We 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 creates | 09:19 |
| ttx | and if the project is picked up and has an active team again, it can also re-apply easily | 09:19 |
| ttx | if anything it might wake up its few users | 09:20 |
| ttx | I 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 far | 09:21 |
| ttx | Having two projects for backup of cloud resources always sounded overkill to me | 09:22 |
| ttx | heck, "backup of cloud resources" sounds weird to me -- but I was happy to give it a chance to prove me wrong | 09:23 |
| cmurphy | what's the other one? i always thought freezer was the backup service | 09:23 |
| ttx | Karbor | 09:23 |
| cdent | Since deciding if something is in or out is one of the few powers we have, making something out is a good way to draw attention | 09:24 |
| ttx | Freezer is a wrapper API on top of disaster/restore solutions | 09:24 |
| ttx | Karbor is an openstack-aware thing that backs up OpenStack resources | 09:24 |
| ttx | I've been pushing those two to merge for a few years | 09:24 |
| ttx | Freezer has been mostly run by Saad in his free time since HPE dropped the project | 09:26 |
| ttx | Karbor is more active, developed by a group of APAC contributors | 09:27 |
| ttx | The 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 merging | 09:27 |
| ttx | hmm, Karbor looks pretty deaad too in Rocky | 09:28 |
| ttx | We should ask the top contributor, a guy named Doug Hellmann | 09:29 |
| ttx | I 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 |
| cmurphy | heh | 09:32 |
| eumel8 | ttx: there are similar UI projects like freezer-web-ui and karbor-dashboard | 09:46 |
| cmurphy | it 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 dire | 09:52 |
| * cmurphy sends an internal email to probe about freezer investment | 10:01 | |
| *** jaosorior has joined #openstack-tc | 10:46 | |
| *** ricolin has quit IRC | 10:58 | |
| ttx | cmurphy: one (key) difference is that with trove the previous team is still around and publishing a release for rocky | 11:17 |
| ttx | If we keep freezer "in" and it does not release for rocky that creates a bit of a precedent that "skipping" releases is ok | 11:17 |
| cmurphy | that's true | 11:18 |
| ttx | So maybe ask them to file early in Stein (before milestone-2) for reinclusion is the right approach | 11:18 |
| ttx | that way they can be back in Stein if that's really saved | 11:18 |
| cdent | I'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 |
| cmurphy | why do you think it's increasing? | 11:28 |
| cmurphy | my impression is it's a consistent attitude from people who think that infrastructure just exists by magic | 11:29 |
| cdent | cmurphy: it's sort of a finger on the pulse thing. Increasing mentions in twitter, comments around the world. | 11:30 |
| cdent | The statement might be more complete if it where s/OpenStack/Nova/ | 11:30 |
| cdent | so 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 happes | 11:32 |
| * cdent is speculating | 11:32 | |
| cdent | I'm not suggesting that it is a correct attitude, or anything like that, merely that it is happening | 11:33 |
| cdent | and as much as we would prefer people to rationally evaluate the world, hype and buzz matter :( | 11:33 |
| cmurphy | how 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 |
| cdent | Is 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 |
| jroll | cdent: 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 |
| jroll | I guess there's probably an argument that nova is more stable | 11:50 |
| cdent | I wonder if we should be more embracing and encouraging instead of defending? | 11:52 |
| jroll | I thikn the defending comes from the comments that say "openstack is dead, k8s is the future" | 11:53 |
| jroll | hard to encourage that :P | 11:54 |
| TheJulia | ttx: 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 the | 11:55 |
| TheJulia | perspective, not a versioned release | 11:55 |
| TheJulia | ++ for conveying use cases more clearly | 11:56 |
| cdent | ("value on not releasing something every cycle if there have been no changes or is no need")++ | 11:57 |
| *** jaosorior has quit IRC | 11:59 | |
| *** edmondsw has joined #openstack-tc | 12:04 | |
| cmurphy | nova (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 need | 12:05 |
| TheJulia | jroll: 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 |
| jroll | TheJulia: of course :) | 12:16 |
| openstackgerrit | Jean-Philippe Evrard proposed openstack/governance master: Split OpenStack-Ansible deliverable https://review.openstack.org/589446 | 12:17 |
| TheJulia | You 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-tc | 12:18 | |
| *** jaosorior has quit IRC | 12:27 | |
| dims | cdent : 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 |
| dims | cdent : 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 scenarios | 12:33 |
| dims | cdent : so things are easily to teardown and move to a fresh cluster (instead of upgrading for example) | 12:34 |
| dims | cdent : for application workloads that need existing VM images, yes, kubevirt seems to be gaining steam | 12:35 |
| dims | TheJulia : 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 interested | 12:39 |
| dims | in that kind of work and no one has stepped up yet. | 12:39 |
| *** e0ne has joined #openstack-tc | 12:40 | |
| dims | there's a better picture here - https://github.com/kubernetes-sigs/cluster-api | 12:41 |
| jroll | dims: definitely on my radar already :) | 12:41 |
| *** jaosorior has joined #openstack-tc | 12:42 | |
| TheJulia | I feel like that might be a good CI test to have... | 12:43 |
| dims | ++ jroll TheJulia | 12:50 |
| *** tellesnobrega has quit IRC | 12:50 | |
| cdent | thanks dims | 12:51 |
| TheJulia | Perhaps 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-tc | 12:54 | |
| *** dklyle has quit IRC | 12:59 | |
| ttx | TheJulia: 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 that | 13:05 |
| ttx | component can exist, but outside of the "official release" that we associate the name "openStack" with | 13:05 |
| ttx | it's a baseline for me | 13:05 |
| ttx | Now 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 |
| ttx | That is the situation of most of our libraries, for example | 13:07 |
| TheJulia | ttx: I agree with your statement | 13:09 |
| cdent | ttx: I think that's well understood. I think the point is good though: stability and feature completeness is something we should strive for and celebrate | 13:09 |
| cdent | hasn't had a release for N years + people still use it == great success | 13:09 |
| ttx | totally. We could even have a team that sheperds (sp?) those in perpetuity, a bit like the Oslo PTL pushes releases and covers for completed libraries | 13:09 |
| ttx | It;'s ok to be feature complete. It's not ok to be abandoned. | 13:10 |
| TheJulia | the 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 consensus | 13:10 | |
| ttx | And 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 |
| ttx | since it's about 15-min worth of work every 6 months. | 13:11 |
| *** lbragstad has joined #openstack-tc | 13:12 | |
| TheJulia | I 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 measure | 13:12 |
| ttx | re: 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 that | 13:12 |
| TheJulia | "Hi, this is my official check-in commit, I'm still alive!" | 13:12 |
| ttx | heartbeat :) | 13:12 |
| ttx | OpenStack is driven by complexity/size of needs... If we want to be beneath every K8s cluster on Earth we'll have to simplify deployment dramatically | 13:13 |
| ttx | If you have simple/small needs then it tends to be overkill | 13:14 |
| *** mriedem has joined #openstack-tc | 13:16 | |
| TheJulia | ++, different scale of use | 13:18 |
| scas | from 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 mouth | 13:23 |
| scas | i'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 capacity | 13:26 |
| * TheJulia wonders if we could somehow get that down to sandwich making ;) | 13:31 | |
| TheJulia | scas: 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 help | 13:32 |
| scas | TheJulia: 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 discussion | 13:34 |
| fungi | mriedem: 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 |
| zaneb | the 'lots of small clusters' thing is I think a result of k8s being designed around a single-tenant model | 13:51 |
| zaneb | as 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 app | 13:51 |
| mriedem | fungi: ok | 13:52 |
| ttx | zaneb: totally | 13:52 |
| ttx | although one might argue that it's really feature creep and that would pave the way for the next thing | 13:53 |
| ttx | (multitenant support for a single k8s cluster) | 13:53 |
| * fungi is catching up on office hour scrollback | 13:53 | |
| zaneb | they have a multitenancy SIG. it's only a matter of time | 13:54 |
| fungi | i 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 |
| ttx | zaneb: not everyone is happy about that SIG :) | 13:54 |
| zaneb | and kubevirt is getting better, although it's not ready for primetime yet aiui | 13:54 |
| * ttx has seen the amount of "what is kubernetes" discussions jump up lately | 13:55 | |
| dhellmann | fungi : I'm not sure I like the phrasing there, but I tend to agree with the sentiment | 13:57 |
| ttx | fuzzy scope is a natural consequence of large open collaborations | 13:57 |
| zaneb | the 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 one | 13:57 |
| ttx | dhellmann is also the top contributor to the release team. | 13:57 |
| zaneb | Ironic also seems safe | 13:57 |
| dhellmann | a sure sign that openstack is dead | 13:57 |
| zaneb | but 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 Nova | 13:58 |
| ttx | zaneb: the storage k8s SIG people might disagree with that :) | 13:58 |
| dhellmann | tc-members: does anyone have any background on the comments in https://review.openstack.org/588358 about us hosting a fork of ryu? | 13:59 |
| ttx | dhellmann: 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 |
| dhellmann | ah, if it's abandoned that's one thing | 14:00 |
| ttx | https://blueprints.launchpad.net/neutron/+spec/ryu-framework-maintenace-transition | 14:01 |
| ttx | https://etherpad.openstack.org/p/neutron-ryu-future-plans | 14:01 |
| smcginnis | There were some incompatibility issues too with ryu. I think this is the result of trying to sort that out. | 14:01 |
| ttx | that etherpad gives some insight on the discussion that happened | 14:02 |
| ttx | The trick is that they depend on parts of Ryu, rather than the whole project | 14: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 |
| fungi | fwiw, yesterday i temporarily blocked the corresponding project-config dependency to create that repo until there's consensus on what it should be named | 14:04 |
| ttx | fungi: 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 first | 14:05 |
| dhellmann | I wonder if "os-ryu" is a good name for the new thing. | 14:06 |
| smcginnis | If 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 |
| dhellmann | based on my experience with oslo, that can take quite a bit of work | 14:07 |
| fungi | right, 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 ways | 14:07 |
| dhellmann | all-in-one code bases tend to become rather tightly coupled | 14:07 |
| * dtroyer notices that https://github.com/starlingx-staging/stx-ryu is a thing… | 14:07 | |
| ttx | haha | 14:07 |
| dhellmann | does someone want to take the point on expressing our concerns, so it's not a big pile-on job? | 14:09 |
| dims | dtroyer : did you get a chance to peek at mriedem 's notes on stx/nova? | 14:21 |
| dtroyer | dims: I have, spent most of yesterday trying to match that up with the actual commits. | 14:22 |
| dims | cool! | 14:23 |
| dims | dtroyer : as mriedem must have mentioned ... bunch of us heading to hq end of this week | 14:24 |
| dtroyer | dims: 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 not | 14:26 |
| dims | dtroyer : dunno. we generally get asked about everything that's happening and what may be relevant to work on next | 14:27 |
| * dtroyer is familiar with that feeling | 14:27 | |
| dims | :) | 14:27 |
| fungi | dhellmann: 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 first | 14:30 |
| dhellmann | fungi : yes, ok, if the neutron team is already dealing with it that' sfine | 14:30 |
| dhellmann | as long as it's being raised | 14:30 |
| fungi | best not to spend our influence when it's not needed ;) | 14:30 |
| smcginnis | We should probably ask that the TC be updated on how the discussion goes though. | 14:31 |
| fungi | if it seems to start veering off the rails i'm happy to comment | 14:31 |
| dhellmann | smcginnis : good point | 14:31 |
| fungi | yeah, i expect them to at least follow up in the governance change with outcomes | 14:32 |
| fungi | rather, 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-tc | 14:33 | |
| *** hongbin has joined #openstack-tc | 14:38 | |
| *** e0ne has quit IRC | 14:39 | |
| *** annabelleB has joined #openstack-tc | 14:46 | |
| *** rosmaita has joined #openstack-tc | 14:57 | |
| openstackgerrit | Merged openstack/governance master: add soft validation of extra-atcs https://review.openstack.org/588585 | 15:01 |
| *** jaosorior has quit IRC | 15:01 | |
| *** mriedem is now known as mriedem_afk | 15:06 | |
| cdent | I 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 IRC | 16:11 | |
| *** jaypipes_ has joined #openstack-tc | 16:16 | |
| cdent | that email came back quickly with an "I'm not involved anymore, don't know what's up" | 16:16 |
| *** jaypipes has quit IRC | 16:17 | |
| *** jaypipes_ has quit IRC | 16:17 | |
| *** annabelleB has quit IRC | 16:17 | |
| *** annabelleB has joined #openstack-tc | 16:18 | |
| *** e0ne has joined #openstack-tc | 16:18 | |
| dhellmann | it sounds like we need someone to work out a plan for what to do | 16:19 |
| cdent | I'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 be | 16:21 |
| cdent | Assuming we could get the pypi gang to let us jump on the namespace, I would think a fork wouldn't be too bad | 16:21 |
| *** jpich has quit IRC | 16:27 | |
| *** jaypipes has joined #openstack-tc | 16:33 | |
| smcginnis | I think I've heard that pypi process can be quite long. | 16:34 |
| smcginnis | If we can get an existing owner to add us then I think that would be best all around. | 16:34 |
| smcginnis | If even possible. | 16:34 |
| * cdent is working on it | 16:35 | |
| cdent | I 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 IRC | 16:57 | |
| ttx | we have a formal PTL candidate now for Freezer | 17:00 |
| ttx | https://review.openstack.org/588645 | 17:00 |
| smcginnis | Has 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 |
| mugsie | smcginnis: they are not | 17:12 |
| mugsie | tacker seems to their main focus | 17:12 |
| dhellmann | freezer doesn't even show up on stackalytics | 17:14 |
| dhellmann | I see no contributions or reviews from Trinh Nguyen in freezer in the last year | 17:20 |
| *** e0ne has quit IRC | 17:20 | |
| dhellmann | that's not a blocker from taking over the project, but may be reason to say we want it moved out of governance first | 17:20 |
| dhellmann | I guess it makes the case somewhat similar to trove's | 17:20 |
| *** e0ne has joined #openstack-tc | 17:21 | |
| *** e0ne has quit IRC | 17:22 | |
| mugsie | yeah, but in troves case the new ptl has at least proposed patches to the project | 17:24 |
| *** ricolin has joined #openstack-tc | 17:30 | |
| *** harlowja has joined #openstack-tc | 17:31 | |
| *** annabelleB has quit IRC | 17:38 | |
| *** harlowja has quit IRC | 17:43 | |
| *** annabelleB has joined #openstack-tc | 17:45 | |
| *** annabelleB has quit IRC | 17:55 | |
| *** annabelleB has joined #openstack-tc | 18:01 | |
| *** e0ne has joined #openstack-tc | 18:04 | |
| *** diablo_rojo has joined #openstack-tc | 18:13 | |
| *** AlanClark has joined #openstack-tc | 18:21 | |
| fungi | worth 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 project | 18:24 |
| fungi | if we remove them from governance first, then we (for the most part) lose the authority to decide such matters | 18:24 |
| fungi | enough of a technicality probably nobody would question us doing it in the latter order, but it still seems backwards to me | 18:26 |
| dhellmann | given that there isn't anyone else around to approve of a handover, that's a good point | 18:26 |
| *** ricolin has quit IRC | 18:27 | |
| fungi | also, 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 |
| fungi | i 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 way | 18:30 |
| dhellmann | yeah, 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 governance | 18:31 |
| fungi | i could get behind that. what document should it go in? | 18:32 |
| dhellmann | to allow us to resolve that situation | 18:32 |
| dhellmann | hmm | 18:32 |
| dhellmann | maybe just a resolution? | 18:32 |
| dhellmann | I don't think we have anything formal that talks about dropping projects yet | 18:32 |
| dhellmann | we have the list of requirements for new projects, but nothing for old projects | 18:32 |
| fungi | i'll see what i can come up with | 18:33 |
| dhellmann | thanks | 18:33 |
| fungi | basically 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 former | 18:35 |
| fungi | there's a fuzzy middle ground too, e.g. fuel | 18:35 |
| dhellmann | there's also the case where a repo is removed from governance but the team remains | 18:36 |
| fungi | people 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 |
| dhellmann | I'm not sure what makes the fuel case special? | 18:36 |
| dhellmann | ah | 18:36 |
| smcginnis | Should we have a process where we just mark these as retired but still under governance? | 18:36 |
| dhellmann | perhaps we should reserve the right to more fully retire things that used to be under governance, too | 18:37 |
| fungi | that might be a food way to frame it | 18:37 |
| fungi | er, a good way | 18:37 |
| fungi | i must have skipped lunch today ;) | 18:37 |
| dhellmann | step 1 is just to move it to legacy, step 2 is to retire it after some delay | 18:37 |
| smcginnis | fungi: :) | 18:38 |
| dhellmann | heh | 18:38 |
| mugsie | playing devils advocate, but would that not fall under -infra / winterscale (what ever that team becomes) ? | 18:38 |
| smcginnis | mugsie: Could you elaborate? | 18:38 |
| cdent | i hear wintermute everytime someone says winterscale | 18:38 |
| mugsie | if we remove them from governance, it would be up to the team hosting the code (like the pypi example from above) | 18:38 |
| dhellmann | mugsie : 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 |
| mugsie | yeah, thats true. | 18:40 |
| dhellmann | it's one less thing for the winterscale team to have to deal with | 18:40 |
| mugsie | For cue, we totally retired it afaik. but it didn't have working gates or anything | 18:42 |
| dhellmann | yeah, 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 judgement | 18:48 |
| *** openstackgerrit has quit IRC | 18:49 | |
| fungi | right, i'd like to reserve asking the winterscale team to make ambiguous judgement calls which are entirely preventable with a little preparation | 18:49 |
| fungi | er, s/reserve/avoid/ | 18:50 |
| fungi | reserve the need to ask them to make ambiguous judgement calls only in situations we can't easily predict and sidestep | 18:50 |
| dhellmann | right | 18:50 |
| fungi | winterscale 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 |
| dhellmann | as long as it defers to former owners it should be easy to fit whatever we come up with into that process | 18:53 |
| dhellmann | i.e., the response for something that used to be governed would be "go ask the tc" | 18:53 |
| smcginnis | In 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.html | 18:54 |
| *** annabelleB has quit IRC | 18: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 crossed | 18:55 | |
| dhellmann | thundersnow? | 18:56 |
| * fungi can neither confirm nor deny | 18:58 | |
| *** diablo_rojo has quit IRC | 19:02 | |
| smcginnis | thundercats | 19:06 |
| *** mriedem has joined #openstack-tc | 19:24 | |
| fungi | how'd you guess? | 19:30 |
| fungi | i was pulling for voltron, but still not bad | 19:30 |
| *** e0ne has quit IRC | 19:32 | |
| *** cdent has quit IRC | 19:42 | |
| *** diablo_rojo has joined #openstack-tc | 20:29 | |
| *** annabelleB has joined #openstack-tc | 20:30 | |
| *** AlanClark has quit IRC | 20: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 IRC | 21:29 | |
| *** rosmaita has quit IRC | 22:11 | |
| *** hongbin has quit IRC | 22:39 | |
| *** diablo_rojo has quit IRC | 22:41 | |
| *** annabelleB has quit IRC | 22:41 | |
| *** edmondsw has joined #openstack-tc | 22:54 | |
| *** annabelleB has joined #openstack-tc | 22:58 | |
| *** edmondsw has quit IRC | 22:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!