| *** bhagyashris_ is now known as bhagyashris|ruck | 05:25 | |
| opendevreview | Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362 | 06:28 |
|---|---|---|
| opendevreview | Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363 | 06:28 |
| opendevreview | Yongli He proposed openstack/nova master: smartnic support - create arqs https://review.opendev.org/c/openstack/nova/+/758944 | 06:29 |
| opendevreview | Yongli He proposed openstack/nova master: smartnic support - build instance with smartnic arqs https://review.opendev.org/c/openstack/nova/+/798249 | 06:29 |
| opendevreview | Yongli He proposed openstack/nova master: smartnic support - cleanup arqs https://review.opendev.org/c/openstack/nova/+/798054 | 06:29 |
| opendevreview | Yongli He proposed openstack/nova master: smartnic support - reject server move and suspend https://review.opendev.org/c/openstack/nova/+/779913 | 06:29 |
| opendevreview | Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147 | 06:29 |
| *** xek_ is now known as xek | 07:25 | |
| *** rpittau|afk is now known as rpittau | 07:39 | |
| gibi | melwitt: I just saw your consumer type spec. I think I created a bad precedent with my RP re-parenting spec proposed in the nova-specs repo. | 08:41 |
| gibi | At that time I thought that there is no spec tracking in placement | 08:41 |
| gibi | but it turned out that there is ./doc/source/specs in the placement repository | 08:41 |
| gibi | so we have two ways forward. Make the placement spec directiory freezed and use nova-specs for placement specs too, or duplicate my RP re-parenting spec there and move you consumer type spec to there. | 08:44 |
| kashyap | sean-k-mooney: Hey, so I've got a Red Hat QE to do some migration tests w/ Cirrus and VirtIO - for Windows and Linux | 09:22 |
| kashyap | sean-k-mooney: It all "just works". In brief, this was the test: | 09:23 |
| kashyap | Have a Linux and Windows guest on source with 'cirrus', change the video model to 'virtio'; reboot the guest, and then live-migrate -- it succeeds just fine. | 09:25 |
| kashyap | sean-k-mooney: And thanks for the review; just saw that | 09:26 |
| *** akekane_ is now known as abhishekk | 09:38 | |
| sean-k-mooney | ok thats good to know for the new nova-manage command | 09:48 |
| opendevreview | Takashi Kajinami proposed openstack/placement master: Enable HTTPProxyToWSGI to look up actual remote address https://review.opendev.org/c/openstack/placement/+/800611 | 09:49 |
| opendevreview | Takashi Kajinami proposed openstack/placement master: Enable HTTPProxyToWSGI to look up actual remote address https://review.opendev.org/c/openstack/placement/+/800611 | 09:51 |
| opendevreview | Takashi Kajinami proposed openstack/placement master: Enable HTTPProxyToWSGI middleware to find actual client ips https://review.opendev.org/c/openstack/placement/+/800611 | 09:53 |
| opendevreview | Takashi Kajinami proposed openstack/placement master: Enable HTTPProxyToWSGI middleware to find actual client ips https://review.opendev.org/c/openstack/placement/+/800611 | 09:57 |
| opendevreview | Takashi Kajinami proposed openstack/placement master: Enable HTTPProxyToWSGI middleware to find actual client ips https://review.opendev.org/c/openstack/placement/+/800611 | 10:00 |
| opendevreview | Stephen Finucane proposed openstack/nova master: Use neutronclient's port binding APIs https://review.opendev.org/c/openstack/nova/+/706295 | 10:03 |
| stephenfin | gibi: ^ | 10:03 |
| stephenfin | gibi: Fixed the single failing test and addressed the mypy complaint so that should be green now. I'll remind melwitt when she's about too | 10:04 |
| gibi | stephenfin: ack, looking | 10:32 |
| * gibi loves the new gerrit to show in different color the changes between two patchsets due to rebase | 11:06 | |
| opendevreview | Takashi Kajinami proposed openstack/placement master: Enable HTTPProxyToWSGI middleware to find actual client ips https://review.opendev.org/c/openstack/placement/+/800611 | 11:21 |
| *** ricolin_ is now known as ricolin | 12:48 | |
| opendevreview | Lee Yarwood proposed openstack/nova master: WIP/DNM nova-manage: Introduce bdm show and refresh commands https://review.opendev.org/c/openstack/nova/+/800634 | 12:49 |
| ganso | lyarwood, bauzas: if you have a minute to spare could you please take a look at this last backport of the anti-affinity series? It already has a +2, just needs a +W: https://review.opendev.org/c/openstack/nova/+/800114 Thanks in advance! | 13:31 |
| opendevreview | Takashi Kajinami proposed openstack/placement master: Enable HTTPProxyToWSGI middleware to find actual client ips https://review.opendev.org/c/openstack/placement/+/800611 | 15:20 |
| *** mgoddard- is now known as mgoddard | 15:27 | |
| gibi | nova meeting starts in 12 minutes here in the channel | 15:48 |
| gibi | stephenfin: you might want to drop your -1 from https://review.opendev.org/c/openstack/project-config/+/798071 as you proposal was accepted last week on the meeting | 15:52 |
| stephenfin | done | 15:52 |
| gibi | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Jul 13 16:00:19 2021 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| gibi | o/ | 16:01 |
| stephenfin | o/ | 16:01 |
| sean-k-mooney | o/ | 16:02 |
| dansmith | o/ | 16:02 |
| elodilles | o/ | 16:02 |
| gmann | o/ | 16:02 |
| gibi | #topic Bugs (stuck/critical) | 16:03 |
| gibi | no critical bug | 16:03 |
| gibi | #link 14 new untriaged bugs (-11 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New | 16:03 |
| lyarwood | \o | 16:03 |
| gibi | thanks for the triage! | 16:03 |
| gibi | (whoever did it)( | 16:03 |
| gibi | is there any specific bug that we need to discuss? | 16:04 |
| gibi | #topic Gate status | 16:04 |
| gibi | Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure | 16:04 |
| stephenfin | nice! (bug triage) | 16:04 |
| * lyarwood did a little | 16:05 | |
| gibi | looking at the gate bug list I dont see new bugs there | 16:05 |
| stephenfin | subjectively, I'm still seeing a decent amount of nova-live-migration failures | 16:05 |
| stephenfin | though it does feel like it's slightly better | 16:05 |
| stephenfin | I'm assuming this is still the volume detach issue | 16:06 |
| lyarwood | I've not had a chance to look tbh | 16:06 |
| gibi | I had no time looking at the gate since the last meeting so I cannto commet | 16:06 |
| stephenfin | ah, sorry, that was more of a statement than a question | 16:06 |
| lyarwood | https://zuul.opendev.org/t/openstack/builds?project=openstack%2Fnova&branch=master&pipeline=gate&result=failure at least we haven't blocked anything | 16:07 |
| gibi | there is one gate fix from melwitt https://review.opendev.org/c/openstack/nova/+/800313 that needs a second core | 16:08 |
| lyarwood | https://zuul.opendev.org/t/openstack/builds?job_name=nova-live-migration&project=openstack%2Fnova&branch=master&pipeline=check&result=failure but yeah there's a number of LM failures in check | 16:08 |
| stephenfin | I'll grab that | 16:08 |
| gibi | stephenfin: thanks | 16:08 |
| tosky | related: the legacy jobs removal moved forward, the stable/train backport just requires a few small fixes: https://review.opendev.org/c/openstack/nova/+/795435 | 16:08 |
| stephenfin | thought I already had, tbh... | 16:08 |
| gibi | lyarwood: thanks for the links | 16:09 |
| elodilles | tosky: train is not blocked, do we need that backport there? | 16:09 |
| tosky | elodilles: I'd say it's worth it: it should help people who will keep on eye on that branch when a failure will happen | 16:10 |
| elodilles | i see.... it's just.... really not that nice of a patch :] | 16:12 |
| elodilles | for backport :X | 16:12 |
| gibi | elodilles: so far we backported that to newer stable branches to unblock gate there? | 16:13 |
| elodilles | well, it became like that in ussuri | 16:13 |
| elodilles | in newer branches it was a *bit* nicer | 16:14 |
| elodilles | but yes, we did backport it so far | 16:14 |
| elodilles | until ussuri | 16:14 |
| elodilles | since gate was broken back to ussuri | 16:14 |
| gibi | so the gate is OK in train, so this becomes a nice to have compared to ussure where it was a must have | 16:15 |
| gibi | anyhow I let the stable core team to decide | 16:16 |
| gibi | let me know if you stuck on deciding and need my final ruling :) | 16:17 |
| gibi | moving on | 16:17 |
| gibi | the placement gate status looks green | 16:18 |
| gibi | any other topic about the gate? | 16:18 |
| gibi | #topic Release Planning | 16:19 |
| gibi | Milestone 2 is Thursday (15 of July) which is spec freeze | 16:19 |
| gibi | we have couple of open specs | 16:19 |
| gibi | https://review.opendev.org/q/project:openstack/nova-specs+status:open | 16:19 |
| gibi | melwitt: has two re-propose specs that needs a second core | 16:19 |
| gibi | nova-audit https://review.opendev.org/c/openstack/nova-specs/+/800570 | 16:20 |
| gibi | and | 16:20 |
| gibi | consumer types https://review.opendev.org/c/openstack/nova-specs/+/800569 | 16:20 |
| gibi | these are pretty easy to get in before the deadline I think | 16:21 |
| gibi | there is one more spec with only positive feedback https://review.opendev.org/c/openstack/nova-specs/+/787458 | 16:21 |
| gibi | Integration With Off-path Network Backends ^^ | 16:21 |
| gibi | I sean-k-mooney said in the review that we wait for bauzas to review | 16:22 |
| gibi | but I think bauzas is already on PTO | 16:22 |
| stephenfin | he is | 16:22 |
| sean-k-mooney | i think part of the concern there is the neutorn apporval and ovn support | 16:22 |
| sean-k-mooney | we could approve it for this cycle but im not sure the depencies will line up before feature freeze | 16:23 |
| sean-k-mooney | so we could leave that to the implemantion reivew and be optimistic or defer | 16:23 |
| gibi | sean-k-mooney: could you please summarize this dependency complication in the spec review? | 16:23 |
| sean-k-mooney | until everyting is ready | 16:23 |
| *** rpittau is now known as rpittau|afk | 16:23 | |
| sean-k-mooney | gibi: its already captured in the review | 16:23 |
| gibi | ohh, cool then I missed that | 16:24 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/787458/9/specs/xena/approved/integration-with-off-path-network-backends.rst#654 | 16:24 |
| sean-k-mooney | we are not expecting the nova design to change | 16:24 |
| sean-k-mooney | but we likely want to wait for the depencies to be resolved before merging the nova code | 16:25 |
| sean-k-mooney | gibi: i agree on nova-audit and consumer types | 16:25 |
| sean-k-mooney | i think those could be progressed before spec freeze | 16:26 |
| gibi | sean-k-mooney: thanks, I will read the last part of the discussion in the spec tomorrow and then try to decide if I upgrade my vote | 16:26 |
| gibi | the rest of the open specs has negative feedback on them so they have small chance to land until Thursday but I will keep an eye on them | 16:26 |
| gibi | anything else about the coming spec freeze? | 16:27 |
| gibi | #topic Stable Branches | 16:28 |
| gibi | stable gates are not blocked | 16:28 |
| gibi | stable releases have been proposed: | 16:28 |
| gibi | wallaby: https://review.opendev.org/800475 | 16:29 |
| gibi | victoria: https://review.opendev.org/800476 | 16:29 |
| gibi | ussuri: https://review.opendev.org/800477 | 16:29 |
| gibi | EOM (from elodilles ) | 16:29 |
| * lyarwood has these open and will review before dropping for a few weeks later today | 16:29 | |
| gibi | I've already looked at the stable release patches and they look good to me. I will wait for lyarwood before approve | 16:29 |
| elodilles | lyarwood: thanks in advance :) | 16:29 |
| lyarwood | ack np, sorry I didn't get to them already | 16:30 |
| gibi | lyarwood: thanks! | 16:30 |
| gibi | anythin else on stable land? | 16:30 |
| elodilles | nothing from me | 16:30 |
| gibi | I'm skipping the libvirt subteam topic as we dont have bauzas | 16:31 |
| gibi | #topic Open discussion | 16:31 |
| gibi | nothing on the agenda | 16:31 |
| gibi | but I have one note | 16:31 |
| gibi | I sent out a doodle about the coming PTG | 16:31 |
| sean-k-mooney | ah i was going to ask about that i saw the ooo one | 16:32 |
| gibi | #link http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023560.html | 16:32 |
| gibi | in the ML thread I have a question about the amount of slots we would need | 16:32 |
| gibi | and also we have brand new PTG etherpad too https://etherpad.opendev.org/p/nova-yoga-ptg | 16:32 |
| sean-k-mooney | i do think that 4 days with 4 hour slot is likely better yes | 16:33 |
| sean-k-mooney | if it was in person we likely owuld do 3 8 hour slots - breaks | 16:33 |
| gibi | yeah my experience tells me we could use more time than 3x4 hours | 16:35 |
| sean-k-mooney | when do you need to inform the organisers | 16:35 |
| gibi | 21st of July | 16:35 |
| gibi | so next week | 16:35 |
| sean-k-mooney | ack | 16:35 |
| gibi | but I think I can always add more slots then remove it later | 16:35 |
| sean-k-mooney | yep | 16:36 |
| gibi | any other topic for today? | 16:36 |
| alistarle | Hello guys, concerning this blueprint https://review.opendev.org/c/openstack/nova/+/794837, do you have any question about it, and what is the next step ? | 16:36 |
| sean-k-mooney | looks liek lee has a -1 | 16:37 |
| * lyarwood clicks | 16:37 | |
| * gibi looks | 16:37 | |
| sean-k-mooney | has this been disucsed as a specless blueprint in the past | 16:37 |
| alistarle | Yep, but I already answer in previous comment I think, but I can sum up for lee I for sure | 16:38 |
| lyarwood | alistarle: yeah sorry did I miss the justification for this? | 16:38 |
| alistarle | What do you mean about a speechless blueprint ? Because yes, there is a blueprint for that: https://blueprints.launchpad.net/nova/+spec/configure-direct-snapshot | 16:38 |
| lyarwood | alistarle: I couldn't work out how you would be able to do this without manually flattening disks | 16:38 |
| gibi | sean-k-mooney: I think this is the time alistarle asks for the approval of the specless bp | 16:39 |
| sean-k-mooney | alistarle: that is a blueprint not a spec. a spec is a serate document that describe the usecase in detial and the design | 16:39 |
| sean-k-mooney | gibi: ack | 16:39 |
| sean-k-mooney | alistarle: can you summerise what you want to enable | 16:40 |
| alistarle | Sure, I want to make the direct snapshot feature configurable, because for now, nova will not honor the glance configuration when creating a snapshot, but trying to guess it from the actual nova backend | 16:40 |
| dansmith | what does that mean? "not honor the glance configuration" ? | 16:41 |
| sean-k-mooney | alistarle: is this a glance multistore envoinment? or a case where glance does not use ceph for storage? | 16:42 |
| alistarle | Let's say you 1. Store your image on ceph, and use copy on write to create VM, so you are storing your VM disk as images child in RBD, but during life of your cloud you want to move out from ceph. So 2. You remove your rbd backend from glance and put a swift one instead | 16:42 |
| alistarle | With this configuration, nova will never call glance to check which backend is enabled, and he will always store the snapshot in ceph, even if it is not a declared glance backend | 16:43 |
| sean-k-mooney | alistarle: are we talking about cinder volumes for the vm or the rbd image backend? | 16:43 |
| sean-k-mooney | in nova.conf | 16:43 |
| lyarwood | sean-k-mooney: rbd image backend | 16:43 |
| alistarle | It it for a case when you used RBD as a glance store, then you replace it with a swift one, and you want to progressively move out from ceph | 16:44 |
| sean-k-mooney | so the request is to flaten the snapshots effectivly in ceph and then have new shapshots go to swift | 16:44 |
| dansmith | alistarle: okay I thought I asked you this question on the spec | 16:44 |
| sean-k-mooney | alistarle: well one thing we do not support is changing the nova image_types backend | 16:44 |
| sean-k-mooney | including via a move operation like cold migrate | 16:45 |
| lyarwood | sean-k-mooney: you wouldn't, that doesn't control where the image is | 16:45 |
| dansmith | alistarle: maybe what you want is to be able to tell nova-compute which glance backend you want to snapshot to, to create a flattened snapshot in the desired store, which may not be the rbd one? | 16:45 |
| sean-k-mooney | lyarwood: well im aware of that but the usecase given was removing ceph | 16:45 |
| alistarle | I think it is a good catch dansmith | 16:45 |
| dansmith | telling it not to use rbd snapshotting "just because" is more confusing | 16:45 |
| lyarwood | dansmith: does Glance support moving images between backends? | 16:45 |
| dansmith | lyarwood: copying, yes, but that's not what I mean | 16:45 |
| lyarwood | sean-k-mooney: dropping rbd just for Glance AFAICT | 16:46 |
| sean-k-mooney | alistarle: is ^ the case | 16:46 |
| dansmith | lyarwood: I meant tell nova "specifically create a flattened snapshot and upload it to a specific glance backend" | 16:46 |
| sean-k-mooney | dansmith: that i think would be useful in other cases too | 16:46 |
| dansmith | lyarwood: I don't think glance really exposes parent-child relationships anyway, so you couldn't expect to copy/move a hierarchy between backends | 16:47 |
| sean-k-mooney | adding a glance store parater to the snapshot api i think woudl be resonable | 16:47 |
| dansmith | either way, | 16:47 |
| dansmith | I think it's quite clear that this can't be a specless bp :) | 16:47 |
| alistarle | So you think it is better to change the snapshot API to allow users to choose which glance backend to use to snap the image ? | 16:47 |
| alistarle | Yeah I see you point, for sure it will require a spec in that case | 16:47 |
| dansmith | alistarle: that's not what I was suggesting, although that might also be an option.. the problem is, many ops will *not* want users to choose the pathologically terrible option, which you seem to want :) | 16:47 |
| alistarle | But actually we will need to do the same code, so if a user explicitly specify a glance store, we need to bypass the direct_snapshot process | 16:48 |
| dansmith | I was suggesting a conf option for nova-compute to tell it "always snapshot to glance backend X" or something | 16:48 |
| dansmith | instead of letting a user choose | 16:48 |
| alistarle | Because as of now, rbd image_backend do not care about glance config, he will magically decide to use ceph because VM disk is stored in ceph | 16:48 |
| sean-k-mooney | i kind of dislike doing this per host but i guess a host level config might be useful for an edge deployment | 16:49 |
| sean-k-mooney | alistarle: correct although that is partly be desgin | 16:49 |
| alistarle | Oh I see, so instead of putting a config option to "disable direct snapshot", we put an option to "choose a glance backend" | 16:50 |
| alistarle | And if we specify this option, we skip the direct_snapshot to always call glance | 16:50 |
| sean-k-mooney | alistarle: well not nessisarly | 16:50 |
| sean-k-mooney | if the specifed backedn was ceph | 16:50 |
| dansmith | sean-k-mooney: letting users choose the backend on snapshot will mean they try all kinds of things that won't work or are terrible for performance | 16:51 |
| sean-k-mooney | then direct would stil make sense | 16:51 |
| sean-k-mooney | if the vm was backed by that ceph cluster | 16:51 |
| dansmith | sean-k-mooney: like a user who is currently on ceph always choosing the file backend, causing us to always flatten and upload when we shouldn't be | 16:51 |
| sean-k-mooney | dansmith: yes although i was wondiering if people woudl want to do that for data reducnace reasons | 16:51 |
| sean-k-mooney | e.g. normally backup to local edge site with a snapshot and ocationally do it to central site | 16:52 |
| dansmith | sean-k-mooney: I mean, it would be nice, but I think we'd need policy, defaults, and some sort of way to know which ones the compute can even talk to | 16:52 |
| dansmith | sean-k-mooney: yeah, but not backup from one edge site to another.. that would be terribad | 16:52 |
| dansmith | so we'd have to have some mapping of who can do what, etc | 16:52 |
| sean-k-mooney | ya which is not realy somethng a normal user woudl be aware off | 16:53 |
| dansmith | for sure | 16:53 |
| sean-k-mooney | so we have 2 pothtial host level cofnig options | 16:53 |
| sean-k-mooney | disableing direct snapshto whihc to me feels more like a workaround option | 16:53 |
| sean-k-mooney | and dansmith's glance backend option | 16:53 |
| sean-k-mooney | *glance store | 16:54 |
| dansmith | yup.. the former is a workaround for sure, and as we've noted here, hard to even grok what or why you'd want it, | 16:54 |
| sean-k-mooney | im a little concerned the host level glance store option will have implications for shelve and cross cell migration | 16:54 |
| dansmith | but the latter is at least useful for migrating in or out of some thing, or directing snapshots to an appropriate on- or off-site location depending | 16:55 |
| dansmith | sean-k-mooney: well, whatever the default is today already does, AFAIK | 16:55 |
| sean-k-mooney | i do think i prefer the store approch | 16:55 |
| sean-k-mooney | ya fair we just assume that glance is accable everywhere | 16:56 |
| gibi | we have 5 minutes left, is there any other topic today? if not the we can continue this of course | 16:56 |
| dansmith | spec on this for sure tho | 16:56 |
| gibi | the spec it is | 16:56 |
| gibi | then | 16:56 |
| gibi | alistarle: please note that we have spec freeze on Thursday for Xena | 16:57 |
| lyarwood | Quick one from me, I'm out for the next ~2 or so weeks, stephenfin is babysitting some stuff while I'm gone. | 16:57 |
| gibi | lyarwood: thanks for the headsup | 16:57 |
| gibi | if nothing else for today, then I will close the meeting but you can continue discussing the snapshot issue | 16:58 |
| gibi | than thanks for joining | 16:59 |
| gibi | #endmeeting | 16:59 |
| opendevmeet | Meeting ended Tue Jul 13 16:59:21 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-13-16.00.html | 16:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-13-16.00.txt | 16:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-13-16.00.log.html | 16:59 |
| alistarle | Sorry guy's I just miss the end of the meeting | 17:14 |
| melwitt | gibi: ack re: the consumer type spec, I'm happy to propose it in the placement repo, either way, lmk what you think | 17:15 |
| alistarle | So if I understand well I need to write a spec for that and freeze is Thursday, so it is dead for Xena right ? | 17:15 |
| melwitt | stephenfin: ack, will look at the update on your patch | 17:15 |
| sean-k-mooney | alistarle: it would be challanging to land by thursday yes | 17:19 |
| sean-k-mooney | alistarle: i would still suggest working on the spec and a poc of the implementaiton | 17:20 |
| sean-k-mooney | but likely it would be a yoga change at this point | 17:20 |
| sean-k-mooney | alistarle: im not sure if dansmith woudl agree but i could maybe see adding a [workarounds]disable_direct_snapshot=True|False config option as a bug in xena | 17:21 |
| dansmith | zI dunno, | 17:22 |
| sean-k-mooney | alistarle: but i think as a long term feature it would need a spec and that likely cant land in xena | 17:22 |
| dansmith | I was having a hard time seeing the value, and clearly lyarwood was as well | 17:22 |
| dansmith | it's definitely a workaround, but doesn't really fit what the workarounds conf section was supposed to be | 17:22 |
| sean-k-mooney | dansmith: so am i in that apprcoh but as a workaround option we could remvoe it in a sort period of time | 17:23 |
| dansmith | I think I'd rather see it done as a generally-useful thing to avoid landing the workaround and then never closing on it | 17:23 |
| sean-k-mooney | dansmith: i think we have a similar workaroud alredy | 17:23 |
| alistarle | Actually it is not really an issue for me to see it in Yoga if it need more work, my only concern is if I need to wait 6 month to work on it | 17:23 |
| sean-k-mooney | for live snapshots | 17:23 |
| dansmith | alistarle: you can work on it now, just don't expect to merge before Y opens | 17:23 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_libvirt_livesnapshot | 17:23 |
| alistarle | Oh I see, there is a dedicated workaround section | 17:24 |
| alistarle | But does the workaround section follow the same deprecation cycle than others ? | 17:24 |
| sean-k-mooney | alistarle: on no you would not need to wait 6 months | 17:24 |
| lyarwood | I'd be happy with another workaround to disable_live_directsnapshot with this replacement approach being worked on in Y | 17:24 |
| sean-k-mooney | we have actully just created the yoga spec folder | 17:25 |
| sean-k-mooney | so you could actully submit a spec to that folder for next cycle which we coudl review, and then you could work on the implemation to merge in early y | 17:25 |
| sean-k-mooney | althoguh we normally dont approve specs for the next release until later in the cycle | 17:26 |
| sean-k-mooney | alistarle: yes workaround follow the same dperecation cycle | 17:26 |
| sean-k-mooney | alistarle: although we have in the passed intoduced workarounds as deprecated imidetly | 17:27 |
| dansmith | if alistarle is fine with Y, then why not do it just once, in Y? | 17:27 |
| alistarle | Actually I don't really care about when it will be officially released, as I can backport my commit easily, I just hope we can freeze the implementation as soon as possible, so I will not backport a different commit in the future | 17:29 |
| lyarwood | If there's no pressing need in some env then yeah | 17:29 |
| sean-k-mooney | alistarle: you mean backprot downstream/out of tree | 17:29 |
| alistarle | Yeah exactly | 17:29 |
| sean-k-mooney | ok just makeing sure since as a blueprit or spec it would not qualify to backport upstream | 17:30 |
| sean-k-mooney | then can i suggest you submit a spec agaisnt the yoga specs directory and we can review it with Y in mind | 17:30 |
| alistarle | Ok fine, let's go for Y then, and dive the "glance store" option in nova_compute config then | 17:31 |
| sean-k-mooney | +1 | 17:31 |
| opendevreview | Lee Yarwood proposed openstack/nova master: WIP/DNM nova-manage: Introduce bdm show and refresh commands https://review.opendev.org/c/openstack/nova/+/800634 | 17:35 |
| lyarwood | stephenfin: ^ dumped some example output, need to help with bedtime then I'll try to clean the spec up this evening before I drop | 17:36 |
| -opendevstatus- NOTICE: Depends-On using https://review.opendev.org URLs are currently not working. This was due to a config change in Zuul that we are reverting and will be restarting Zuul to pick up. | 17:42 | |
| opendevreview | Merged openstack/nova master: Make test_archive_task_logs deterministic https://review.opendev.org/c/openstack/nova/+/800313 | 18:01 |
| stephenfin | melwitt: Could you also look at https://review.opendev.org/c/openstack/nova/+/794007/4 ? lyarwood is happy with it now | 18:16 |
| melwitt | stephenfin: ah, cool, I had been waiting for his ack. will do | 18:18 |
| opendevreview | Lee Yarwood proposed openstack/nova master: WIP/DNM libvirt: register device bus and model image properties https://review.opendev.org/c/openstack/nova/+/800708 | 18:25 |
| lyarwood | right, I'm out of here, catch you all in ~2 weeks hopefully! \o | 18:34 |
| sean-k-mooney | melwitt: am regarding https://review.opendev.org/c/openstack/nova-specs/+/800570 i thikn it would be better if we made all the time spans relitive ages insted of date ranges | 19:55 |
| sean-k-mooney | but other then that i still like the idea of this | 19:55 |
| opendevreview | Merged openstack/nova-specs master: Repropose: Support Consumer Types in placement https://review.opendev.org/c/openstack/nova-specs/+/800569 | 20:14 |
| NobodyCam | Good Afternoon Nova Folks | 22:16 |
| NobodyCam | looking for a little guidance on deleting an instance. I have a instance that is stuck in building. it shows up with openstack server list. But we get "No server with a name or ID" when attempting to run a server show.. would anyone be able to point me in the right direction to remove this | 22:19 |
| melwitt | stephenfin: sorry, still have one question from PS12 and a new question on PS14 https://review.opendev.org/c/openstack/nova/+/706295 | 23:55 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!