KubeVirt Community, 2 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: KubeVirt Community Meeting 2022-02-02

Description

Meeting Notes: https://docs.google.com/document/d/1kyhpWlEPzZtQJSjJlAqhPcn3t0Mt_o0amhpuNPGs1Ls/

A

um Well, anyone else uh pulls up the dock, to block attendance and add stuff. Is there anyone that would like to introduce themselves today? So this is the first meeting of february, I'm glad to be back and able to host again.

A

I know I'd love to hear from anyone who maybe has started joining in the last few few weeks, while I've been out.

A

It looks like the activity on the.

A

Any pull, requests or bugs that need some extra attention be sure to drop those on and if there's no intros starting off today, we can go ahead and jump into.

A

The agenda bullet points.

B

A

Just start with.

B

The first point.

A

Yeah, it looks like that's you, roman.

B

Okay, um I just wanted to uh mention that uh we started some test improvements again on the end-to-end testing keyword like we found out that the end-to-end test cleanup is taking four to six seconds between every test and we're mostly just hitting the kubernetes rate gland side rate limiting here, and we can bring it down easily to under two seconds, I'm working on that and it exposes quite a lot of flaky tests again, so I'm still working through them and just a general reminder that if you are developing features- and you still have tests which are not running in parallel, yet it's worth looking into it.

B

It really helps cutting down the test times a lot to speed up ci for everyone so and if you're interested in the cleanup pr just have a look, um I'm covered from a review perspective just would give people the chance to look into it too. That's basically it from my side.

C

Roman, does the test usually run automatically in parallel or is.

B

It just a serial.

C

B

So when, when you're, when you're running a test, lane ginkgo is actually run two times. First, it's executing the c. The parallel tests, which are that are all tests which do not have the serial tag in the name, and then it has an exclusion and exclude regex on the second run, where it only runs the serial tests so that the parallel tests are not run again.

B

Or the other way around, basically serial tag means they are not running in parallel. No serial tag means they're run in parallel, and there are also some security checks in place like when you're in a parallel test modifying the keyboard configuration the test will fail because that's not allowed in parallel tests and so on. So it's pretty easy to do. Actually, I think and hope.

B

That's an answer, the question.

C

A

A

B

I have nothing else to do.

A

On the next um item it looks like you have some concern about issues being closed prematurely or without noticing. Why.

D

But there is a bottle that is closing them, but we have a problem that that, if I think we have a- I don't know if it's good or bad, but some it's for sure strange that an issue will be closed because no one is answering at the minimum should be that someone said it's not about not a problem. I don't have enough information and then it can be close yeah. It's.

B

Yeah, um so you are reacting basically to the last of the github bots reminder in that sense, so yeah yeah. So when I see a bug like this, I tend to ask if it's an issue and just yeah reopen.

E

B

Yeah but yeah in general, it's good that they get closed because you get a few reminders before it gets closed. It's a chance for everyone, us and the reporter to state again that the issue exists really yeah.

D

So so I think that the minimum should be that we acknowledge that it was accepted that someone is going to answer something and only then maybe trigger the timer, but uh and- and I'm not- I mean the problem- I I found it by me by mistake, because I saw some other issue that seems that we opened there were open like five issues that are talking almost the same thing and they were linking between each other, and one of them was linking to this one, which I saw that it was closed.

D

That's why I found it it's not like I'm. I was looking for something like that and so yeah. That's. Maybe we need like to think about this case where someone is opening the issue and he's not getting any response. So if the response is that the bot is selling it's going to be closed, but not so nice.

E

F

Hey, I think I think there are two sides to that right. On the one hand, of course, it's sad that no one even acknowledged this, uh this issue having having opened somehow- um and I think this is what we generally try to um try to focus on when we are doing box drops uh at the moment, or uh at least issue scrubs or whatever, how that's called.

F

I think it's box club yeah and the other thing is um that, of course, um when there is not much attention to an issue and the people of the before the the person that that opened.

F

That issue did not really ask again, probably somehow, then this might not be that at least I'm expecting that that this might not be that issue or that he might have been fixing being able to fix that himself and probably just didn't, follow up on his own issue, and so I think, after a while, when there is no activity on an issue, it's fair to close it somehow, and I think we even have uh even I think, 90 days or something when it's the first time declared stale.

D

Yeah, that's all I I I understand what your point I agree we did, but I agree I mean I want to agree with it only after someone in the organization says something. So if the after that that someone say something it's it's 90 days, obviously you're right, but if.

E

D

It it's like someone missed it and that's not his fault. I mean he can negate what maybe it's not like in a culture not.

F

Every culture will do.

D

It so it's uh yeah.

F

I I understand what you mean so maybe, and a quick idea that I have right now would be probably just to try uh to change the the filter that we have for the bug. Stop, maybe looking for uh issues who don't have any triage label somewhere.

F

That could at least be some kind of like just putting up new or untriaged issues again. So this would probably solve the problem.

A

Another thing I would be curious about is if we can maybe update the uh template, for, I guess, point directing people at um the slack or the mailing list in the event that they're unsure whether it's actually a bug or if it's more along the lines of like support and user configuration error type stuff, because a lot of the stale ones that I've seen are more user education than actual bugs, at least at first glance.

A

And I don't know that everyone who, who reports those is familiar with jumping onto the cooper itself,.

A

I don't know if that would be an un unwelcome flooding of the channel either.

D

You can always uh I mean the first. The boat can say that uh how to escalate it if there is no response or where to find more information, that's possible.

D

I think I don't know if we already do it actually, but but yeah by the way I wanted to make it like. I want to give the other side um so I had like. I was looking at the last week or two on the issues that and and some of them it's like the long long lost issues like the 90 days is too much for them. So my question is, is: do we have even a policy that let's say that we answered? We say?

D

I think this is one two three four and we can wait, for example a week for a response, and if there is no response just to close it is it can. We have some some rule.

E

D

This um because.

B

Yeah, I think I mean if you respond and the person which opened it is not responding anymore. It will close sooner or later. I don't see an issue, I mean it's not necessary. Sometimes the conversation is really. There is a clear end to conversation and then they get close, sometimes like yeah.

B

This is really we cannot help on this because you're building your own container, um then you can then sometimes we just close them and write feel free to reopen if you think we can still contribute, but in general, there's nothing interesting, but for the rest, if the person is just not answering the bot can take care of it. I think I don't think yeah.

D

D

So this is exactly so we sometimes we do have the answer. We just politely wait, uh for example a week and then close it and say you can reopen if you think otherwise, but there are some, uh there are some sometimes the cases where uh he didn't. I think.

B

Whatever you would do up there, they're not good enough, so I mean when you when you think there is nothing to add and it's clear that nothing can help. You can close it and just try it if you think this is wrong. Just reopen okay, okay, good! So.

E

B

E

D

No because, uh but if you're just leaving when the bot.

B

Will close it, I mean it's as simple as that.

D

Yeah the problem with the boat closing it is that the bot will close it after I think 90 days, which is like a huge amount of time, and then it's it's on you to monitor that uh I mean if.

G

You want to monitor it, you get yeah, you.

D

Can get github.

G

Notifications, emails.

F

G

Not sure that's.

F

An issue if I may chime in and the first thing that the bot does is it marks the issue stale after 90 days of inactivity and then the second thing that will then it will get rotten after another day, it's 30 days of inactivity and then after uh another. I think, let me let me have a have a look at that. Where is that I think another 30 days of even inactivity of a rotten issue? Then it closes it.

F

So I think, if uh 150 days with three reminders that your issue is stale or rotting or if that's not enough, then I'm not sure what we should do.

D

What I mean is what I mean is that I personally, if I want to maintain, to monitor my the some issues that I let's say, I'm a sign on. I really don't want them to rotten for half a year. I want them to be close, so I will not think about it, not see it in my list and not think about it. So.

E

If someone is not answering.

D

In a week or two, then that's it.

F

Yeah yeah sure, but if there is a change you know if this is.

E

F

If there is a change, you are getting reminded of that in the notifications.

F

So, for example, if you get a stale issue, you see that in your notifications and then you're free to act on that, you could rather directly close it. If you want or just leave it open and wait until the bot closes it. But that's your decision.

A

F

A

Onus of responsibility to bug openers as much as on the maintainers.

D

So, just to just make sure that I understand is it? Is it fine for me after I answer something that I think it's not not an issue from our side? Is it okay to close it after one week or two of no response myself.

F

Like with, I think, like roman said you can you can, if you think this is not an issue for us, you can just uh close it right away with.

E

You, for example,.

F

That like, uh if you think this is still an issue, then please reopen it, and I think this is fair right, because we don't have that much people. So I think we should at least try to keep the number of issues as low as possible.

D

Great. Thank you.

A

All right and alphabeen snapshot api feedback, but how's that pulled up here.

H

Do you want to speak to that? Hey everyone, um so I mentioned this briefly last week sent this message out and I said we'd discuss it here um haven't heard from anyone. um So maybe someone here uh has some feedback for the snapshot api.

H

um Basically, it's been in alpha for a while. It has been evolving slowly from uh you know, only doing supporting offline vms to now um it supports online vms with fs, freeze integration and it's pretty robust and we want to add even more functionality to it. But um you know it's still uh feature gated and we haven't heard much from the community about it, so um wondering what you guys think.

I

Here's a question um is the snapshot api adopted by red hat at this point and part of the product.

H

Yeah I mean it's, it's.

I

Yes, so it's gone through red hat's um quality process like internal quality process, and it's in like the downstream product as in users, can use it today.

H

Correct it is in the it is enabled uh by default and the downstream product we sell to people.

I

So, if we're going by the um kind of guidelines that I'm trying to work on as far as like incrementing things from or graduating things from alpha to beta that counts for end user uh well, it means a vendor technically but uh vendor or end user. Anyone who's adopted this and put it in production, and it's gone through um like another team, has looked and verified this works for them, so that would be red, hat's, qe or qa team.

I

I think that's, that's enough validation that this can go to beta.

H

Okay, yeah um yeah, I mean definitely, we've invested a lot in it at red hat and we want to do more. It would just be great to get some feedback. I know everyone kind of does their own. um Everyone seems to have their own backup strategy and restore strategy, and it's definitely not a one. Size fits all kind of thing, but you know any feedback would be great.

I

It's um did we document this well upstream, yet the snapshot api and like how it could be used, and things like that.

H

uh Well, they're they're defined. Well, I mean it's uh definitely in the user guide. I think it. It came along a little late because of just. um I think it was one of those things where it moved so slowly there was never a like okay. This is let's, let's really talk about this.

H

I think I think um we did a bad job of publicizing it, um and maybe uh it would make sense to um do a little more of that, maybe a convert blog post or something just to talk more about it, but I'm not exactly sure. I know that there's a user guide. um I should check the blog and see what you've got there.

I

Yeah I'm looking at right now.

D

I have, I have a question. Sorry, uh how is it, how is it.

E

Related or not related.

D

To the to the design that is proposed now about vm cloning.

H

Good question I haven't, I haven't seen the design about for vm cloning, but um it should be related. I assume that the clone cloning will um you can clone from a snapshot but yeah. If you could point me to that design, I'd love to take a look.

I

Yeah, I actually I pinged you on it. um I think, maybe a couple days ago, uh so it's in the community repo, it's one of the.

E

I

Proposals- and I I thought the same thing- uh that it's really closely related- um the snapshotting is really closely related to cloning and I kind of wonder so, I'm about to change the.

I

Do you care if we talk about the clone design, how it relates to snapshot right now, michael or did you need any more feedback.

H

uh No, I mean I I I yeah. Let's talk about it.

I

So I had a thought and I'm curious um we uh so for cloning and for snapshotting. I wonder if it all originates from the snapshot, so somebody takes a snapshot of a virtual machine and then whether you restore or you clone is the next app action. So you can restore that exact vm into the exact same object or a clone.

I

Action would be to take that snapshot and uh create a brand new virtual machine out of it, but it seems like if we take that approach, then the snapshot is the like entity that actions work on.

H

Yeah, that was my assumption. um That was my assumptions how it would work. Yeah, okay,.

I

Cool, so maybe that's the feedback for the clone design. Maybe we should be looking in that direction. Yeah.

H

I think the only um you know the the vm snapshot api. You know it will snapshot your manifests and any uh csi uh volumes. um You know, I think clearly it may fall a little short for uh people using storage that does not support um volume snapshots.

H

um So that would be, I think, one thing to maybe consider in the clone epic as well. If, if that, if that is sufficient,.

D

So just for what I remember from rev or uh from from over sorry the product. So there is a big difference.

E

D

Cloning and snapshotting in networking perspective, I don't know if it's taken care of in any any of the solutions. But if you clone a vm for networking, then you just don't clone the network part at all, because or maybe you you don't we don't clone the the parts that are specific to the, for example the markers that's the classic one and but on snapchatting. That's uh that's uh that's another story, because when you restore it you want it to continue from where it stopped. So you want to save the mac, but then it's there.

D

It goes even more complicated because you have this, uh for example, in incovit.

E

D

Cube magpul and then you need to to make sure it's not it's still reserved for you, it's not going to to someone else or some stuff like that, so it becomes more complicated a little bit. So in this regard, I'm saying it's a bit different.

H

Yeah yeah for sure yeah. They were definitely if, if you took a snapshot of vm snapshot of vma um to use that in a clone operation, you would have to you know mutate a lot of of the em specification.

H

Let's make it work.

H

But yeah, no, I'm excited for the clone. That clone is moving along and I'll. Take a look later.

A

All right: um okay, um that's everything! That's posted on the agenda and I don't see any open floor items. Does anyone have anything they want to speak up to on that? Also any pull requests or mailing lists items that we want to call out and dive into real quick feel free to add those ones.

A

A

All right, second,.

A

Apologies: okay! What with that.

A

Are we if you dismiss.

A

Going once going twice.

A

Thank you all for covering, in my outage and good to be back I'll, see you next week.

A

E

F

Bye-Bye bye, thank you. Bye.