| *** cdent has quit IRC | 00:10 | |
| *** kumarmn has quit IRC | 00:17 | |
| *** openstackgerrit has quit IRC | 00:41 | |
| *** kumarmn has joined #openstack-tc | 02:18 | |
| *** kumarmn has quit IRC | 02:22 | |
| *** kumarmn has joined #openstack-tc | 02:25 | |
| *** kumarmn has quit IRC | 02:31 | |
| *** lbragstad has joined #openstack-tc | 03:00 | |
| *** lbragstad has quit IRC | 03:21 | |
| *** kumarmn has joined #openstack-tc | 04:32 | |
| *** kumarmn has quit IRC | 04:36 | |
| *** Rockyg has joined #openstack-tc | 04:46 | |
| *** Rockyg has quit IRC | 06:03 | |
| *** jpich has joined #openstack-tc | 06:58 | |
| *** ChanServ sets mode: +o openstack | 07:14 | |
| *** kumarmn has joined #openstack-tc | 09:32 | |
| *** kumarmn has quit IRC | 09:36 | |
| *** dtantsur|afk is now known as dtantsur | 11:02 | |
| *** sdague has joined #openstack-tc | 11:38 | |
| *** kumarmn has joined #openstack-tc | 13:20 | |
| *** kumarmn has quit IRC | 13:20 | |
| *** kumarmn has joined #openstack-tc | 13:20 | |
| *** rosmaita has joined #openstack-tc | 13:33 | |
| *** kumarmn has quit IRC | 13:43 | |
| *** kumarmn has joined #openstack-tc | 13:43 | |
| *** kumarmn has quit IRC | 13:55 | |
| *** kumarmn has joined #openstack-tc | 13:57 | |
| *** dtantsur is now known as dtantsur|brb | 14:20 | |
| *** hongbin has joined #openstack-tc | 14:43 | |
| *** kumarmn has quit IRC | 14:44 | |
| *** kumarmn has joined #openstack-tc | 14:45 | |
| *** kumarmn has quit IRC | 14:49 | |
| *** kumarmn has joined #openstack-tc | 14:50 | |
| smcginnis | It's that time again. | 15:00 |
|---|---|---|
| * dtroyer looksa bout | 15:00 | |
| dhellmann | o/ | 15:00 |
| smcginnis | So there was some talk about simplifying our assert:supports-*-upgrade tags at the PTG. | 15:03 |
| smcginnis | We have several that no one uses and are slightly confusing: https://governance.openstack.org/tc/reference/tags/index.html#project-assertion-tags | 15:03 |
| smcginnis | Should we propose removal of some of them? | 15:03 |
| ttx | o/ | 15:04 |
| ttx | someone suggested a ping list on -dev | 15:04 |
| * ttx tries that | 15:04 | |
| * smcginnis wonders if a notes etherpad could be useful | 15:05 | |
| dhellmann | smcginnis : it sounds like maybe we should, although I'd have to think more about what exactly we'd do differently | 15:05 |
| dims | o/ | 15:06 |
| * johnthetubaguy lingers | 15:06 | |
| dims | hey thanks for the ping ttx | 15:06 |
| smcginnis | I think we should at least remove assert:supports-zero-impact-upgrade since no one uses it and it really doesn't make much sense to me. | 15:07 |
| dims | dhellmann : thanks for the governance dashboard update | 15:07 |
| dhellmann | dims : now if I could just figure out how to fix my oslo dashboard in the same way. I'm still seeing things I've voted on :-/ | 15:07 |
| ttx | dhellmann: we have no project with docs:follows-policy at this point. Is that tag still useful? | 15:08 |
| dhellmann | ttx: pkovar and the docs team are going to be redefining that tag shortly | 15:08 |
| dhellmann | redefining or replacing | 15:09 |
| ttx | ok | 15:10 |
| ttx | please everyone review the project additions so that we can make fast progress on those | 15:11 |
| dhellmann | what's the general opinion on glare? I see sdague's comment about the potential for conflict | 15:12 |
| ttx | dims: you were in that room right? | 15:13 |
| ttx | rosmaita was pretty confident that would not conflict that much | 15:13 |
| dims | ttx : yes i was in the room when we talked to glare folks | 15:13 |
| ttx | (by the time I got there it was over) | 15:13 |
| dhellmann | my impression from the meeting with the glance team is that they'd stop talking about replacing glance, but I'm still unclear about conflict elsewhere | 15:13 |
| dhellmann | at one point they were talking about replacing barbican, for example | 15:13 |
| *** zhouyaguo has joined #openstack-tc | 15:14 | |
| dhellmann | and I'm not sure I see how glare is different from swift, is it just the indexing? | 15:14 |
| ttx | ah, missed that one | 15:14 |
| ttx | glare can use swift as backend | 15:14 |
| fungi | as i mentioned at the ptg, i am wholly in favor of removing any governance tags which don't presently apply to any project. the tags can be readded when there is a project which complies | 15:14 |
| smcginnis | I think they got the message to focus on their own use cases and not make it a goal to replace anything. | 15:14 |
| dhellmann | I'd have to look in the archives to find that reference, it was a while ago | 15:14 |
| dims | smcginnis : yep, agree | 15:14 |
| *** openstackgerrit has joined #openstack-tc | 15:14 | |
| openstackgerrit | Sean McGinnis proposed openstack/governance master: Remove assert:supports-zero-impact-upgrade tag https://review.openstack.org/506241 | 15:14 |
| smcginnis | fungi: In that case... ^^ | 15:14 |
| smcginnis | :) | 15:14 |
| dhellmann | but if their use cases are actually to do the same thing that's being done elsewhere? | 15:14 |
| ttx | dhellmann: at least if they were under governance we would have some leverage, currently they can just compete with everything and create confusion | 15:15 |
| dims | dhellmann : during the new project review, all of us were clear about where they should be focusing on (NOT glance replacement) | 15:15 |
| smcginnis | dhellmann: They had some slightly different "image serving" requirements when it came to NFV. | 15:15 |
| dhellmann | smcginnis , fungi : please leave the doc tag. I'm trying to get that team to engage with governance, but there's still a bunch of members in transit home. | 15:15 |
| smcginnis | dhellmann: ++ | 15:15 |
| fungi | dhellmann: my comment was more to do with the upgrade tags some of which seem to not actually have any projects which meet their requirements | 15:16 |
| ttx | fungi: just posted that suggestion on the skiplevel thread | 15:16 |
| dhellmann | fungi : yep, just throwing it out there since the docs tag was mentioned too | 15:16 |
| fungi | itym fastforward! ;) | 15:16 |
| ttx | dhellmann: ack, also not removing the maint-mode tag either | 15:16 |
| dhellmann | smcginnis : is there some sort of nova integration to support that? or is there an expectation that there will be, after glare is official? | 15:16 |
| smcginnis | We do have a Trove request for that one at least. | 15:16 |
| ttx | and searchlight | 15:17 |
| dhellmann | I thought I saw a maint-mode request for another project, too. Designate? | 15:17 |
| dhellmann | that's it | 15:17 |
| smcginnis | dhellmann: I'm guessing not. My impression was it is already being used for some NFV things, but that could just be something internal to Ericsson. | 15:17 |
| ttx | nokia? | 15:17 |
| sdague | my comments on glare stand. Whether or not there is technically not going to be a conflict, I'm really uncomfortable giving the green light for a project that historically talked about replacing glance just when glance team is getting back on it's feet | 15:17 |
| dims | y nokia | 15:18 |
| fungi | on glare, i'm still mildly concerned about interactions i've seen with other teams/workgroups, including the somewhat aggressive way they were pushing the etsi/nfv workshop organizers to let them try and convince them to use glare | 15:18 |
| dhellmann | that feels a bit weird. "We don't want 2 image services in the community, but it's ok if glare does image serving and someone has custom patches to nova to use it" | 15:18 |
| sdague | managing the people and moral side of things is important as well, and I think we should be giving glance a big protective buffer for a while | 15:18 |
| ttx | sdague: we could ask for "more history of graciously cooperating" | 15:18 |
| dhellmann | sdague : moral or morale? | 15:18 |
| sdague | morale | 15:19 |
| smcginnis | rosmaita: Around? Any comments on the glance/glare meeting last week? | 15:19 |
| dhellmann | both, I guess, but which did you mean? -- ok | 15:19 |
| rosmaita | i'm trying to put a comment on that patch atm | 15:19 |
| dims | sdague : we should ask the glance team what they though about the interactions with glare team this time around | 15:19 |
| dims | hey rosmaita | 15:19 |
| ttx | I just fear that delaying them will get us further from what we want there | 15:19 |
| ttx | which is good collaboration | 15:19 |
| sdague | dims: we could, but I also think that it's kind of the important job of the TC to step in in situations like this | 15:19 |
| rosmaita | well, a history of gracious cooperation as ttx said would be nice | 15:20 |
| dims | sdague : yes, we had a good conversation, several of us in TC with the glare team | 15:20 |
| sdague | rosmaita: sure, I just don't even want to put the glance team on the hook to feel preasured to grade the glare team right now | 15:20 |
| dims | then me/ttx went and talked to both glance and glare team together | 15:20 |
| rosmaita | i think sdague said it best earlier, about technical space vs moral space | 15:21 |
| sdague | I feel like glance went through a pretty tough people crisis, and I want to give the team space and support to get back on their feet and feel like they are progressing well before even considering something like glare | 15:21 |
| dims | sdague : y that's fair | 15:21 |
| sdague | which to me means a solid year of not having anyone else intruding there | 15:21 |
| sdague | and evaluate in a year | 15:21 |
| ttx | Something like "reconsider for Rocky" | 15:21 |
| sdague | yeh, I wouldn't even want to do that that soon, personally | 15:22 |
| dhellmann | given the history, I'm not inclined to give a lot of benefit of the doubt, although it does seem like the current status is moving in roughly the right direction | 15:22 |
| ttx | a year sounds a bit long to me | 15:22 |
| ttx | which btw.... mordred we need a Berlin based name | 15:22 |
| sdague | I think it's way more important to have a strong glance team than another related effort | 15:22 |
| smcginnis | Rocky seems reasonable to me. And if situations have not changed, OK to defer another cycle. | 15:22 |
| dims | i'd like to revisit in 6 months and ask glance team what they think at that time | 15:22 |
| sdague | so my bias is strongly on giving glance pretty strong protections | 15:23 |
| dhellmann | we do still have the glance team on our top 5 | 15:23 |
| sdague | dhellmann: ++ | 15:23 |
| dims | right dhellmann | 15:23 |
| rosmaita | i don't know that not approving glare will protect glance all that much | 15:23 |
| dhellmann | rosmaita : would it make things worse? | 15:23 |
| rosmaita | it's not like the glare devs will suddenly start working on glance | 15:23 |
| ttx | I feel like we have been stringing them for long already, but ok to live by a 6-month "more history of graciously cooperating" delay | 15:23 |
| mordred | ttx: yah- berlin name on my list | 15:23 |
| dhellmann | rosmaita : I don't think that's what any of us expect | 15:24 |
| rosmaita | the problem has been the confusion about what the glance/glare relationship is | 15:24 |
| mordred | ttx: I'm vamping on it because I think we need to set up our own CIVS server before we do another naming poll | 15:24 |
| dims | ttx : agree | 15:24 |
| smcginnis | mordred: OpenStack Steglitz ;) | 15:24 |
| rosmaita | and the glare team has not been helpful in that regard | 15:24 |
| mordred | ttx: as the last time it took over a week to send out emails and we STILL didn't get them all sent out | 15:24 |
| sdague | rosmaita: sure, I just don't want to even go there. The point being glance is the openstack project, and glare is not, and projects should be integrating with glance. | 15:24 |
| ttx | Schöneberg | 15:25 |
| mordred | ttx: quick sake of argument - what if we ditched foundation member rule for this and just did an open poll? | 15:25 |
| sdague | Schnitzel | 15:25 |
| mordred | ttx: no emails needed, whoever wants to vote can vote | 15:25 |
| dhellmann | really, Schlitz | 15:25 |
| smcginnis | Schützenstraße, then no one else will know how to pronounce it. | 15:25 |
| rosmaita | sdague ++ for Schnitzel | 15:25 |
| ttx | smcginnis: too long | 15:25 |
| sdague | also, ascii | 15:26 |
| mordred | ttx: send the poll link to openstack@ and openstack-dev@ - and hell tweet it | 15:26 |
| fungi | probably better to be clear and not give the glare team false hopes... it's not so much a deferral as a rejection with a promise to reconsider later | 15:26 |
| smcginnis | fungi: ++ | 15:26 |
| * dhellmann mordred : as long as we vet the list of names | 15:26 | |
| * dhellmann wonders what is going on with his irc client | 15:26 | |
| ttx | mordred: allows for ballot stuffing though | 15:27 |
| fungi | and the most compelling argument for approving glare's application is so the tc can attempt to prevent them from doing damage to the ecosystem if let to run unchecked | 15:27 |
| ttx | mordred: more concerned by someone voting 10000 times than by a random person voting | 15:27 |
| fungi | which seems like a disingenuous move | 15:27 |
| smcginnis | My only thing in favor of glare is they are addressing a real use case with NFV that we do not currently cover otherwise. | 15:28 |
| sdague | smcginnis: what is that use case? | 15:28 |
| fungi | mordred: we _used_ to just do an open poll (through launchpad i think) didn't we? | 15:28 |
| smcginnis | sdague: There is a special format and accessiblility needs to items within that format that NFV deployments need. | 15:28 |
| ttx | fungi: required LP, so prevented ballot stuffing | 15:28 |
| sdague | smcginnis: can you be more specific? | 15:28 |
| dhellmann | there's something about a multi-part image format, isn't there? | 15:29 |
| smcginnis | sdague: IIRC, the "image" is more like a zip file that contains a folder structure. It needs to be treated as a whole, yet still provide direct access to specific files within that structure. | 15:29 |
| fungi | ttx: sure, just pointing out that we used to let anyone (with a lp account) vote rather than limiting it to foundation members | 15:29 |
| dhellmann | smcginnis : that matches my vague memory of what I was told | 15:29 |
| ttx | fungi: ack | 15:30 |
| sdague | smcginnis: for what situation? That's a specific behavior, but I think I need to see the use case through to end user results | 15:30 |
| dhellmann | that goes deeper than I remember | 15:30 |
| smcginnis | sdague: I think it was presented as something as part of the ETSI NFV requirements, but I don't really have a deep understanding. | 15:30 |
| sdague | here is the thing, given 4 years of "interesting" NFV feature request pushes in Nova, there are tons of "must have this feature" asks that come in, because that is exactly how a system that someone sold 10 years ago worked | 15:31 |
| dhellmann | it bothers me that a key case for glare is related to images, if we're saying they shouldn't be focused on competing with glance | 15:31 |
| sdague | vs. thinking about the end user / operator results, and the natural ways to acheive and extend them in the existing system | 15:31 |
| sdague | dhellmann: ++ | 15:31 |
| rosmaita | glare can unpack the stuff and create regular glance images | 15:32 |
| sdague | which also mirrored my experience working on the Carrier Grade Linux group at OSDL 10 years ago | 15:32 |
| dhellmann | rosmaita : what triggers that? | 15:32 |
| rosmaita | nothing now | 15:32 |
| fungi | the glare sales push starting at http://lists.openstack.org/pipermail/openstack-dev/2017-September/121816.html (follow that thread) seemed to me like they were shopping around for use cases to make them relevant | 15:32 |
| rosmaita | they are not designing that way | 15:32 |
| dhellmann | is glare acting as a front-end for managing images in glance | 15:32 |
| dhellmann | ? | 15:32 |
| rosmaita | no, by "can" i meant "could" | 15:33 |
| dhellmann | ah | 15:33 |
| * dhellmann if we say no to glare, what is the likelihood that | 15:33 | |
| dhellmann | bah | 15:33 |
| sdague | I'm also super concerned with "glare is an official project, nova has to change it's images interface to make glare first class with glance" | 15:33 |
| dhellmann | if we say no to glare, what is the likelihood that someone will want those features added to glance? | 15:34 |
| rosmaita | don't know | 15:34 |
| dhellmann | given the team priorities, I can't imagine any work on those things happening any time soon | 15:34 |
| dhellmann | priorities and constraints | 15:34 |
| sdague | well, people have wanted image processing on the glance side for a while, so that it could on the fly convert images to the right hypervisor formats, for instance. | 15:34 |
| rosmaita | yeah, "on the fly" would probably be unreasonable given the size of most images | 15:36 |
| fungi | which ended up implemented via the tasks api in many places | 15:36 |
| dhellmann | yep, that and lots of other things | 15:36 |
| rosmaita | fungi right, there's a task for conversion | 15:36 |
| sdague | rosmaita: or convert on upload | 15:36 |
| sdague | anyway, we're getting a little off track | 15:36 |
| dhellmann | yeah, s/on the fly/transparently/ | 15:36 |
| rosmaita | sdague right, that can be done with the import flow | 15:36 |
| openstackgerrit | Matthew Treinish proposed openstack/governance master: Add api interop assert tag to ironic https://review.openstack.org/482759 | 15:36 |
| openstackgerrit | Matthew Treinish proposed openstack/governance master: Add api interop assert tag to nova https://review.openstack.org/506255 | 15:36 |
| sdague | rosmaita: ok, cool | 15:36 |
| rosmaita | well, "can" in the sense of "it's possible" | 15:36 |
| sdague | rosmaita: right | 15:36 |
| rosmaita | (we're still working on it) | 15:37 |
| dhellmann | I'd be interested in seeing what other approach could be taken to solve the nfv case | 15:37 |
| dhellmann | the image format thing | 15:37 |
| fungi | i'm still a little worried about the mutability of images and failure to check/update checksums... has that been getting any better? | 15:37 |
| sdague | fungi: there is some signing stuff being proposed to nova for checking signed images | 15:38 |
| dhellmann | I'm still on the fence about glare, but I'm leaning toward a no, I guess | 15:38 |
| fungi | for example, with user-specified locations, multiple image locations, et cetera | 15:38 |
| sdague | fungi: sure, there is a ton of interesting work | 15:38 |
| sdague | and glance is rebuilding a team | 15:38 |
| rosmaita | fungi the image locations stuff is a mess | 15:38 |
| sdague | and I want to give them all the space in the world to address that stuff first | 15:38 |
| fungi | yup, just wondering where the rebuilt team's priorities are focused | 15:38 |
| rosmaita | we are reconsidering how to deal with all that | 15:38 |
| *** mfedosin has joined #openstack-tc | 15:39 | |
| sdague | but making them deal with potentially competing project and negotiating with that, if I was on the glance team, I'd just rage quit over it. | 15:39 |
| rosmaita | fungi: as long as you don't expose image locations to end users, you are ok | 15:39 |
| dhellmann | the two teams do seem to have come to an agreement, but I can see sdague's point | 15:39 |
| openstackgerrit | Sean McGinnis proposed openstack/governance master: Remove assert:supports-accessible-upgrade tag https://review.openstack.org/506263 | 15:40 |
| mfedosin | hey! I need some time to read the logs | 15:40 |
| mfedosin | if you have questions about glare - please ask | 15:40 |
| fungi | coupling the small/rebuilding team with the simplification priority, i'd be fully in favor of glance declaring a bunch of those hard-to-make-sane features untenable/deprecated | 15:40 |
| dhellmann | rosmaita : did the team come up with ideas for recruiting help? | 15:40 |
| sdague | I would also really like to see the full use case work flow for this special image feature | 15:40 |
| sdague | because, I expect that it didn't get enough "or you could solve this problem the following way" | 15:41 |
| * dhellmann nods | 15:41 | |
| sdague | cyborg is an instance where there was a full year of push for a particular solution, that included a bunch of invasive nova patches, that were all written | 15:41 |
| sdague | and saying "or.... you could solve it this other way" | 15:42 |
| sdague | and now they are running in that direction, which also lets them address the GPU case which is really important | 15:42 |
| dims | ++ sdague | 15:42 |
| dhellmann | are any of the other new projects controversial in anyone's mind? | 15:45 |
| mordred | fungi, ttx: it does open the door to ballot stuffing - but how worried are we about that? I mean, we wound up with "rocky" for R when there were so many other cooler options - and "Queens" for Q even though it's the least australia-sounding word ever | 15:45 |
| dims | mogan may be dhellmann | 15:45 |
| dhellmann | how does stackube relate to magnum? | 15:45 |
| mordred | dhellmann: I think stackube fits a different space | 15:46 |
| * dhellmann awaits more detail | 15:46 | |
| fungi | i'm getting increasingly confused by the proliferation of container-related teams (approved and proposed) | 15:46 |
| sdague | also, is magnum still a thing? | 15:46 |
| mordred | magnum is "boot me a COE" - stackube is, iirc, "use kubernetes to get me a VM" - and could potentially be used as a novabackend | 15:46 |
| sdague | http://stackalytics.com/?module=magnum-group&metric=commits | 15:46 |
| dhellmann | fungi : me, too | 15:46 |
| dims | dhellmann : yep. at the moment stackube has a "captive" openstack and uses that to add multi-tenancy to kubernetes. so it automates keystone, cinder, neutron to achieve that | 15:46 |
| mfedosin | sorry, for interruption. I think I should put the link here. It's about storing VNF packages in Glare: https://etherpad.openstack.org/p/ptg-glare-etsi | 15:47 |
| ttx | mordred: hmm, not exactly | 15:47 |
| dims | dhellmann : it can do baremetal in the future. they don't expect operators to layer over an existing openstack | 15:47 |
| dims | which is magnum's view | 15:47 |
| dhellmann | the stackube request doesn't seem to have responded directly to the questions needed for an application. Is that info somewhere other than the commit message? | 15:47 |
| ttx | Stackube is actually a way to deploy a multitenant Kubernetes cluster on top of Cinder/Neutron and Keystone | 15:47 |
| *** cdent has joined #openstack-tc | 15:47 | |
| dhellmann | dims : what does "do bare metal" mean? | 15:47 |
| dhellmann | so stackube is a k8s deployment tool? | 15:48 |
| ttx | dhellmann: no, more of a set of patches and technologies to make it run on top of OpenStack | 15:48 |
| ttx | (in a multitenant manner) | 15:48 |
| mordred | ttx: oh- I got my projects wrong then | 15:49 |
| ttx | it would belong in that "adjacent technology enablers" box from the map I showed | 15:49 |
| dhellmann | I'm happy to have that, I guess, but does it fall into the "competing with other communities" soft rule we set for ourselves? does the cncf not want stackube? | 15:49 |
| ttx | with Kuryr and Fuxi | 15:49 |
| mordred | ttx: sorry - I was thinking about kubevirt | 15:49 |
| sdague | fungi: your confusion on the number of containers solutions isn't limitted to that in the openstack space | 15:49 |
| dims | dhellmann : there's a picture https://github.com/openstack/stackube#stackube-authors | 15:49 |
| ttx | dhellmann: it's specific to openstack | 15:49 |
| mordred | yah - stackube seems kind of like bifrost to me | 15:49 |
| sdague | they are kind of popping up like javascript frameworks, one every few weeks | 15:49 |
| fungi | mfedosin: thanks, i've been reaching out to some of the attendees of the etsi/nfv workshop to get their impression on the interactions with glare there | 15:49 |
| dims | dhellmann : they don't rely on nova at all for anything | 15:49 |
| mordred | do a deployment of a thing which isn't fully openstack but is built out of openstack pieces | 15:50 |
| ttx | so it's more of a layer to run K*s on top of openstack | 15:50 |
| ttx | think of it as the layer letting you plug kubernetes on top of cinder/neutron/keystone | 15:50 |
| dhellmann | on top of parts of openstack? | 15:50 |
| dims | new components in kubernetes that make sure of openstack to provide services is more like it | 15:50 |
| fungi | mfedosin: responses i'm getting are that glare seems overly eager to invent use cases, but this is only anecdotal of course and i haven't talked to everyone | 15:51 |
| ttx | in a single-cluster, multi-tenant manner | 15:51 |
| dims | like setting up networking for kubernetes nodes using neutron | 15:51 |
| dhellmann | I see some RC+1 votes already, so I'll ask my question about the response again: did they respond directly to the questions we ask of new teams somewhere else? | 15:51 |
| dhellmann | because as it stands the application looks incomplete | 15:51 |
| dhellmann | though I haven't read through the comments | 15:51 |
| ttx | dhellmann: they did provide some of that during the in-person review | 15:51 |
| ttx | but asking to include them in co;;it ;essage sounds fair | 15:52 |
| ttx | arh | 15:52 |
| dhellmann | ok. I think I'd like to see it in writing, since I wasn't able to attend | 15:52 |
| ttx | still learning that us keyboard | 15:52 |
| sdague | I'm also not convinced that etsi specs put this more in the camp. That means the entire design for the critical features is happening outside of openstack and being forced in. Much like OCCI previously. | 15:52 |
| mordred | sdague: ++ etsi specs aren't super interesting to me in general, and external design does bother me, although I certainly don't want to close the door to us deciding that an openstack project implementing an externally designed spec is a bad thing | 15:55 |
| dhellmann | let's not get too NIH | 15:55 |
| ttx | sdague: yeah, feels like this would belong better in a more "NFV" product line if we ever create one. We could move tacker to it, too | 15:55 |
| mordred | the Open Service Broker API is an example of such an external spec that I don't think it would be a terrible idea for some ofour things to implement | 15:55 |
| mordred | but just the existence of Open Service Broker API or an ETSI spec does not in and of itself mean that we as OpenStack *must* implement such a thing | 15:56 |
| mordred | I guess in some way wiht an external spec the part of the open design process thathappens openstack-side is us deciding that the spec or API is valuable and that we want to adopt/use it | 15:57 |
| sdague | ttx: or even more importantly, first try really hard to figure out mapping it to existing things. | 15:57 |
| mordred | what a meta thought trian | 15:57 |
| sdague | because the response, here are specifications, isn't useful for an openstack use case of I expect to get X, store it somewhere, then when it pops up it shows up like Y | 15:57 |
| mordred | rosmaita: have we ever discussed the infra/nodepool image upload/replace use case with you? | 15:58 |
| rosmaita | mordred nope, we should have that discussion | 15:59 |
| mordred | rosmaita: I think it's potentially also applicable to normal image public workflows by cloud providers - and I was just thinking about it yesterday so this is a timely discussion here :) | 15:59 |
| mordred | rosmaita: cool - I'll see if I can write something up for you | 15:59 |
| mordred | rosmaita: the tl;dr is that we want an image called "ubuntu-xenial" - but we want to upload a new one every day, keeping at least one old copy of it. we never want there to be a moment when such an image does not exist - but sometimes we need to delete the most current one and fall back to the previous one | 16:00 |
| rosmaita | mordred we call that "image lifecycle management" | 16:00 |
| mordred | rosmaita: we do that today with an external database and uploading all the images using unique ids - so the imageis ubuntu-xenail-{uuid} to glance | 16:01 |
| mordred | rosmaita: yah. image lifecycle management indeed :) | 16:01 |
| rosmaita | there's a brief discussion on the ML, and also a product wg spec that didn't go anywhere, i will find links for you | 16:02 |
| mordred | rosmaita: cool - I'll follow up for those - I mean, nodepool is fine at this point and we don't really have any issues ourselves- but I keep thinking about hte fact that nodepool's image builders run independently now - so one COULD use it to manage the normal images in their cloud - other than the way it keeps external metadata and name suffixes would make for a terrible experience for humans who | 16:03 |
| mordred | wanted to use those images | 16:03 |
| * mordred stops co-opting the tc room for infra/glance discussion | 16:03 | |
| fungi | well, it's a good demonstration of a project taking use cases from its existing user base ;) | 16:04 |
| * dhellmann checks the clock and starts making lunch plans | 16:05 | |
| *** rosmaita has quit IRC | 16:22 | |
| persia | On ETSI specs: also at PTG was some good discussion between ETSI and Neutron: my memory of that was that the follow-ups would be to review the actual use cases, and maybe adjust the ETSI specs to match existing Neutron workflows, where those already achieved the goal. | 16:33 |
| persia | The same could likely be done for Nova/Glance/etc., if anyone has time/interest in the coordination. ETSI folks are fairly flexible (although not everyone pushing a ETSI spec outside of ETSI might be an excellent demonstrator of that). | 16:34 |
| sdague | persia: yeh, well a good first start would be mapping out this relative to existing flows and figuring out where the mismatches were | 16:35 |
| persia | sdague: Yep. That's the person with time/interest bit :) | 16:36 |
| sdague | persia: well, that seems like the work that should be pushed back onto any team thinking that the only solution is a brand new openstack project | 16:36 |
| persia | Quite possibly, yes. It is often socially easier to create a new team than coordinate consensus between many folks and ensure that is implemented in an existing project though. I don't know the right answer for the current state of things, although I was happy to see more Neutron involvement with ETSI than in the past. My hope is that we see more of that with other projects, and maybe we won't need so many. | 16:39 |
| *** zhouyaguo has quit IRC | 16:39 | |
| *** cdent has quit IRC | 16:41 | |
| *** dtantsur|brb is now known as dtantsur | 16:46 | |
| *** jpich has quit IRC | 17:01 | |
| openstackgerrit | Mike Perez proposed openstack/project-team-guide master: Deprecating the cross-project team https://review.openstack.org/506311 | 17:05 |
| thingee | hey all, cross project spec repo patch from cdent is approved https://review.openstack.org/#/c/498860/1 | 17:06 |
| thingee | related, project team guide https://review.openstack.org/#/c/506311/ | 17:06 |
| ttx | flaper87: ccing you on https://review.openstack.org/#/c/505656/2 | 17:09 |
| ttx | (removing the channel check in irc-meetings) | 17:09 |
| mfedosin | dhellmann: hello :) You said: "I would like to observe that change for a while to see how it goes before approving." How long can "for a while" be? | 17:32 |
| dhellmann | mfedosin : in the meeting we talked about at least 1 cycle | 17:32 |
| dhellmann | well, not meeting, office hours earlier today | 17:33 |
| mfedosin | why this decision was made? | 17:34 |
| mfedosin | just because of the glaтce? | 17:34 |
| mfedosin | *glance | 17:34 |
| dhellmann | I can only speak for myself, but up to this point it has bothered me that the main goal for the glare team seems to have been to replace glance and possibly some other projects. | 17:35 |
| dhellmann | That is changing, but I want to see how things go now before I change my mind. | 17:36 |
| mfedosin | dhellmann: you are not right, of course, because it's clear that there are no plans to do so | 17:36 |
| dhellmann | no plans to change that goal? | 17:37 |
| mfedosin | to replace :) | 17:37 |
| dhellmann | so you're saying that all the times in the past that I thought the glare team proposed replacing glance with glare were a misunderstanding? | 17:37 |
| mfedosin | I mean there are a lot of application for glare in openstack | 17:38 |
| mfedosin | I think I wrote about it in my email... | 17:39 |
| dhellmann | If your position on that has changed, then that's what I mean. I want to see how things go now that the glare team is focusing on their own project, and not on replacing other projects. | 17:39 |
| mfedosin | when Flavio said that glance in critical condition I suggested to replace it with Glare | 17:39 |
| mfedosin | and again, it was a suggestion on how to improve things | 17:40 |
| dhellmann | Is that the only time it has come up? | 17:40 |
| dhellmann | yes, well, it was perceived as quite disruptive by many of us | 17:40 |
| mfedosin | now it seems glance is healthy | 17:41 |
| dhellmann | I'm not sure I would go that far, yet | 17:41 |
| sdague | also http://lists.openstack.org/pipermail/openstack-dev/2017-June/118251.html really doesn't support the idea that the glare team doesn't believe in replacing glance | 17:53 |
| sdague | that was 3 months ago, which is pretty recent | 17:53 |
| dhellmann | if the stance changed in the last few weeks, that's fine, but it means we need to see how it goes | 17:56 |
| thingee | mfedosin: yes I don't think glance is recognized at this point as being healthy as it's listed for our top 5 help needed https://governance.openstack.org/tc/reference/top-5-help-wanted.html | 17:56 |
| mfedosin | thingee: okay "not critical" | 17:58 |
| mfedosin | In the June's mail was sent as a reaction to the Flavio's message | 17:59 |
| thingee | Heh I consider that list as "state of emergency". flaper87 should remove it from there if he feels that comfortable. | 18:01 |
| thingee | mfedosin: | 18:02 |
| *** dtantsur is now known as dtantsur|afk | 18:08 | |
| *** lukebrowning has joined #openstack-tc | 19:15 | |
| *** cdent has joined #openstack-tc | 19:20 | |
| *** kumarmn has quit IRC | 20:54 | |
| *** lukebrowning has quit IRC | 20:55 | |
| *** mrhillsman has quit IRC | 21:47 | |
| *** evrardjp has quit IRC | 21:47 | |
| *** mrhillsman has joined #openstack-tc | 21:50 | |
| *** evrardjp has joined #openstack-tc | 21:52 | |
| *** cdent has quit IRC | 22:27 | |
| *** sdague has quit IRC | 22:34 | |
| *** kumarmn has joined #openstack-tc | 22:35 | |
| *** kumarmn has quit IRC | 22:36 | |
| *** kumarmn has joined #openstack-tc | 22:36 | |
| *** kumarmn has quit IRC | 22:57 | |
| *** hongbin has quit IRC | 23:23 | |
| *** kumarmn has joined #openstack-tc | 23:34 | |
| *** kumarmn has quit IRC | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!