| opendevreview | Takashi Kajinami proposed openstack/python-novaclient master: Use Block Storage API v3 instead of API v2 https://review.opendev.org/c/openstack/python-novaclient/+/802417 | 02:00 |
|---|---|---|
| *** rpittau|afk is now known as rpittau | 07:29 | |
| MrClayPole | Time appropriate greetings, we have a company policy for all network and compute devices have their timezone set to UTC time. The issue we have is that during the summer in the UK we have our clocks set to UTC+1. Our Windows servers are currently booting with clock 1 hour in the past. Is there a way for libvirt/nova to track our timezone while keeping Ubuntu 18.04 set to UTC time? | 08:40 |
| lyarwood | MrClayPole: are you using os_type=windows for the images? | 08:43 |
| lyarwood | https://bugs.launchpad.net/nova/+bug/1231254 a slightly old bug but I wonder if it still applies | 08:43 |
| lyarwood | https://libvirt.org/formatdomain.html#time-keeping would be how libvirt controls this FWIW | 08:45 |
| lyarwood | https://github.com/openstack/nova/blob/1c490ecd7be5722c6cfdaddfacc8d7a5539dd035/nova/virt/libvirt/driver.py#L5792-L5806 is where we switch to localtime when os_type=windows | 08:46 |
| lyarwood | instead of utc | 08:46 |
| lyarwood | ah right but your hosts remain on UTC so that isn't useful | 08:47 |
| MrClayPole | lyarwood: We are running OpenStack rocky, as you said the os_type didn't help but it's interesting that libvirt xml supports a timezone. Can this be set from Nova? | 08:56 |
| lyarwood | MrClayPole: not at the moment AFAICT, we have all of the config code just no way for a user to request it | 08:57 |
| MrClayPole | I wondering if the best way forward might just be to have an exception for our compute nodes so they can bet set to "Europe/London" rather than UTC | 08:59 |
| lyarwood | Yeah for your env on Rocky that would be for the best | 08:59 |
| lyarwood | For the Yoga OpenStack release we could easily add an image property to control the timezone directly | 09:00 |
| MrClayPole | That would defo be useful to us so we can revert the compute nodes back to UTC. | 09:02 |
| stephenfin | bauzas: gate fix for novaclient here if you have 2 | 09:15 |
| stephenfin | https://review.opendev.org/c/openstack/python-novaclient/+/802417 | 09:15 |
| bauzas | stephenfin: we have a gate issue ? | 09:16 |
| stephenfin | Yes, a very slight one due to cinderclient's removal of cinder API v2 | 09:16 |
| stephenfin | Spotted after reading through Takashi Kajinami's email to openstack-discuss ("[all] Broken gate caused by Block Storage API v2 removal") | 09:16 |
| bauzas | stephenfin: any bug y'know ? | 09:16 |
| bauzas | ahah | 09:16 |
| stephenfin | lots of related patches available also https://review.opendev.org/q/topic:%22volumev2-removal%22+(status:open%20OR%20status:merged) | 09:17 |
| bauzas | I just read the email, I don't see failing jobs | 09:18 |
| bauzas | hah | 09:18 |
| lyarwood | stephenfin: ACK'd the novaclient change | 09:19 |
| stephenfin | ty! | 09:19 |
| bauzas | are we sure that the v3 client supports the same than for the v2 ? | 09:20 |
| bauzas | lyarwood: ^ | 09:21 |
| lyarwood | bauzas: yeah it does | 09:21 |
| bauzas | ok, I was a bit afraid of just using the new version without making sure it wasn't creating problems for us | 09:22 |
| bauzas | but if it doesn't change our client API, fair enough | 09:22 |
| lyarwood | https://docs.openstack.org/api-ref/block-storage/api_microversion_history.html#maximum-in-mitaka | 09:22 |
| lyarwood | The 3.0 Cinder API includes all v2 core APIs existing prior to the introduction of microversions. The /v3 URL is used to call 3.0 APIs. This is the initial version of the Cinder API which supports microversions. | 09:22 |
| sean-k-mooney | it looks like in most cases the convertion to v3 is trivial as a result | 09:26 |
| bauzas | lyarwood: thanks | 09:26 |
| sean-k-mooney | MrClayPole: im not sure th at nova should really provide a facility to set a timezone | 09:29 |
| sean-k-mooney | at least not at the host level provbly not ant the image or flaovr level. although im more open to the image idea | 09:29 |
| sean-k-mooney | if we were to suprot settign a time zone i think i would want it to be per instance hosetly but really i think that woule be better handeles withine the workload | 09:30 |
| sean-k-mooney | just always set your host to utc | 09:30 |
| sean-k-mooney | and in windows set the timezone appropreiately if needed | 09:31 |
| CeeMac | sean-k-mooney: thats exactly the issues we have at the moment though. The host is set to utc and windows seems locked to that, so during DST the guest still runs -1 hour instead of updating. | 09:32 |
| CeeMac | i must confess I'm a little perplexed as I was expecting the os_type=windows to resolve the issue, but this doesn't appear to be the case | 09:32 |
| sean-k-mooney | CeeMac: you should be able to set the time in windows the clock source will by utc | 09:35 |
| sean-k-mooney | but in windows itself you can change the local | 09:35 |
| CeeMac | sean-k-mooney: yes, "should" appears to be the main issues here as that was my expectation, but the results don't appear to support this :( | 09:36 |
| sean-k-mooney | are you saying if you go into the region settign in windows it does not work? | 09:36 |
| sean-k-mooney | CeeMac: that sound like a windows bug you should report to microsoft | 09:36 |
| CeeMac | our guest VMs are all set to BST (UTC+1) and the system clock is reporting UTC+0 times, so they're all an hour in the past | 09:36 |
| sean-k-mooney | in a cloud enviornemt you cannot know the timezone of the tenant | 09:37 |
| sean-k-mooney | so you shoudl always be abel to set it indepenently of the host | 09:37 |
| CeeMac | it appears to be a known issue around how windows handles time from the bios clock, which i believe is the entire premise on why the os_type=windows patch was ported from hyper-v hypervisor to kvm hypervisor in nova | 09:37 |
| sean-k-mooney | CeeMac: for what its worth i hate daylight saving time so im glad ill by on utc permently next year | 09:37 |
| CeeMac | sean-k-mooney: yeah, thats the dream! | 09:38 |
| CeeMac | yeah, can't say I'm a big fan either. its those pesky customers who are complaining :) | 09:38 |
| sean-k-mooney | well os_type=windows does other things too | 09:38 |
| sean-k-mooney | but that patch yes | 09:38 |
| sean-k-mooney | although when we use os_type=windows it shoudl enabel the hyperv clock | 09:39 |
| CeeMac | from what I gather, there is a reg hack that resolves the problem, but microsoft wont support it and say it is "buggy", whatever that means | 09:39 |
| sean-k-mooney | which clock is this changing | 09:39 |
| sean-k-mooney | we have multipel clock source i think in the vm | 09:39 |
| sean-k-mooney | CeeMac: why not set the windows vms to utc | 09:40 |
| CeeMac | i've seen the <timer name='hypervclock' present='yes'/> | 09:40 |
| CeeMac | get added to the clock offset stanza for instances with os_type=windows | 09:40 |
| sean-k-mooney | you can disable DST in them | 09:40 |
| sean-k-mooney | CeeMac: ill pretend your not altering the xml :) | 09:41 |
| CeeMac | sean-k-mooney: its ok, i'm not, i'm just looking at it with dumpxml | 09:41 |
| CeeMac | :) | 09:41 |
| sean-k-mooney | so we have offset and timezone https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L703-L705 | 09:42 |
| CeeMac | so, the issue we're looking at currently, is a hosted platform for a customer clocking / time management systems. Presumably they want/need the clock in / clock out times to register against the correct regional time for accurate reporting | 09:42 |
| sean-k-mooney | and then we add the hyperv clock source https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5840-L5844 in addation to the pit, rtc and optionally the hpet | 09:44 |
| sean-k-mooney | CeeMac: right but the normal way to do that is to use UTC and then do the conversion client side | 09:45 |
| sean-k-mooney | you should never store data in local time | 09:45 |
| CeeMac | tbh, until we came across this issues it was always my belief that the windows kernel ran in utc natively and just adusted 'user' time based on the regional settings | 09:46 |
| sean-k-mooney | you enither use unix time or some other utc reference time like isotime format | 09:46 |
| CeeMac | but windows | 09:46 |
| CeeMac | appears to be the issues | 09:46 |
| sean-k-mooney | CeeMac: i belive it does with a different epoc | 09:46 |
| CeeMac | as its chose to use the 'localtime' standard, if you can call it a standard | 09:46 |
| CeeMac | stupid windows | 09:46 |
| sean-k-mooney | CeeMac: i think windows expect the hardware time to be in utc | 09:46 |
| CeeMac | i think more stick poking is required | 09:47 |
| CeeMac | thanks sean-k-mooney we'll have a ponder and see if we can see whats happening, or not happening as the case may be | 09:48 |
| sean-k-mooney | https://libvirt.org/formatdomain.html#time-keeping | 09:49 |
| CeeMac | thanks, thats an interesting read. | 09:51 |
| sean-k-mooney | so reading that localtime should give you what you wanted i think | 09:52 |
| CeeMac | yeah, that was our theory. Perhaps we're missing something in the os | 09:52 |
| sean-k-mooney | we can use timezone since we can only update that on reboot so you woudl have to reboot your vms evey 6 months | 09:52 |
| CeeMac | i presume there is no easy way to insert the additional track and catchup information? | 09:53 |
| sean-k-mooney | we could maybe use variable | 09:53 |
| sean-k-mooney | its not currently exposed in nova no | 09:53 |
| sean-k-mooney | this is getting more speicic then im comfortable exposing in a cloud env by the way | 09:54 |
| CeeMac | all the data suggests that it should work, as you say | 09:54 |
| sean-k-mooney | we might expsoe it but im not sure we should in general | 09:54 |
| CeeMac | no thats fine, i get that. It must be working for other people, otherwise I'm sure there would be more chat out there for it not working | 09:54 |
| sean-k-mooney | <clock offset='varible' basis='localtime'> | 09:54 |
| sean-k-mooney | we cold maybe try that | 09:55 |
| sean-k-mooney | *could | 09:55 |
| sean-k-mooney | CeeMac: if we were to expose the timer settign i think it woudl ahve to be at teh image level rghat then host by the way | 09:57 |
| CeeMac | sean-k-mooney: yes, that would make sense | 09:57 |
| sean-k-mooney | CeeMac: host level config that modify the xml are basicaly terribel form a live migration standpoint as we havne to schdule on it or pass the data or both | 09:57 |
| sean-k-mooney | so this type of info really needt to live with the instnace for its lifetime hence flavor or image | 09:58 |
| sean-k-mooney | with that said i woudl be tempeted to start using server metadata for this personally | 09:59 |
| sean-k-mooney | since this is a very pet like tuning | 09:59 |
| CeeMac | it makes sense that it should follow the instance | 09:59 |
| CeeMac | windows is all about the pet sadly | 09:59 |
| CeeMac | server metadata would be useful i think | 10:01 |
| sean-k-mooney | we dont currently allow it to modify xml exctra but i have always wondered if we should allow it to set anything that is setabel via image metadata | 10:02 |
| sean-k-mooney | that would require a spec and some semi invasive changes to parts of the libvirt driver | 10:03 |
| CeeMac | in some scenarios it could be beneficial, especially if its discovered you need to retrofit a value that would normally only be doable through an image | 10:03 |
| sean-k-mooney | so not sure its worth it | 10:03 |
| CeeMac | its still a very pet mentality granted | 10:03 |
| CeeMac | hmm, cost/benefit are skewed i guess | 10:04 |
| sean-k-mooney | CeeMac: ya we are adding a nova-manage command that operators can use for a limit set of image properties | 10:04 |
| CeeMac | oh, that sounds interesting | 10:04 |
| sean-k-mooney | the intent is for operators taht need to change things for upgrades | 10:05 |
| sean-k-mooney | e.g. move to q35 which means you have to remove use of ide | 10:05 |
| sean-k-mooney | ectra | 10:05 |
| sean-k-mooney | we approved https://github.com/openstack/nova-specs/blob/master/specs/newton/approved/virt-image-props-boot-override.rst in the past but then decieded to no porceed with it when we came to implemenation | 10:06 |
| sean-k-mooney | im still somewhat open to that idea but i dont fully recal what the main objects were | 10:07 |
| CeeMac | i imagine its tricky finding a decent balance point between stability and the ability to make dynamic changes | 10:07 |
| sean-k-mooney | ya and stricking a blance between upstream and downstream | 10:08 |
| sean-k-mooney | downstream our hands are forced a bit by change made by other teams | 10:08 |
| sean-k-mooney | for example qxl graphic is going away downstream so we have to provide a way to move instances off it which is what propmeted the change | 10:09 |
| sean-k-mooney | CeeMac: this is the new nova-magage command by the way https://github.com/openstack/nova-specs/blob/master/specs/xena/approved/nova-manage-commands-to-update-libvirt-device-models.rst | 10:25 |
| sean-k-mooney | CeeMac: lyarwood is currently workign on it for xena | 10:25 |
| CeeMac | looks good | 10:28 |
| opendevreview | Merged openstack/python-novaclient master: Use Block Storage API v3 instead of API v2 https://review.opendev.org/c/openstack/python-novaclient/+/802417 | 10:46 |
| opendevreview | Merged openstack/nova master: Bump os-resource-classes to 1.1.0 https://review.opendev.org/c/openstack/nova/+/800976 | 11:13 |
| opendevreview | Merged openstack/os-vif master: add configurable per port bridges https://review.opendev.org/c/openstack/os-vif/+/798055 | 11:50 |
| *** akekane_ is now known as abhishekk | 12:31 | |
| brinzhang | gibi,sean-k-moonkey,stephenfin,alex_xu: we submited the PoC code for allowing PMEM's data wihle migrate vm, but it is not completely implemented in accordance with the spec, because some irrationality in the spec was discovered during the implementation process, so we hope you can review the PoC code. | 12:34 |
| brinzhang | ah, gibi has a holday(pto), gibi_pto | 12:35 |
| brinzhang | the PoC code link: https://review.opendev.org/c/openstack/nova/+/802225 | 12:36 |
| sean-k-mooney | brinzhang: do you have a patch to update the spec whith what diverged | 12:36 |
| sean-k-mooney | brinzhang: what exactly was teh "irrationality in the spec" it may have been stated that way for a reason which the impleation misses | 12:37 |
| brinzhang | sean-k-mooney: in spec we want to ask ensure which pmem we can copy in the target host when run migtate_disk_and_power_off, but this time we cannt know the target pmem's path in the context | 12:40 |
| sean-k-mooney | yes we can | 12:41 |
| brinzhang | https://review.opendev.org/c/openstack/nova-specs/+/785563/14/specs/xena/approved/allow-migrate-pmem-data.rst#65 | 12:41 |
| sean-k-mooney | its includeded in the instance claim if i recall correctly | 12:41 |
| brinzhang | we test and write the logs, and we cannt get the target PMEM's path from the context | 12:41 |
| sean-k-mooney | ill have to review but i was pretty sure i pointed to the code where you could get it at one point | 12:43 |
| brinzhang | not exectly, it's cannot claim it now, now we just get the pmem's path when we were started if I wasn's missed some key info | 12:43 |
| sean-k-mooney | no | 12:43 |
| sean-k-mooney | it must claim it before you do the data copy | 12:44 |
| sean-k-mooney | you cannot pass back paths to unclaimed devices | 12:44 |
| sean-k-mooney | that is a potential securrity bug | 12:44 |
| brinzhang | yes, hope we were wrong, you can review the PoC code and give some points, thanks | 12:46 |
| sean-k-mooney | prep_resize should have claimed the remote pmemdevices and store them in the migration context | 12:46 |
| sean-k-mooney | brinzhang: i can but since it deviates form the spec im -1 untill you can show why the spec wont work | 12:46 |
| sean-k-mooney | why did you not save the pmem device in the migration context in prep_resize | 12:47 |
| sean-k-mooney | we create a resize claim here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5153-L5156 | 12:48 |
| brinzhang | yeah, it looks like he jumped the prep_resize, so he cannot get the target pmem's info | 12:52 |
| sean-k-mooney | right now the claims dont claim the pci devices | 12:53 |
| sean-k-mooney | * pmem devcies | 12:53 |
| sean-k-mooney | but the intent of the spec was to extend it to do that | 12:53 |
| sean-k-mooney | which can be sotre either in the claim direclty or we can update the migration or migration context | 12:53 |
| sean-k-mooney | we hvae access to both | 12:54 |
| brinzhang | as I know, the VM only knows the path information of the PMEM after it is started, otherwise the VM does not know what the PMEM patch used inside the virtual machine is (e.g. /dev/pmem0) | 12:56 |
| brinzhang | may this is my confusing | 12:56 |
| sean-k-mooney | i dont belive that is correct | 12:56 |
| sean-k-mooney | we must know the path before we start the vm since we need to specify the path in the vm xml | 12:57 |
| brinzhang | right | 12:57 |
| sean-k-mooney | and we cannot copy any data untile we have claimed the devcie because other wise we coudl race with a differnte vm and that could be a security bug or at least a data loss bug | 12:58 |
| brinzhang | yes, if it's right we will lost the datas in pmem | 12:59 |
| brinzhang | I will check the prep_resize tomorrow | 13:00 |
| brinzhang | may it need to claim the pci devices in resource tracker | 13:01 |
| sean-k-mooney | im currenlty trying to figure out why it does not appear to be doign that although i may have missed it | 13:02 |
| sean-k-mooney | i tought it was doing that already | 13:02 |
| sean-k-mooney | but yes when we aquire the instnace clam or move claim it should for cold migration at least | 13:03 |
| sean-k-mooney | for live migration we explitly claim the neutron pci devices in the pci tracker | 13:03 |
| sean-k-mooney | we do not use move claims for that | 13:03 |
| sean-k-mooney | for pmems though you will need to cliam them in the resouce table in the db | 13:04 |
| brinzhang | yes, we shuold claims it firstly before cold migrate the instance | 13:05 |
| sean-k-mooney | yep because we want to abort the migration if we cant claim | 13:07 |
| sean-k-mooney | this is why we insited the spec be written the way it currently is | 13:08 |
| sean-k-mooney | brinzhang: the poc wont work by the way | 13:12 |
| sean-k-mooney | brinzhang: ill push comments in a second but its using processutiles incorrectly | 13:13 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/802225/1/nova/virt/libvirt/driver.py#10757 | 13:13 |
| brinzhang | it's ok, I agree your point, and I think firstly we should claim the pmem devices in prep_resize interface, and then check it when we want to execute migrage_server then to copy date form source pmem to the target pmem devices | 13:13 |
| sean-k-mooney | well if the claim fails then the migration shoudl go to error and the vm will stay in active | 13:14 |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova stable/queens: libvirt: Skip encryption metadata lookups if secret already exists on host https://review.opendev.org/c/openstack/nova/+/765774 | 13:15 |
| brinzhang | sean-k-mooney:ok, hope you can review if you find the error in that patch, we will update and try to update in next patch | 13:16 |
| sean-k-mooney | the issue is the 3 commands in _migrate_vpmem_data will all execute on the same host. to fix it you need to pipe the output of the first commadn into the input of the second and the second and third commands should be combined | 13:19 |
| brinzhang | agree, I saw your comment, it's useful to improve efficiency | 13:21 |
| sean-k-mooney | well it wont work the way it is now | 13:28 |
| sean-k-mooney | it might work on the same host but both daxio command woudl execute on the local host | 13:28 |
| brinzhang | ack, it should be update, in local we have tested the CLI, it works fine | 13:32 |
| sean-k-mooney | if you use those comand on the cli it would wokr but only because the second comamdn will put you in a new shell on the dest | 13:33 |
| sean-k-mooney | to emulate this on the cli you need to rune each exec in a new terminal | 13:33 |
| brinzhang | ack | 13:33 |
| *** akekane_ is now known as abhishekk | 14:19 | |
| bauzas | reminder : nova meeting in 47 mins-ish here in #openstack-nova | 15:12 |
| opendevreview | Merged openstack/nova stable/ussuri: Reject open redirection in the console proxy https://review.opendev.org/c/openstack/nova/+/791806 | 15:17 |
| opendevreview | Stephen Finucane proposed openstack/nova master: Cleanup 'drop_move_claim' and '_drop_move_claim' https://review.opendev.org/c/openstack/nova/+/747747 | 15:29 |
| opendevreview | Stephen Finucane proposed openstack/nova master: manager: Address TODO https://review.opendev.org/c/openstack/nova/+/747748 | 15:29 |
| opendevreview | Stephen Finucane proposed openstack/nova master: manager: Move context manager up one level https://review.opendev.org/c/openstack/nova/+/745674 | 15:29 |
| opendevreview | Stephen Finucane proposed openstack/nova master: compute: Add type hints for resize functions https://review.opendev.org/c/openstack/nova/+/745341 | 15:29 |
| opendevreview | Stephen Finucane proposed openstack/nova master: WIP: compute: Add more type hints for resize functions https://review.opendev.org/c/openstack/nova/+/745675 | 15:29 |
| opendevreview | Stephen Finucane proposed openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'Migration' https://review.opendev.org/c/openstack/nova/+/723572 | 15:48 |
| opendevreview | Stephen Finucane proposed openstack/nova master: objects: Remove 'NovaObjectDictCompat' from 'InstancePCIRequest' https://review.opendev.org/c/openstack/nova/+/723573 | 15:48 |
| opendevreview | Stephen Finucane proposed openstack/nova master: Remove use of pkg_resources https://review.opendev.org/c/openstack/nova/+/740661 | 15:50 |
| bauzas | last reminder : nova meeting in 10 mins here in this chan. Sharpen your pencils. | 15:50 |
| opendevreview | Stephen Finucane proposed openstack/nova master: api: Improve extra spec validator help texts https://review.opendev.org/c/openstack/nova/+/782412 | 15:56 |
| stephenfin | lyarwood: Can you look at https://review.opendev.org/c/openstack/nova/+/773640/ and https://review.opendev.org/c/openstack/nova/+/797513/ seeing as you're +2 on patches later in the series | 15:57 |
| stephenfin | also addressed your comments on https://review.opendev.org/c/openstack/nova/+/782412 | 15:58 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Jul 27 16:00:05 2021 UTC and is due to finish in 60 minutes. The chair is bauzas. 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 |
| stephenfin | o/ | 16:00 |
| bauzas | howdy folks I'll be your chair for this meeting given our Supreme Leader is on vacations | 16:00 |
| bauzas | \o | 16:00 |
| sean-k-mooney | o/ | 16:00 |
| bauzas | awesome, one more people from the last meeting I chaired \o/ | 16:01 |
| bauzas | agenda is up at https://wiki.openstack.org/wiki/Meetings/Nova | 16:01 |
| elodilles | o/ | 16:01 |
| bauzas | feel free to add items you wanna discuss in the last section above ^ | 16:02 |
| bauzas | moving on now | 16:02 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| bauzas | No Critical bugs | 16:02 |
| bauzas | #link 11 new untriaged bugs (+1 since the last meeting): #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New | 16:02 |
| bauzas | I'll try to look at some of them tomorrow | 16:02 |
| bauzas | any other bugs people wanna raise ? | 16:03 |
| stephenfin | nope, we had a gate issue due to Sphinx 4.x but sean-k-mooney fixed that for us | 16:03 |
| bauzas | we could have had a cinderclient bug, but the v3 change is now merged, right? | 16:04 |
| bauzas | stephenfin: excellent, thanks sean-k-mooney | 16:04 |
| sean-k-mooney | ya i think that is merged now | 16:04 |
| stephenfin | Yes, the nova one landed last week and the novaclient one went in earlier today | 16:04 |
| bauzas | oki doki | 16:04 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/802334 | 16:04 |
| bauzas | were we limiting the cinderclient version ? | 16:04 |
| sean-k-mooney | that was the nova one | 16:05 |
| sean-k-mooney | bauzas: no we jsut had a refernce to v2 | 16:05 |
| bauzas | ok | 16:05 |
| sean-k-mooney | replced it with v3 | 16:05 |
| bauzas | anyway, moving | 16:05 |
| bauzas | #topic Gate status | 16:05 |
| bauzas | Nova gate bugs #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure | 16:05 |
| bauzas | #topic Gate status | 16:06 |
| bauzas | meh, maybe the meetbot works with the #topic section | 16:07 |
| bauzas | anyway | 16:07 |
| bauzas | nothing to say about any gate issue ? | 16:07 |
| stephenfin | nope, not beyond the above | 16:07 |
| bauzas | I can see a new one from lyarwood https://bugs.launchpad.net/nova/+bug/1938021 | 16:07 |
| sean-k-mooney | we are still using the tempoary workaround for the ovsdb issue. ill try and find out how the ovs change is comming before m3 but no other update on that | 16:08 |
| sean-k-mooney | hum interesting | 16:08 |
| melwitt | I have noticed while working on placement consumer types that a generation conflict gets hit on my patches, let me find the (old) gate bug | 16:08 |
| sean-k-mooney | was tehre a new olo release | 16:08 |
| bauzas | sean-k-mooney: good question | 16:09 |
| melwitt | this one http://bugs.launchpad.net/bugs/1836754 | 16:09 |
| sean-k-mooney | bauzas: the messging issue might be related to something moving and we are nolonger mocking properly in the func tests | 16:10 |
| bauzas | melwitt: heh, who is working on this one ? | 16:10 |
| melwitt | it occurs in general too but while working on placement to do more during a PUT it makes it happen a lot more. so a heads up that I think we'll need to address that before placement consumer types will be usable | 16:10 |
| sean-k-mooney | although perhaps not it is corectly using the fake implementation. | 16:10 |
| bauzas | melwitt: oh it's you | 16:11 |
| sean-k-mooney | huh i could see that conflict happening alright | 16:11 |
| melwitt | bauzas: I have restored mriedem's old patch about the bug and will add tests to it for review | 16:11 |
| bauzas | do we have race conditions for this a lot ? (the conflict) | 16:11 |
| melwitt | yeah, it was originallly from tssurya and cdent but both moved off of openstack before it was finished so I've been working on finishing it | 16:11 |
| bauzas | or is it just for a few job runs ? | 16:12 |
| melwitt | bauzas: I have seen it on other patches yes, but not nearly as often as I do on the placement patches. on the placement patches it looks pretty much guaranteed | 16:12 |
| sean-k-mooney | well im not sure the frequency matteers with the scale we run at its goign to block patches at least temporaly and require a recheck | 16:12 |
| sean-k-mooney | so i think we should try an fix it sooner rather then later | 16:13 |
| bauzas | melwitt: so we get a conflict when deleting the allocation but why are we getting an exception ? | 16:13 |
| bauzas | the allocation should just be orphaned, that's it | 16:13 |
| melwitt | just wanted to give everyone a heads up about it because back when the fix was proposed, it there was a lot of discussion on the review. so if anyone has concerns about DELETE for most allocations cases rather than PUT, comment on the review | 16:13 |
| bauzas | melwitt: sure, will review your change if you want | 16:14 |
| melwitt | because it was changed to a PUT instead of a DELETE when consumer generations were added | 16:14 |
| bauzas | ah shit, I see | 16:14 |
| melwitt | it's mriedem's change that I'm going to complete | 16:14 |
| bauzas | melwitt: thanks for working on it either way | 16:14 |
| sean-k-mooney | melwitt: wait deleting an allocation was chgange to a put? | 16:14 |
| sean-k-mooney | because what delete dont have a body and we did not want to include the consomer generation in the query arg? | 16:15 |
| bauzas | sean-k-mooney: https://review.opendev.org/c/openstack/nova/+/688802/2/nova/scheduler/client/report.py#b2107 | 16:15 |
| melwitt | here's the review https://review.opendev.org/c/openstack/nova/+/688802 | 16:15 |
| melwitt | sean-k-mooney: yes, https://review.opendev.org/c/openstack/nova/+/591597 | 16:15 |
| melwitt | sean-k-mooney: I don't know, tbh | 16:15 |
| bauzas | sean-k-mooney: we now call put() | 16:15 |
| sean-k-mooney | well that by itself is a bug | 16:16 |
| melwitt | I tend to agree | 16:16 |
| sean-k-mooney | we should not use put for delete and im not convince we need to even include the generation version | 16:16 |
| bauzas | let's discuss this after the meeting, if people want | 16:16 |
| sean-k-mooney | sure | 16:16 |
| bauzas | but I tend to agree too | 16:16 |
| bauzas | I need to understand the *why* for put | 16:17 |
| bauzas | so looking at the original change | 16:17 |
| bauzas | anyway | 16:17 |
| bauzas | moving on | 16:17 |
| bauzas | Placement periodic job status #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly | 16:17 |
| melwitt | the only thing you get with PUT is if you issue a delete of your instance, if someone else updates it while it's deleting, you have a chance to reconsider your decision to delete it. afaik that might be the reasoning | 16:17 |
| bauzas | melwitt: yeah, that's what I think too | 16:18 |
| bauzas | for a race | 16:18 |
| bauzas | anyway | 16:18 |
| melwitt | yeah sorry, can move on | 16:18 |
| bauzas | about the placement periodic job, well, we merged stuff | 16:18 |
| sean-k-mooney | ya that is what i assuem too but i dont think that is the right design choice if we delete it we shoudl just delete it | 16:18 |
| bauzas | last week | 16:18 |
| bauzas | now the job looks to work | 16:18 |
| bauzas | (we merged a now o-r-c) | 16:18 |
| bauzas | *version | 16:18 |
| sean-k-mooney | o-r-c | 16:19 |
| sean-k-mooney | ?? | 16:19 |
| sean-k-mooney | oh os-resouce-classes | 16:19 |
| sean-k-mooney | yes | 16:19 |
| sean-k-mooney | placment was updated to account for the new os-resource-class release | 16:20 |
| bauzas | yeah, sorry was triying to find the patch | 16:20 |
| bauzas | https://review.opendev.org/c/openstack/placement/+/796595 | 16:20 |
| bauzas | anyway, nothing to tell more | 16:20 |
| sean-k-mooney | one thing we might want to consider it preparing the patch when we are preparing the release | 16:21 |
| bauzas | except maybe https://zuul.openstack.org/build/0e135bb912b240c8bc2aa96049727a1a | 16:21 |
| sean-k-mooney | we know we have to do this every time we release it so we can prementivly submit the placment patch with a depens on the releases repo patch | 16:21 |
| bauzas | oh nevermind, was fixed by the above | 16:21 |
| bauzas | sean-k-mooney: you mean the placement release patch ? | 16:22 |
| sean-k-mooney | yep | 16:22 |
| bauzas | for m-3 ? | 16:22 |
| sean-k-mooney | yes | 16:22 |
| sean-k-mooney | well | 16:22 |
| sean-k-mooney | when we go to release o-r-c again | 16:22 |
| sean-k-mooney | we can prepare a patch to placment for it | 16:23 |
| sean-k-mooney | to update the canary test and have it ready to go by depending on the pathch to the release repo | 16:23 |
| bauzas | well, generally this is made by the release mgmt team but we can surely prepare it | 16:23 |
| sean-k-mooney | im not sure if we will have anothger o-r-c release at m3 | 16:23 |
| sean-k-mooney | they will open the patch if we dont but they ask the ptl to approve | 16:24 |
| sean-k-mooney | so at that point we can just do the house keeping patch for placnement and preappove ti so it will merge wehen the release patch does | 16:24 |
| bauzas | they ask either the release folk or the PTL, yup :) | 16:24 |
| sean-k-mooney | anyway we can move on just a tought | 16:24 |
| bauzas | sean-k-mooney: keep your thought for next week when we get our ptl back | 16:25 |
| bauzas | moving on | 16:25 |
| bauzas | time is flying | 16:25 |
| bauzas | Please look at the gate failures, file a bug, and add an elastic-recheck signature in the opendev/elastic-recheck repo (example: #link https://review.opendev.org/#/c/759967) | 16:25 |
| bauzas | #topic Release Planning | 16:25 |
| bauzas | We past M2 and spec freeze. M3 is in 5 weeks. | 16:26 |
| bauzas | We have 21 approved an open blueprints and we have 5 weeks to finish them. Please focus review effort on bps in Needs Code Review state. | 16:26 |
| bauzas | that reminds me, people have to make sure their blueprint is on Needs Code Review | 16:26 |
| bauzas | #link https://launchpad.net/nova/+milestone/xena-3 | 16:26 |
| bauzas | the delivery status doesn't really mean anything but that can help reviewers to know which series to look at | 16:27 |
| bauzas | so, if you love reviews, you know what to do | 16:27 |
| bauzas | Next deadline is non-client library freeze at 16th of August | 16:28 |
| bauzas | think about it for os-resource-class ;) | 16:28 |
| bauzas | moving on | 16:28 |
| bauzas | #topic PTG Planning | 16:29 |
| bauzas | PTG timeslots booked by gibi, see #link http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023787.html | 16:29 |
| bauzas | The PTG etherpad is ready to be filled with topics: #link https://etherpad.opendev.org/p/nova-yoga-ptg | 16:29 |
| bauzas | If you see a need for a specific cross project section then please let gibi know | 16:29 |
| bauzas | I'm pretty sure this etherpad will be filled before we have the PTG :) | 16:30 |
| bauzas | #topic Stable Branches | 16:30 |
| bauzas | elodilles: flood is yours | 16:30 |
| bauzas | floor* | 16:31 |
| bauzas | (oh man) | 16:31 |
| elodilles | stable gates are not blocked | 16:31 |
| elodilles | :) | 16:31 |
| elodilles | at least as far as I can tell | 16:31 |
| bauzas | excellent, excellent :D | 16:31 |
| bauzas | tbh, this is not really time of the cycle when I look at stable changes | 16:31 |
| elodilles | not so much activity around stable branches (M2, M3, vacations, etc...) | 16:31 |
| bauzas | yup, most of the team efforts are focused on feature delivery as we speak, I guess | 16:32 |
| elodilles | bauzas: true :) | 16:32 |
| bauzas | moving on | 16:32 |
| bauzas | #topic Sub/related team Highlights | 16:32 |
| bauzas | Libvirt (bauzas) | 16:32 |
| bauzas | bauzas: floor is your | 16:32 |
| bauzas | bauzas: thanks | 16:32 |
| bauzas | bauzas: nothing to report, sir. | 16:32 |
| bauzas | bauzas: thanks. | 16:33 |
| bauzas | moving on. | 16:33 |
| bauzas | #topic Open discussion | 16:33 |
| bauzas | I refreshed and nothing popped in the wikipage while we were speaking | 16:33 |
| bauzas | so, nothing to say on this today, unless someone wanna raise something now | 16:34 |
| stephenfin | nope | 16:34 |
| bauzas | (I guess my fake dialog frightened a lof of people who disappeared) | 16:34 |
| bauzas | oh wow, at least someone stayed \o/ | 16:34 |
| bauzas | I'm not that bad actor | 16:35 |
| sean-k-mooney | can we ever really leave | 16:35 |
| bauzas | I could just pretend I'll keep the stick for the whole hour and prevent you to use this channel for the last 25 mins | 16:35 |
| sean-k-mooney | i dont have anything more for today | 16:35 |
| bauzas | privilege of the power, whahahah | 16:35 |
| bauzas | but, heh, | 16:36 |
| bauzas | #stopmeeting | 16:36 |
| bauzas | #endmeeting | 16:36 |
| opendevmeet | Meeting ended Tue Jul 27 16:36:53 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:36 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-27-16.00.html | 16:36 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-27-16.00.txt | 16:36 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-27-16.00.log.html | 16:36 |
| bauzas | even | 16:36 |
| sean-k-mooney | melwitt: bauzas do you want to chat about the allocation delete issue | 16:37 |
| bauzas | sean-k-mooney: I guess I need to look at the original change | 16:37 |
| sean-k-mooney | it didnt really contain much more motivation then we surmised already | 16:38 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/591597 | 16:38 |
| sean-k-mooney | it looks like the current intent was to put the instance in error if there was a conflict | 16:39 |
| sean-k-mooney | which you would preumable fix by deleting it again | 16:39 |
| sean-k-mooney | so based on that https://bugs.launchpad.net/nova/+bug/1836754 is invlid | 16:40 |
| sean-k-mooney | since that is the expect behavior | 16:40 |
| *** rpittau is now known as rpittau|afk | 16:40 | |
| sean-k-mooney | and presumable tempest does not handel the fact delete can fail and it shoudl retry | 16:40 |
| melwitt | no it does not. I debated whether that should be the fix, to retry on 409 during resource cleanup | 16:41 |
| melwitt | but then I found the WIP change and thought it didn't seem like good UX to ever reject a delete request from a user | 16:41 |
| sean-k-mooney | right | 16:42 |
| melwitt | that was in fact one of the things customers within yahoo when I worked there were vehement about, delete should never fail | 16:42 |
| sean-k-mooney | but if we decied its not a good ux to delete it form the user instead of https://review.opendev.org/c/openstack/nova/+/688802 | 16:42 |
| sean-k-mooney | we should revert the previous patch and start callign delete again on plamcnet | 16:42 |
| melwitt | I'm cool with that too. I wasn't 100% sure whether there's internal cases where we would want the chance to know about a conflict | 16:44 |
| sean-k-mooney | melwitt: basiclaly i think we have 2 options. mark the bug as invilad and adapt tempset for the 409, or always call placemtn with DELETE | 16:44 |
| sean-k-mooney | i dont think we need a new arguement that default to ture | 16:44 |
| bauzas | I see two different things here | 16:45 |
| sean-k-mooney | melwitt: do we know of any internal cases this would protect form | 16:45 |
| bauzas | 1/ a delete should always work and never return an exception, for sure | 16:45 |
| bauzas | 2/ a racing delete could tho leave orphaned allocations and that's fine | 16:45 |
| melwitt | sean-k-mooney: they're in the WIP patch, one of them was during a soft-delete reclaim periodic. I need to look again to see the other cases where we would pass force=False | 16:45 |
| sean-k-mooney | melwitt: ack | 16:46 |
| melwitt | but yeah for sure when it's an end user requesting delete we should ensure that cannot fail | 16:46 |
| melwitt | bauzas: only adjacent to how this discussion came about, I would love for you to be the second reviewer on the placement consumer types series, if you might have interest | 16:48 |
| bauzas | melwitt: I can help | 16:48 |
| melwitt | \o/ | 16:48 |
| bauzas | I mostly work on the generic mdev stuff but I'm not sure I'll be able to put all the changes before I leave for 3 weeks, so I'll maybe turn into reviews next week | 16:49 |
| melwitt | gibi has gone through it thoroughly already (thank you gibi!) so it's in a nice shape now | 16:50 |
| sean-k-mooney | i can try and take a look too but while i dicuss the api of placment alot i never really look at the code so millage will vary | 16:51 |
| bauzas | melwitt: ping me your series so I'll open a tab and make it a priority | 16:52 |
| melwitt | sean-k-mooney: ++ | 16:53 |
| melwitt | bauzas: it's 3 patches starting here https://review.opendev.org/c/openstack/placement/+/669170 I will remove the -W, I put up a DNM nova change to run with the new stuff and it all worked well _except_ for hitting the generation conflict seemingly guaranteed | 16:54 |
| opendevreview | Stephen Finucane proposed openstack/nova master: mypy: Add nova.cmd, nova.conf, nova.console https://review.opendev.org/c/openstack/nova/+/705657 | 16:55 |
| opendevreview | Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to top-level modules https://review.opendev.org/c/openstack/nova/+/705658 | 16:55 |
| opendevreview | Stephen Finucane proposed openstack/nova master: trivial: Clean manager.Manager, service.Service signatures https://review.opendev.org/c/openstack/nova/+/764806 | 16:55 |
| opendevreview | Stephen Finucane proposed openstack/nova master: WIP: Expand type hints for nova.block_device https://review.opendev.org/c/openstack/nova/+/742170 | 16:55 |
| bauzas | melwitt: cool, will read tomorrow | 16:57 |
| melwitt | thanks bauzas++ | 16:57 |
| sean-k-mooney | melwitt: bauzas this is a summary of my view on the WIP patch https://review.opendev.org/c/openstack/nova/+/688802/2#message-70a28bde99719c723c954c947d0af17227a344e9 | 16:59 |
| melwitt | thanks sean-k-mooney | 17:00 |
| sean-k-mooney | melwitt: there are other reasonce lients can recive a 409 namely locked instances so we can go either way with it | 17:00 |
| melwitt | I feel strongly that delete (by an end user) should never fail | 17:00 |
| melwitt | internals can handle 409s if there is some reason to | 17:00 |
| sean-k-mooney | right but the api contract is it must fail if the instance is locked | 17:00 |
| melwitt | well, yeah, agree that is expected | 17:01 |
| melwitt | that's the point (or one of the points) of locking | 17:01 |
| sean-k-mooney | https://docs.openstack.org/api-ref/compute/?expanded=force-delete-server-forcedelete-action-detail#force-delete-server-forcedelete-action im kind of suprised force delete can also return a 409 | 17:02 |
| melwitt | yeah :\ | 17:02 |
| sean-k-mooney | force-delet i do expect to never fail | 17:02 |
| sean-k-mooney | well 401/403/404 sire | 17:03 |
| sean-k-mooney | *sure | 17:03 |
| sean-k-mooney | but not 409 | 17:03 |
| melwitt | yeah | 17:03 |
| melwitt | fyi there's a new spec proposed around migrating instances between projects that I had -2ed the implementation proposal as this majorly needs a spec https://review.opendev.org/c/openstack/nova-specs/+/802034 | 17:08 |
| sean-k-mooney | melwitt: oh i forgot to bring this up in the meeting | 17:20 |
| sean-k-mooney | melwitt: bauzas how do you feel about approving/reviewing yoga specs now? | 17:21 |
| sean-k-mooney | we normally wait untill around m3 but ^ and any other specs can be targeted again the yoga release now | 17:21 |
| sean-k-mooney | we have the folder created | 17:21 |
| sean-k-mooney | melwitt: and ya that needs a spec | 17:23 |
| melwitt | I personally think review is welcome at any time. approval I think is natural post PTG at least but obviously it doesn't have to be | 17:23 |
| sean-k-mooney | we sould also need support in every other serivce to move the ownership of the resouces | 17:23 |
| sean-k-mooney | we have approved spec pre ptg before but mostly onse that missed the previous cycle | 17:24 |
| melwitt | yeah. we've talked about it many times as we know, and some of the proposal were to only support the project move within nova and then let other tools call all the different projects' APIs | 17:24 |
| sean-k-mooney | os-chown was the latest iteration of that right | 17:24 |
| sean-k-mooney | https://github.com/kk7ds/oschown | 17:25 |
| sean-k-mooney | i think there was a sepereate repo created form dansmith poc | 17:26 |
| melwitt | yeah there is that and I didn't know about a separate repo | 17:26 |
| sean-k-mooney | the only one i can find is os-migrate | 17:26 |
| sean-k-mooney | but that is different | 17:27 |
| sean-k-mooney | that is inter cloud migration | 17:27 |
| sean-k-mooney | melwitt: so i think my issue with nova just doing the nova bits is we end up in a situration where for a time the ownser ship of each resouce is split between multipel porojects/users/domains | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: tests: Silence noisy tests https://review.opendev.org/c/openstack/placement/+/801101 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: tox: Remove psycopg2 warning filter https://review.opendev.org/c/openstack/placement/+/800911 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: setup: Replace dashes with underscores https://review.opendev.org/c/openstack/placement/+/801102 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Replace implicit conversion of SELECT into FROM https://review.opendev.org/c/openstack/placement/+/800910 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Replace 'as_scalar()' with 'scalar_subquery()' https://review.opendev.org/c/openstack/placement/+/801100 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Update 'select()' calls https://review.opendev.org/c/openstack/placement/+/801103 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Remove use of non-integer/slice indices https://review.opendev.org/c/openstack/placement/+/801104 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Replace deprecated 'FromClause.select().whereclause' parameter https://review.opendev.org/c/openstack/placement/+/801105 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Use explicit transactions https://review.opendev.org/c/openstack/placement/+/801106 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: db: Remove unnecessary use of '_mapping' https://review.opendev.org/c/openstack/placement/+/801107 | 17:28 |
| opendevreview | Stephen Finucane proposed openstack/placement master: tox: Enable SQLAlchemy 2.0 warnings https://review.opendev.org/c/openstack/placement/+/801108 | 17:28 |
| sean-k-mooney | for example what happens if you move the ownwer ship of the neutron port of cinder volumes first before the nova instance | 17:29 |
| sean-k-mooney | if we created the port and volume and delete on terminate is set | 17:29 |
| sean-k-mooney | then you delete the instance | 17:29 |
| melwitt | yeah... I think that's why we've nacked it in the past. if we add something like that, it needs a big fat warning on it. and maybe a dragon icon | 17:29 |
| sean-k-mooney | what do we do then | 17:29 |
| sean-k-mooney | but dragons are cool | 17:30 |
| sean-k-mooney | we should put a honey badger on it instead | 17:30 |
| melwitt | "if you do this and it messes stuff up, you are on your own" | 17:30 |
| melwitt | hehe | 17:30 |
| dansmith | how about we only allow the transition if the instance is locked? | 17:31 |
| dansmith | I don't remember how much lock really restricts, and we've probably not done a good job of honoring lock everywhere, | 17:31 |
| melwitt | yeah true dragons might attract people to call the API | 17:31 |
| dansmith | but it would at least be something procedural | 17:31 |
| sean-k-mooney | dansmith: admin bypass lock by default apparently which is fun | 17:31 |
| dansmith | sean-k-mooney: sure, but this change ownership call could ... not | 17:32 |
| sean-k-mooney | dansmith: but i get your point we could take some of the rough edges off with lock | 17:32 |
| melwitt | conceptually I think that's a good idea. require some kind of freezing of it before allowing project migration | 17:32 |
| dansmith | if a compute rebooted in the middle or something I think you'd still get magic smoke | 17:32 |
| sean-k-mooney | i assume this woudl ba an admin only api by default too | 17:33 |
| dansmith | for sure | 17:33 |
| sean-k-mooney | although a domain admin might have a usecase for it to not be | 17:33 |
| melwitt | yes, haha I can't imagine it being open to normal users by default | 17:34 |
| sean-k-mooney | melwitt: well not project member anyway or likely even project admin | 17:34 |
| sean-k-mooney | but in new rbac world i coudl see domain_admin or system_admin having a use case for it | 17:34 |
| dansmith | not project admin either, I wouldn't think | 17:35 |
| sean-k-mooney | unless you did it liek cinder? i think it cinder that has a volume transfer api | 17:35 |
| sean-k-mooney | that allows you to transfer volumes between tenatns | 17:35 |
| melwitt | yeah that would seem weird to be able to move something into another project if you're not admin in that project. I guess if you were project admin in the source and destination projects? | 17:35 |
| sean-k-mooney | that has a request and accpet model | 17:36 |
| dansmith | well, if you did that, I guess you could also freeze all operations on the instance if it had a pending transfer, | 17:36 |
| dansmith | which maybe would be good | 17:36 |
| dansmith | I dunno | 17:36 |
| sean-k-mooney | if i rememebr correct both side have to agree to the transfer | 17:36 |
| melwitt | that sounds familiar | 17:36 |
| dansmith | I dunno, I have a hard time ever seeing this being not fraught with pain | 17:36 |
| sean-k-mooney | so i think the work flow is project a start the tansfer then project b acclets it | 17:36 |
| dansmith | transferring a volume in isolation is a lot simpler than an instance with tentacles | 17:37 |
| sean-k-mooney | yes true | 17:37 |
| sean-k-mooney | but i like the idea of the transfering state as you said and potentally blocking all or most operation when its in that state | 17:37 |
| sean-k-mooney | we might still want to supprot apport or delete | 17:38 |
| sean-k-mooney | *abort | 17:38 |
| sean-k-mooney | aborting and roling back though is anohter can of worms | 17:38 |
| dansmith | yeah, for serious | 17:38 |
| sean-k-mooney | so the current spec is for instance that dont have volumes only but honestly im not sure how useful it is at that point | 17:40 |
| dansmith | well, you will always have a port, maybe more, so the problem is already bad without volumes | 17:40 |
| dansmith | might as well include the volumes of course | 17:40 |
| sean-k-mooney | also they are adding that stiplulation to avoid the cinder interaction but its still there for neutron and cyborg so really unless we have a solution for all the things im not sure i see the point | 17:40 |
| sean-k-mooney | yep | 17:41 |
| dansmith | what about backups? aren't those somehow linked to the instance? | 17:41 |
| sean-k-mooney | hehe i was just thinking about snapshots in glance | 17:41 |
| sean-k-mooney | which might be store in swift or cinder on the backend | 17:41 |
| melwitt | +1 there are so many worms. but I'm not completely closed off to the idea if other people think it's worth the trouble | 17:41 |
| sean-k-mooney | although i think the volumes / objecst are technialy onwed by glance in that case not the ownere of the image but still | 17:42 |
| dansmith | correct | 17:42 |
| dansmith | the backend wouldn't be a thing I don't think | 17:42 |
| sean-k-mooney | we do store tpm data in swift for shelved instance though | 17:42 |
| sean-k-mooney | and secrets in barbican | 17:43 |
| sean-k-mooney | melwitt: im not agaisnt the idea either just the spec ist trivialising what is a very hard thing to do | 17:43 |
| sean-k-mooney | well to do right | 17:43 |
| melwitt | yeah agree | 17:44 |
| opendevreview | Merged openstack/nova master: docs: Fold in MDS security flaw doc https://review.opendev.org/c/openstack/nova/+/782411 | 18:24 |
| opendevreview | Merged openstack/nova master: docs: Change formatting of hypervisor config guides https://review.opendev.org/c/openstack/nova/+/781439 | 18:24 |
| opendevreview | Merged openstack/nova master: docs: Add libvirt misc doc https://review.opendev.org/c/openstack/nova/+/781440 | 18:24 |
| opendevreview | Merged openstack/placement master: Add periodic-stable-jobs template https://review.opendev.org/c/openstack/placement/+/775384 | 18:38 |
| melwitt | zzzeek: do you know what TypeError("Boolean value of this clause is not defined") means in the context of trying to add a column with nullable=True? (I'm trying the statement you suggested on the review) https://pastebin.com/cVRZjhLk | 20:02 |
| zzzeek | it means the wrong kind of input is either being passed to op.add_column() or something internal in alembic | 20:04 |
| zzzeek | that looks like an older version of alembic at least | 20:04 |
| zzzeek | melwitt: ^^ | 20:04 |
| melwitt | ok thanks for the hint | 20:05 |
| zzzeek | could be a bug woudl have to see the calling code | 20:06 |
| melwitt | this is the | 20:08 |
| melwitt | with op.batch_alter_table('consumers') as batch_op: | 20:09 |
| melwitt | batch_op.add_column('consumers', sa.Column('consumer_type_id', sa.Integer(), sa.ForeignKey('consumer_types.id'), nullable=True)) | 20:09 |
| zzzeek | melwitt: can you run the migration directly? does it only fail when running the test suite? | 20:09 |
| zzzeek | ohhh | 20:09 |
| zzzeek | wait | 20:09 |
| zzzeek | take the table name out | 20:09 |
| zzzeek | batch_op.add_column(sa.Column(...)) | 20:09 |
| zzzeek | ^^^^ | 20:10 |
| melwitt | zzzeek: that looks to have worked, thank you! | 20:12 |
| zzzeek | yup | 20:13 |
| opendevreview | Lee Yarwood proposed openstack/nova master: trivial: Cleanup a comment about a now removed libvirt version check https://review.opendev.org/c/openstack/nova/+/802617 | 20:51 |
| opendevreview | Lee Yarwood proposed openstack/nova master: Add functional test for bug 1937375 https://review.opendev.org/c/openstack/nova/+/802011 | 20:59 |
| opendevreview | Lee Yarwood proposed openstack/nova master: compute: Avoid duplicate BDMs during reserve_block_device_name https://review.opendev.org/c/openstack/nova/+/801990 | 20:59 |
| opendevreview | Merged openstack/nova master: scheduler: Remove 'USES_ALLOCATION_CANDIDATES' https://review.opendev.org/c/openstack/nova/+/773640 | 21:21 |
| opendevreview | Lee Yarwood proposed openstack/nova master: fup: Move _wait_for_volume_attach into InstanceHelperMixin https://review.opendev.org/c/openstack/nova/+/802623 | 21:21 |
| opendevreview | Merged openstack/nova master: scheduler: 'USES_ALLOCATION_CANDIDATES' removal cleanup https://review.opendev.org/c/openstack/nova/+/797513 | 21:25 |
| opendevreview | melanie witt proposed openstack/placement master: Add consumer_types migration, database and object changes https://review.opendev.org/c/openstack/placement/+/669170 | 21:58 |
| opendevreview | melanie witt proposed openstack/placement master: Microversion 1.38: API support for consumer types https://review.opendev.org/c/openstack/placement/+/679441 | 21:58 |
| opendevreview | melanie witt proposed openstack/placement master: Switch ConsumerType to use an AttributeCache https://review.opendev.org/c/openstack/placement/+/679486 | 21:58 |
| opendevreview | Merged openstack/nova master: scheduler: Remove 'hosts_up' https://review.opendev.org/c/openstack/nova/+/773641 | 21:59 |
| opendevreview | Merged openstack/nova master: trivial: Remove FakeScheduler (for realz) https://review.opendev.org/c/openstack/nova/+/773642 | 22:00 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!