Thursday, 2017-09-21

*** cdent has quit IRC00:10
*** kumarmn has quit IRC00:17
*** openstackgerrit has quit IRC00:41
*** kumarmn has joined #openstack-tc02:18
*** kumarmn has quit IRC02:22
*** kumarmn has joined #openstack-tc02:25
*** kumarmn has quit IRC02:31
*** lbragstad has joined #openstack-tc03:00
*** lbragstad has quit IRC03:21
*** kumarmn has joined #openstack-tc04:32
*** kumarmn has quit IRC04:36
*** Rockyg has joined #openstack-tc04:46
*** Rockyg has quit IRC06:03
*** jpich has joined #openstack-tc06:58
*** ChanServ sets mode: +o openstack07:14
*** kumarmn has joined #openstack-tc09:32
*** kumarmn has quit IRC09:36
*** dtantsur|afk is now known as dtantsur11:02
*** sdague has joined #openstack-tc11:38
*** kumarmn has joined #openstack-tc13:20
*** kumarmn has quit IRC13:20
*** kumarmn has joined #openstack-tc13:20
*** rosmaita has joined #openstack-tc13:33
*** kumarmn has quit IRC13:43
*** kumarmn has joined #openstack-tc13:43
*** kumarmn has quit IRC13:55
*** kumarmn has joined #openstack-tc13:57
*** dtantsur is now known as dtantsur|brb14:20
*** hongbin has joined #openstack-tc14:43
*** kumarmn has quit IRC14:44
*** kumarmn has joined #openstack-tc14:45
*** kumarmn has quit IRC14:49
*** kumarmn has joined #openstack-tc14:50
smcginnisIt's that time again.15:00
* dtroyer looksa bout15:00
smcginnisSo there was some talk about simplifying our assert:supports-*-upgrade tags at the PTG.15:03
smcginnisWe have several that no one uses and are slightly confusing:
smcginnisShould we propose removal of some of them?15:03
ttxsomeone suggested a ping list on -dev15:04
* ttx tries that15:04
* smcginnis wonders if a notes etherpad could be useful15:05
dhellmannsmcginnis : it sounds like maybe we should, although I'd have to think more about what exactly we'd do differently15:05
* johnthetubaguy lingers15:06
dimshey thanks for the ping ttx15:06
smcginnisI 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
dimsdhellmann : thanks for the governance dashboard update15:07
dhellmanndims : 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
ttxdhellmann: we have no project with docs:follows-policy at this point. Is that tag still useful?15:08
dhellmannttx: pkovar and the docs team are going to be redefining that tag shortly15:08
dhellmannredefining or replacing15:09
ttxplease everyone review the project additions so that we can make fast progress on those15:11
dhellmannwhat's the general opinion on glare? I see sdague's comment about the potential for conflict15:12
ttxdims: you were in that room right?15:13
ttxrosmaita was pretty confident that would not conflict that much15:13
dimsttx : yes i was in the room when we talked to glare folks15:13
ttx(by the time I got there it was over)15:13
dhellmannmy impression from the meeting with the glance team is that they'd stop talking about replacing glance, but I'm still unclear about conflict elsewhere15:13
dhellmannat one point they were talking about replacing barbican, for example15:13
*** zhouyaguo has joined #openstack-tc15:14
dhellmannand I'm not sure I see how glare is different from swift, is it just the indexing?15:14
ttxah, missed that one15:14
ttxglare can use swift as backend15:14
fungias 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 complies15:14
smcginnisI think they got the message to focus on their own use cases and not make it a goal to replace anything.15:14
dhellmannI'd have to look in the archives to find that reference, it was a while ago15:14
dimssmcginnis : yep, agree15:14
*** openstackgerrit has joined #openstack-tc15:14
openstackgerritSean McGinnis proposed openstack/governance master: Remove assert:supports-zero-impact-upgrade tag
smcginnisfungi: In that case... ^^15:14
dhellmannbut if their use cases are actually to do the same thing that's being done elsewhere?15:14
ttxdhellmann: at least if they were under governance we would have some leverage, currently they can just compete with everything and create confusion15:15
dimsdhellmann : during the new project review, all of us were clear about where they should be focusing on (NOT glance replacement)15:15
smcginnisdhellmann: They had some slightly different "image serving" requirements when it came to NFV.15:15
dhellmannsmcginnis , 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
smcginnisdhellmann: ++15:15
fungidhellmann: my comment was more to do with the upgrade tags some of which seem to not actually have any projects which meet their requirements15:16
ttxfungi: just posted that suggestion on the skiplevel thread15:16
dhellmannfungi : yep, just throwing it out there since the docs tag was mentioned too15:16
fungiitym fastforward! ;)15:16
ttxdhellmann: ack, also not removing the maint-mode tag either15:16
dhellmannsmcginnis : 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
smcginnisWe do have a Trove request for that one at least.15:16
ttxand searchlight15:17
dhellmannI thought I saw a maint-mode request for another project, too. Designate?15:17
dhellmannthat's it15:17
smcginnisdhellmann: 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
sdaguemy 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 feet15:17
dimsy nokia15:18
fungion 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 glare15:18
dhellmannthat 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
sdaguemanaging 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 while15:18
ttxsdague: we could ask for "more history of graciously cooperating"15:18
dhellmannsdague : moral or morale?15:18
smcginnisrosmaita: Around? Any comments on the glance/glare meeting last week?15:19
dhellmannboth, I guess, but which did you mean? -- ok15:19
rosmaitai'm trying to put a comment on that patch atm15:19
dimssdague : we should ask the glance team what they though about the interactions with glare team this time around15:19
dimshey rosmaita15:19
ttxI just fear that delaying them will get us further from what we want there15:19
ttxwhich is good collaboration15:19
sdaguedims: we could, but I also think that it's kind of the important job of the TC to step in in situations like this15:19
rosmaitawell, a history of gracious cooperation as ttx said would be nice15:20
dimssdague : yes, we had a good conversation, several of us in TC with the glare team15:20
sdaguerosmaita: sure, I just don't even want to put the glance team on the hook to feel preasured to grade the glare team right now15:20
dimsthen me/ttx went and talked to both glance and glare team together15:20
rosmaitai think sdague said it best earlier, about technical space vs moral space15:21
sdagueI 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 glare15:21
dimssdague : y that's fair15:21
sdaguewhich to me means a solid year of not having anyone else intruding there15:21
sdagueand evaluate in a year15:21
ttxSomething like "reconsider for Rocky"15:21
sdagueyeh, I wouldn't even want to do that that soon, personally15:22
dhellmanngiven 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 direction15:22
ttxa year sounds a bit long to me15:22
ttxwhich btw.... mordred we need a Berlin based name15:22
sdagueI think it's way more important to have a strong glance team than another related effort15:22
smcginnisRocky seems reasonable to me. And if situations have not changed, OK to defer another cycle.15:22
dimsi'd like to revisit in 6 months and ask glance team what they think at that time15:22
sdagueso my bias is strongly on giving glance pretty strong protections15:23
dhellmannwe do still have the glance team on our top 515:23
sdaguedhellmann: ++15:23
dimsright dhellmann15:23
rosmaitai don't know that not approving glare will protect glance all that much15:23
dhellmannrosmaita : would it make things worse?15:23
rosmaitait's not like the glare devs will suddenly start working on glance15:23
ttxI feel like we have been stringing them for long already, but ok to live by a 6-month "more history of graciously cooperating" delay15:23
mordredttx: yah- berlin name on my list15:23
dhellmannrosmaita : I don't think that's what any of us expect15:24
rosmaitathe problem has been the confusion about what the glance/glare relationship is15:24
mordredttx: I'm vamping on it because I think we need to set up our own CIVS server before we do another naming poll15:24
dimsttx : agree15:24
smcginnismordred: OpenStack Steglitz ;)15:24
rosmaitaand the glare team has not been helpful in that regard15:24
mordredttx: as the last time it took over a week to send out emails and we STILL didn't get them all sent out15:24
sdaguerosmaita: 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
mordredttx: quick sake of argument - what if we ditched foundation member rule for this and just did an open poll?15:25
mordredttx: no emails needed, whoever wants to vote can vote15:25
dhellmannreally, Schlitz15:25
smcginnisSchützenstraße, then no one else will know how to pronounce it.15:25
rosmaitasdague ++ for Schnitzel15:25
ttxsmcginnis: too long15:25
sdaguealso, ascii15:26
mordredttx: send the poll link to openstack@ and openstack-dev@ - and hell tweet it15:26
fungiprobably 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 later15:26
smcginnisfungi: ++15:26
* dhellmann mordred : as long as we vet the list of names15:26
* dhellmann wonders what is going on with his irc client15:26
ttxmordred: allows for ballot stuffing though15:27
fungiand 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 unchecked15:27
ttxmordred: more concerned by someone voting 10000 times than by a random person voting15:27
fungiwhich seems like a disingenuous move15:27
smcginnisMy 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
sdaguesmcginnis: what is that use case?15:28
fungimordred: we _used_ to just do an open poll (through launchpad i think) didn't we?15:28
smcginnissdague: There is a special format and accessiblility needs to items within that format that NFV deployments need.15:28
ttxfungi: required LP, so prevented ballot stuffing15:28
sdaguesmcginnis: can you be more specific?15:28
dhellmannthere's something about a multi-part image format, isn't there?15:29
smcginnissdague: 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
fungittx: sure, just pointing out that we used to let anyone (with a lp account) vote rather than limiting it to foundation members15:29
dhellmannsmcginnis : that matches my vague memory of what I was told15:29
ttxfungi: ack15:30
sdaguesmcginnis: for what situation? That's a specific behavior, but I think I need to see the use case through to end user results15:30
dhellmannthat goes deeper than I remember15:30
smcginnissdague: 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
sdaguehere 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 worked15:31
dhellmannit bothers me that a key case for glare is related to images, if we're saying they shouldn't be focused on competing with glance15:31
sdaguevs. thinking about the end user / operator results, and the natural ways to acheive and extend them in the existing system15:31
sdaguedhellmann: ++15:31
rosmaitaglare can unpack the stuff and create regular glance images15:32
sdaguewhich also mirrored my experience working on the Carrier Grade Linux group at OSDL 10 years ago15:32
dhellmannrosmaita : what triggers that?15:32
rosmaitanothing now15:32
fungithe glare sales push starting at (follow that thread) seemed to me like they were shopping around for use cases to make them relevant15:32
rosmaitathey are not designing that way15:32
dhellmannis glare acting as a front-end for managing images in glance15:32
rosmaitano, by "can" i meant "could"15:33
* dhellmann if we say no to glare, what is the likelihood that 15:33
sdagueI'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
dhellmannif we say no to glare, what is the likelihood that someone will want those features added to glance?15:34
rosmaitadon't know15:34
dhellmanngiven the team priorities, I can't imagine any work on those things happening any time soon15:34
dhellmannpriorities and constraints15:34
sdaguewell, 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
rosmaitayeah, "on the fly" would probably be unreasonable given the size of most images15:36
fungiwhich ended up implemented via the tasks api in many places15:36
dhellmannyep, that and lots of other things15:36
rosmaitafungi right, there's a task for conversion15:36
sdaguerosmaita: or convert on upload15:36
sdagueanyway, we're getting a little off track15:36
dhellmannyeah, s/on the fly/transparently/15:36
rosmaitasdague right, that can be done with the import flow15:36
openstackgerritMatthew Treinish proposed openstack/governance master: Add api interop assert tag to ironic
openstackgerritMatthew Treinish proposed openstack/governance master: Add api interop assert tag to nova
sdaguerosmaita: ok, cool15:36
rosmaitawell, "can" in the sense of "it's possible"15:36
sdaguerosmaita: right15:36
rosmaita(we're still working on it)15:37
dhellmannI'd be interested in seeing what other approach could be taken to solve the nfv case15:37
dhellmannthe image format thing15:37
fungii'm still a little worried about the mutability of images and failure to check/update checksums... has that been getting any better?15:37
sdaguefungi: there is some signing stuff being proposed to nova for checking signed images15:38
dhellmannI'm still on the fence about glare, but I'm leaning toward a no, I guess15:38
fungifor example, with user-specified locations, multiple image locations, et cetera15:38
sdaguefungi: sure, there is a ton of interesting work15:38
sdagueand glance is rebuilding a team15:38
rosmaitafungi the image locations stuff is a mess15:38
sdagueand I want to give them all the space in the world to address that stuff first15:38
fungiyup, just wondering where the rebuilt team's priorities are focused15:38
rosmaitawe are reconsidering how to deal with all that15:38
*** mfedosin has joined #openstack-tc15:39
sdaguebut 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
rosmaitafungi: as long as you don't expose image locations to end users, you are ok15:39
dhellmannthe two teams do seem to have come to an agreement, but I can see sdague's point15:39
openstackgerritSean McGinnis proposed openstack/governance master: Remove assert:supports-accessible-upgrade tag
mfedosinhey! I need some time to read the logs15:40
mfedosinif you have questions about glare - please ask15:40
fungicoupling 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/deprecated15:40
dhellmannrosmaita : did the team come up with ideas for recruiting help?15:40
sdagueI would also really like to see the full use case work flow for this special image feature15:40
sdaguebecause, I expect that it didn't get enough "or you could solve this problem the following way"15:41
* dhellmann nods15:41
sdaguecyborg 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 written15:41
sdagueand saying "or.... you could solve it this other way"15:42
sdagueand now they are running in that direction, which also lets them address the GPU case which is really important15:42
dims++ sdague15:42
dhellmannare any of the other new projects controversial in anyone's mind?15:45
mordredfungi, 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 ever15:45
dimsmogan may be dhellmann15:45
dhellmannhow does stackube relate to magnum?15:45
mordreddhellmann: I think stackube fits a different space15:46
* dhellmann awaits more detail15:46
fungii'm getting increasingly confused by the proliferation of container-related teams (approved and proposed)15:46
sdaguealso, is magnum still a thing?15:46
mordredmagnum is "boot me a COE" - stackube is, iirc, "use kubernetes to get me a VM" - and could potentially be used as a novabackend15:46
dhellmannfungi : me, too15:46
dimsdhellmann : 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 that15:46
mfedosinsorry, for interruption. I think I should put the link here. It's about storing VNF packages in Glare:
ttxmordred: hmm, not exactly15:47
dimsdhellmann : it can do baremetal in the future. they don't expect operators to layer over an existing openstack15:47
dimswhich is magnum's view15:47
dhellmannthe 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
ttxStackube is actually a way to deploy a multitenant Kubernetes cluster on top of Cinder/Neutron and Keystone15:47
*** cdent has joined #openstack-tc15:47
dhellmanndims : what does "do bare metal" mean?15:47
dhellmannso stackube is a k8s deployment tool?15:48
ttxdhellmann: no, more of a set of patches and technologies to make it run on top of OpenStack15:48
ttx(in a multitenant manner)15:48
mordredttx: oh- I got my projects wrong then15:49
ttxit would belong in that "adjacent technology enablers" box from the map I showed15:49
dhellmannI'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
ttxwith Kuryr and Fuxi15:49
mordredttx: sorry - I was thinking about kubevirt15:49
sdaguefungi: your confusion on the number of containers solutions isn't limitted to that in the openstack space15:49
dimsdhellmann : there's a picture
ttxdhellmann: it's specific to openstack15:49
mordredyah - stackube seems kind of like bifrost to me15:49
sdaguethey are kind of popping up like javascript frameworks, one every few weeks15:49
fungimfedosin: 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 there15:49
dimsdhellmann : they don't rely on nova at all for anything15:49
mordreddo a deployment of a thing which isn't fully openstack but is built out of openstack pieces15:50
ttxso it's more of a layer to run K*s on top of openstack15:50
ttxthink of it as the layer letting you plug kubernetes on top of cinder/neutron/keystone15:50
dhellmannon top of parts of openstack?15:50
dimsnew components in kubernetes that make sure of openstack to provide services is more like it15:50
fungimfedosin: 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 everyone15:51
ttxin a single-cluster, multi-tenant manner15:51
dimslike setting up networking for kubernetes nodes using neutron15:51
dhellmannI 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
dhellmannbecause as it stands the application looks incomplete15:51
dhellmannthough I haven't read through the comments15:51
ttxdhellmann: they did provide some of that during the in-person review15:51
ttxbut asking to include them in co;;it ;essage sounds fair15:52
dhellmannok. I think I'd like to see it in writing, since I wasn't able to attend15:52
ttxstill learning that us keyboard15:52
sdagueI'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
mordredsdague: ++ 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 thing15:55
dhellmannlet's not get too NIH15:55
ttxsdague: yeah, feels like this would belong better in a more "NFV" product line if we ever create one. We could move tacker to it, too15:55
mordredthe 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 implement15:55
mordredbut 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 thing15:56
mordredI 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 it15:57
sdaguettx: or even more importantly, first try really hard to figure out mapping it to existing things.15:57
mordredwhat a meta thought trian15:57
sdaguebecause 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 Y15:57
mordredrosmaita: have we ever discussed the infra/nodepool image upload/replace use case with you?15:58
rosmaitamordred nope, we should have that discussion15:59
mordredrosmaita: 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
mordredrosmaita: cool - I'll see if I can write something up for you15:59
mordredrosmaita: 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 one16:00
rosmaitamordred we call that "image lifecycle management"16:00
mordredrosmaita: we do that today with an external database and uploading all the images using unique ids - so the imageis ubuntu-xenail-{uuid} to glance16:01
mordredrosmaita: yah. image lifecycle management indeed :)16:01
rosmaitathere's a brief discussion on the ML, and also a product wg spec that didn't go anywhere, i will find links for you16:02
mordredrosmaita: 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 who16:03
mordredwanted to use those images16:03
* mordred stops co-opting the tc room for infra/glance discussion16:03
fungiwell, 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 plans16:05
*** rosmaita has quit IRC16:22
persiaOn 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
persiaThe 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
sdaguepersia: yeh, well a good first start would be mapping out this relative to existing flows and figuring out where the mismatches were16:35
persiasdague: Yep.  That's the person with time/interest bit :)16:36
sdaguepersia: well, that seems like the work that should be pushed back onto any team thinking that the only solution is a brand new openstack project16:36
persiaQuite 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 IRC16:39
*** cdent has quit IRC16:41
*** dtantsur|brb is now known as dtantsur16:46
*** jpich has quit IRC17:01
openstackgerritMike Perez proposed openstack/project-team-guide master: Deprecating the cross-project team
thingeehey all, cross project spec repo patch from cdent is approved
thingeerelated, project team guide
ttxflaper87: ccing you on
ttx(removing the channel check in irc-meetings)17:09
mfedosindhellmann: 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
dhellmannmfedosin : in the meeting we talked about at least 1 cycle17:32
dhellmannwell, not meeting, office hours earlier today17:33
mfedosinwhy this decision was made?17:34
mfedosinjust because of the glaтce?17:34
dhellmannI 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
dhellmannThat is changing, but I want to see how things go now before I change my mind.17:36
mfedosindhellmann: you are not right, of course, because it's clear that there are no plans to do so17:36
dhellmannno plans to change that goal?17:37
mfedosinto replace :)17:37
dhellmannso 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
mfedosinI mean there are a lot of application for glare in openstack17:38
mfedosinI think I wrote about it in my email...17:39
dhellmannIf 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
mfedosinwhen Flavio said that glance in critical condition I suggested to replace it with Glare17:39
mfedosinand again, it was a suggestion on how to improve things17:40
dhellmannIs that the only time it has come up?17:40
dhellmannyes, well, it was perceived as quite disruptive by many of us17:40
mfedosinnow it seems glance is healthy17:41
dhellmannI'm not sure I would go that far, yet17:41
sdaguealso really doesn't support the idea that the glare team doesn't believe in replacing glance17:53
sdaguethat was 3 months ago, which is pretty recent17:53
dhellmannif the stance changed in the last few weeks, that's fine, but it means we need to see how it goes17:56
thingeemfedosin: yes I don't think glance is recognized at this point as being healthy as it's listed for our top 5 help needed
mfedosinthingee: okay "not critical"17:58
mfedosinIn the June's mail was sent as a reaction to the Flavio's message17:59
thingeeHeh I consider that list as "state of emergency". flaper87 should remove it from there if he feels that comfortable.18:01
*** dtantsur is now known as dtantsur|afk18:08
*** lukebrowning has joined #openstack-tc19:15
*** cdent has joined #openstack-tc19:20
*** kumarmn has quit IRC20:54
*** lukebrowning has quit IRC20:55
*** mrhillsman has quit IRC21:47
*** evrardjp has quit IRC21:47
*** mrhillsman has joined #openstack-tc21:50
*** evrardjp has joined #openstack-tc21:52
*** cdent has quit IRC22:27
*** sdague has quit IRC22:34
*** kumarmn has joined #openstack-tc22:35
*** kumarmn has quit IRC22:36
*** kumarmn has joined #openstack-tc22:36
*** kumarmn has quit IRC22:57
*** hongbin has quit IRC23:23
*** kumarmn has joined #openstack-tc23:34
*** kumarmn has quit IRC23:56

Generated by 2.15.3 by Marius Gedminas - find it at!