| opendevreview | Andrey Kurilin proposed openstack/governance master: Appoint Andriy Kurilin as Rally PTL https://review.opendev.org/c/openstack/governance/+/878065 | 11:25 |
|---|---|---|
| jamespage | o/ | 13:46 |
| knikolla[m] | o/ | 13:48 |
| jamespage | I have a new project incubating in OpenStack Charms that I'd like to get the TC's opinion on | 13:49 |
| jamespage | we've been working on a POC of an alternative approach to deployment of OpenStack; still using Charms (and Juju) but making use of Kubernetes for hosting on the cloud control plane whilst leaving services that best reside directly on machines where they are, but leveraging the sematics that Juju provides to manage all of the associated complexity | 13:51 |
| jamespage | we also recognised that even with that encapsulation in the current set of charms, there was still alot for operators to understand so we've been working on a set of tooling to encapsulate alot of that complexity and make the tool much easier to consume. | 13:52 |
| jamespage | that's kinda popped out as a discrete project codenamed Sunbeam; I would envision that this will supersede the current OpenStack Charms project over the next 12 months or so; a set of migration tooling to move from OpenStack Charms -> Sunbeam is also on the roadmap | 13:54 |
| jamespage | looking for some opinion on whether to propose a new project for this; the current OpenStack Charms project has alot of repos, and alot of code history and I want to ensure that its clear what's future strategic direction (Sunbeam) and what's going to be deprecated (OpenStack Charms) | 13:57 |
| jamespage | alternatively we can continue to work on this under the OpenStack Charms project, but the technical architecture for the deployed cloud is quite different as are alot of the tooling being used; we've picked up Terraform todo alot of the deployment management task as well as the configuration of the deployed cloud | 13:58 |
| jamespage | currently we're using Kolla containers for the K8S payloads | 14:00 |
| jamespage | although we are trialing some work that might help minize the size of the container footprints as well - that's still very early stages right now | 14:02 |
| jamespage | any thoughts? | 14:02 |
| fungi | the plan has shades of the trove-ng discussion as well as tripleo retirement vibes. when trove contributors proposed replacing the current project with a non-backward-compatible solution under the same name, it was considered problematic both from a user experience perspective and due to general name confusion | 14:06 |
| fungi | more recently, red hat contributors proposed to retire the tripleo project because it was effectively single-vendor-maintained and that vendor was no longer interested in contributing to it | 14:06 |
| fungi | this sounds like it sort of falls somewhere in between those prior scenarios | 14:07 |
| jamespage | yeah - I'm keen to avoid name confusion but I'm also not in the business of leaving our existing deployed base high and dry with no upgrade paths; to be clear it will be a transtion to a Sunbeam deploy (not an inplace upgrade) | 14:09 |
| fungi | makes sense. my hot take would be propose a new openstack project called sunbeam, make phased retirement plans for deliverables in openstack-charms which are expected to cease active development, and then have sunbeam "adopt" any relevant deliverables from openstack-charms whenever is appropriate | 14:12 |
| fungi | but that's just my (purely tc emeritus) opinion of course | 14:12 |
| jamespage | thanks fungi - your feedback is very much appreciated :) | 14:13 |
| fungi | also recommend engaging openinfra foundation staff early in the proposal process to vet the name for potential trademark issues | 14:14 |
| fungi | we've had our share of projects renamed at less convenient times because we didn't perform that due diligence earlier | 14:15 |
| jamespage | ack | 14:18 |
| gmann | jamespage: By understanding from your details here (though need more details about new project sunbeam), I think if code base is not used from charms or no deps then yes it will be clear if you propose it as a new project. But at the same time whether to deprecate OpenStack Charms or not is different question and that can be think if no maintainers are there. I think monitor the momentum of new projects for some cycle and then | 15:55 |
| gmann | decide on OpenStack Charms not at the same time. | 15:55 |
| gmann | knikolla[m]: are you booking for Tc+leaders interaction lot also for vPTG ? | 15:59 |
| bauzas | +1 I'd appreciate the timing in advance | 16:38 |
| bauzas | so I could organize myself | 16:38 |
| gmann | yeah I am also waiting for that to select QA slots | 16:38 |
| * bauzas never stops saying how he dislikes virtual meetings because of the weird work-on-non-usual-workhours thing | 16:39 | |
| JayF | There's really no way to escape that inconvienience when you're working on a global product though. I'm glad most of the requirements are isolated to PTG-weeks. | 16:43 |
| fungi | same, i'm hoping to book the os-security track so that it doesn't overlap with os-tc | 16:44 |
| bauzas | JayF: I work with a globally distributed team, but we only have a few meetings | 17:04 |
| bauzas | JayF: here, we need to work for a long week | 17:05 |
| JayF | I gotta be honest, I don't find PTG week taxing compared to other, non-OSS, corporate "sync-up"/planning type events I've experienced. I'm sure there are better ways to do it, but we're doing pretty good with how it's arranged now. | 17:05 |
| JayF | I wish all our work could be done completely asyncronous, but sometimes working in sync is needed to help folks build rapport with each other. | 17:06 |
| jamespage | gmann: agreed that the deprecation of the OpenStack Charms project is a separate decision at the end of the day | 17:12 |
| knikolla[m] | gmann: did we do that on the first hour of the TC PTG slot last time? | 17:18 |
| knikolla[m] | or I am misremembering | 17:19 |
| gmann | knikolla[m]: we did on Monday tc slot, 15 UTC - 17 UTC last time | 17:28 |
| knikolla[m] | oh right, i remember now. | 17:29 |
| knikolla[m] | i see a completely empty schedule for all tracks on Monday 17.00-19.00. | 17:30 |
| knikolla[m] | well, there is no 18.00. | 17:31 |
| knikolla[m] | but we can perhaps do 16.00-18.00 | 17:31 |
| bauzas | in general I prefer the "golden hour" : 1500UTC | 17:39 |
| bauzas | all my meetings are in general in this hour, due to the fact it works for a lot of TZs | 17:39 |
| knikolla[m] | same, but I want to minimize conflicts to allow the leaders of those tracks that that schedule would conflict with to attend this session. | 17:41 |
| knikolla[m] | and 1500UTC being the golden hour has several | 17:41 |
| gmann | or we can ask community leaders for their preferred time as they are important attendees in this sessions. I usually did poll for that | 17:41 |
| JayF | At some point you've gotta just pick a time, especially six days before it begins... I would be +1 to a Monday slot 1600-1800 UTC | 17:42 |
| gmann | we can pick the one, majority of leaders are available | 17:43 |
| knikolla[m] | I would rather avoid that as it will lead us to picking which people's attendance is more important once the poll is out. | 17:45 |
| gmann | I think it will give us 'majority of availability' vs 'which people's' | 17:46 |
| JayF | I worry sometimes that approach leads to people living in areas that a minority of contributors are from losing out every time. | 17:47 |
| JayF | It's a hard problem :\ | 17:48 |
| gmann | I think target of this sessions is to have large number of community leaders and scheduling time for minority of contributors is different things | 17:49 |
| clarkb | in previous ptgs I've set up opendev office hours to overlap with each major block of time. What I've found is that its almost always better to optimize for when people are interested. Otherwise you spend a lot of time idle. | 17:50 |
| fungi | yes, it's been pointed out many times (going back nearly to the beginning of openstack) that majority rule meeting times can self-perpetuate a lack of global diversity, since the majority will have a tendency to remain a majority if the minority regions never gain traction | 17:50 |
| gmann | otherwise we need to schedule Asia specific TZ where we have minority of contributors | 17:50 |
| knikolla[m] | I just want to note the assumptions that I'm operating under in specific order of importance for me. 1. people will prioritize vPTG events in their calendar at least for the week of the PTG 2. we want to minimize conflicts between tracks 3. we want to generally optimize for people's schedules and attendance | 17:50 |
| knikolla[m] | Based on those assumptions, I believe the 1600-1800UTC on Monday time slots are my preferred choice. | 17:51 |
| fungi | those times are definitely more convenient for participants in the americas, quite late for emea participants, and extremely early for apac | 17:52 |
| gmann | I am not denying those slots, this work for me too but I am saying let's ask leaders also if this work for them or not instead of giving them with no choice of preferred time selection | 17:53 |
| fungi | but to maximize involvement from the people who are already most involved, those times are optimal yes | 17:53 |
| gmann | yeah this is important to have people with most involvement and interest | 17:53 |
| knikolla[m] | tc-members: I'm going to book Monday 1600-1800UTC for TC+Community Leaders PTG session by EOD today. More feedback is welcome before I make the call. | 18:01 |
| noonedeadpunk | ++ | 18:01 |
| jamespage | works for me | 18:01 |
| slaweq | Ok for me | 18:23 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!