| opendevreview | Merged openstack/nova stable/victoria: Stop leaking ceph df cmd in RBD utils https://review.opendev.org/c/openstack/nova/+/791938 | 03:08 |
|---|---|---|
| *** bhagyashris|ruck is now known as bhagyashris|out | 05:53 | |
| *** mgoddard- is now known as mgoddard | 08:40 | |
| lyarwood | melwitt: https://bugs.launchpad.net/nova/+bug/1931707 btw, that's the same issue as downstream right? | 09:53 |
| stephenfin | lyarwood: gibi: With an operator-like hat on, is there any reason to keep the VERSION argument in 'nova-manage db sync [VERSION]' ? | 09:56 |
| stephenfin | given we don't allow downgrades | 09:56 |
| stephenfin | and you can't really run nova without the latest DB schema | 09:57 |
| sean-k-mooney | stephenfin: my only resevation with removing it is if you want to do the migrations in batches | 09:58 |
| gibi | stephenfin: I think stoping at an intermittent version, do some manual checks / fixes inconsistencies, then continue forward might make sense | 09:58 |
| sean-k-mooney | thats basicaly what i was thinking | 09:59 |
| sean-k-mooney | but if we did things correctly that should not be required | 09:59 |
| gibi | yeah, also batching might make sense if there are heavy transformations | 09:59 |
| gibi | if we never have bugs leading to db inconsistencies then yeah :D | 09:59 |
| sean-k-mooney | stephenfin: with a down stream hat on i dont know if there are FFU cases where we would want to stop an an intermidite release | 09:59 |
| gibi | what my empoyer do during Mitaka -> Victoria FFU is to stop at Pike and Train then go to Victoria | 10:00 |
| gibi | sorry, stop at Newton and Pike | 10:01 |
| stephenfin | okay, batching or step by step upgrades makes sense | 10:01 |
| sean-k-mooney | we might want to stop on n+2 before n+3 to run some online migrations | 10:01 |
| stephenfin | alembic allows us to separate migrations into those that expand (can be done online) and those that contract (requires downtime) | 10:02 |
| sean-k-mooney | ya it does | 10:02 |
| stephenfin | so we might be able to look at finally removing a lot of dead tables and columns in contract migrations | 10:02 |
| sean-k-mooney | is it problematic to continue to supprot this | 10:02 |
| stephenfin | is that a question or a statement? | 10:02 |
| sean-k-mooney | a quetion is it difficult to support db sync version? | 10:03 |
| sean-k-mooney | im wondering why you asked | 10:03 |
| stephenfin | no, not at all | 10:03 |
| stephenfin | I was just wondering if it's worth keeping | 10:03 |
| lyarwood | Yeah I think it is, would avoid the need to ship every release for db migrations | 10:04 |
| sean-k-mooney | ok personally i do not know if it really widely used. typically i would not expect it to be | 10:04 |
| stephenfin | Well, it's slightly tricky. I'm not allowing people to select an sqlalchemy-migrate version. Only alembic ones | 10:04 |
| lyarwood | if we kept a few releases in tree at once that is | 10:04 |
| sean-k-mooney | lyarwood: well we dont drop the db migrations | 10:04 |
| stephenfin | So you won't be able to select any of the migrations > Train, < Xena | 10:04 |
| stephenfin | which I think is fine because they're all placeholders rn | 10:04 |
| lyarwood | right the ones you squashed? | 10:05 |
| stephenfin | I squashed everything up to Train | 10:05 |
| stephenfin | we haven't had a real DB migration since then | 10:05 |
| sean-k-mooney | their have been no db changes since train? | 10:05 |
| sean-k-mooney | i was not aware of that. | 10:06 |
| stephenfin | nope | 10:06 |
| stephenfin | No API microversions in Victoria either. Sign of the times | 10:06 |
| sean-k-mooney | so that tecnicaly mean a master api could talk to a train cell db | 10:06 |
| stephenfin | Yup | 10:06 |
| stephenfin | in theory we don't do contractions so a train API could talk to a master DB | 10:08 |
| stephenfin | also | 10:08 |
| sean-k-mooney | is the same true of the api db | 10:08 |
| stephenfin | yes, afaik | 10:08 |
| sean-k-mooney | good to know | 10:08 |
| lyarwood | sean-k-mooney / stephenfin / gibi ; if you have time today could you take a look at these specs I'm trying to get over the line before spec freeze and my sick leave next week? https://review.opendev.org/c/openstack/nova-specs/+/799811 https://review.opendev.org/c/openstack/nova-specs/+/799624 https://review.opendev.org/c/openstack/nova-specs/+/799850 | 10:20 |
| sean-k-mooney | you have 3 :) | 10:22 |
| sean-k-mooney | ah | 10:22 |
| sean-k-mooney | yes i rememebr all 3 of them being discussed ill review them today | 10:22 |
| gibi | lyarwood: I will check them out after lunch | 10:23 |
| lyarwood | many thanks | 10:28 |
| lyarwood | https://review.opendev.org/c/openstack/nova/+/799964 - we don't need a minor version bump on o.vo objects when adding new field values right? | 10:30 |
| lyarwood | ^ this updated nova.virt.arch.ALL and caused the hashed version of a few o.vo objects to change | 10:30 |
| lyarwood | but as it's just field values and not adding or removing actual attributes from the object I guess we just update the hash? | 10:31 |
| sean-k-mooney | am we do not bump for compostion | 10:46 |
| sean-k-mooney | so if a contained ovo change we dont need the bump the warping ovo | 10:46 |
| sean-k-mooney | but let me look | 10:46 |
| sean-k-mooney | we do need to backlevel the value in some cases | 10:47 |
| sean-k-mooney | do we support armv6l | 10:48 |
| gibi | lyarwood: yeah I think we need a minor bump for enum value. As the old compute will not handle the new enum value | 10:48 |
| sean-k-mooney | i tought we were going to drop all 32bit arch support | 10:48 |
| sean-k-mooney | gibi: for enuma yes | 10:48 |
| sean-k-mooney | we back level the image proerties object for example anytime we bump an enuma field | 10:49 |
| gibi | there is an Architecture enum that uses very similar values than https://review.opendev.org/c/openstack/nova/+/799964/2/nova/virt/arch.py#17 | 10:50 |
| sean-k-mooney | yes there is the current patch is not touching the objects just the virt code | 10:50 |
| lyarwood | gibi: right, I've asked them to update that, it's using the values of nova.virt.arch.ALL that they have updated for the ALL attribute there that caused the test version failures | 10:51 |
| sean-k-mooney | although i thinke we generate one form the ohter | 10:51 |
| sean-k-mooney | lyarwood: well im not sure if wew shoudl be adding this however | 10:51 |
| lyarwood | kk I didn't think it was 32 bit ./me looks | 10:51 |
| lyarwood | hmm does it really matter if libvirt supports it? | 10:54 |
| sean-k-mooney | i mean we can add it but im not sure if that is soemthing we want to support | 10:54 |
| sean-k-mooney | i guess its fine to include if we want to enulate it in the future | 10:55 |
| sean-k-mooney | just not as a host plathform | 10:55 |
| lyarwood | Yeah indeed | 10:56 |
| sean-k-mooney | with that said i did once try to get openstack running in a rasberry pi | 10:57 |
| sean-k-mooney | proably quite doable now with the pi4 | 10:58 |
| gibi | lyarwood: if you add a sentence about locking / unlocking the instance during the connection update then I'm +2 on https://review.opendev.org/c/openstack/nova-specs/+/799624 | 11:13 |
| gibi | lyarwood: I left two questions in https://review.opendev.org/c/openstack/nova-specs/+/799850 | 11:20 |
| gibi | lyarwood: and I'm +2 with a micro nit on https://review.opendev.org/c/openstack/nova-specs/+/799811 | 11:24 |
| gibi | I can get back to these specs still today if you bump them | 11:25 |
| sean-k-mooney | lyarwood: by the way this is still pending we shoudl proably implemaet that soone rather then later ill see if i can get back to that while your away | 11:27 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/774044 | 11:27 |
| lyarwood | gibi: ack looking | 11:37 |
| lyarwood | sean-k-mooney: ack kk | 11:38 |
| sean-k-mooney | am i would prefer if we made https://review.opendev.org/c/openstack/nova-specs/+/799811 more general | 11:39 |
| sean-k-mooney | ill push my comments shortly | 11:39 |
| lyarwood | sean-k-mooney: two issues with making it general, we'd have to work out the defaults for all of the image props if they aren't provided | 11:42 |
| lyarwood | sean-k-mooney: and it's a load of work to validate all of the input compared to just targeting what we need at the moment | 11:42 |
| sean-k-mooney | we dont need to recorod all of them but i want to allow updating all excptin the ones we know will break things | 11:42 |
| lyarwood | tbh that's a seperate spec and thing to this | 11:43 |
| sean-k-mooney | lyarwood: there are only 4 addtional ones i think we should be recordeing | 11:43 |
| opendevreview | Lee Yarwood proposed openstack/nova-specs master: Add nova-manage commands to show and refresh connection_info https://review.opendev.org/c/openstack/nova-specs/+/799624 | 11:44 |
| lyarwood | gibi: re https://review.opendev.org/c/openstack/nova-specs/+/799850 - I thought policy was more for overall access to an API but if we can use it to also control the contents of the response then I don't see why we couldn't use it here as well. | 11:48 |
| gibi | lyarwood: e.g. os_compute_api:os-instance-actions:events:details controls the detials of the actions and it is system reader by default | 11:51 |
| sean-k-mooney | we also have a polciy to control if the extra specs of a flavor are show to normal users | 11:53 |
| lyarwood | cool okay I'll copy that pattern then | 11:55 |
| sean-k-mooney | lyarwood: comments pushed on https://review.opendev.org/c/openstack/nova-specs/+/799811 | 11:57 |
| sean-k-mooney | lyarwood: you had another spec similar to https://review.opendev.org/c/openstack/nova-specs/+/799850 for addign the attchment id right | 11:59 |
| sean-k-mooney | can we use the same microversion for both | 11:59 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/794799 | 11:59 |
| sean-k-mooney | i kid of feel like those two api cahnges shoudl be done together | 12:00 |
| lyarwood | we could but I thought it needed something separate for the admin/policy driven part | 12:00 |
| sean-k-mooney | i mean we could leave that to the implemation it would be nice not to have to bump twice | 12:01 |
| sean-k-mooney | am one other question | 12:02 |
| sean-k-mooney | we wanted to stop stashing the connection info in nova at somepoitn right | 12:02 |
| sean-k-mooney | and just alwasy get it form cinder | 12:02 |
| sean-k-mooney | basically if we plan to not store it in the db long term i dont think we should add it to the api respocne so that we do not need then proxy it in the future | 12:04 |
| lyarwood | sorry back | 12:09 |
| lyarwood | yeah I don't mind using the same microversion for both if it matters that much | 12:09 |
| lyarwood | and yeah eventually I'd like to but there's no written down plan to attack that this cycle yet | 12:09 |
| sean-k-mooney | it does not but im not conviced we should should add the new api | 12:10 |
| sean-k-mooney | i think we should just proceed with https://review.opendev.org/c/openstack/nova-specs/+/799624 more then likely | 12:10 |
| sean-k-mooney | although i have not read that yet but i think nova manage would be better if we plan to remove the cacheing eventually | 12:11 |
| lyarwood | I disagree, we can always remove it in a later microversion | 12:11 |
| sean-k-mooney | we could but we will have to proxy for old microverions | 12:11 |
| lyarwood | and when it is there it's just going to be None once we've removed the stashing in Nova | 12:11 |
| lyarwood | why would we need to proxy? | 12:12 |
| sean-k-mooney | no if we remove the stashing we will have to have nova proxy to nova for the old microverion | 12:12 |
| lyarwood | nope | 12:12 |
| lyarwood | it's the connection_info that Nova has | 12:12 |
| sean-k-mooney | it would break people if we did not | 12:12 |
| lyarwood | how would it break people? | 12:12 |
| sean-k-mooney | if people used the old microversion then they would expect the connection info | 12:13 |
| sean-k-mooney | and it would nolonger be presnt when we stop stashing | 12:13 |
| lyarwood | they'd expect the connection_info that Nova held about a volume attachment | 12:13 |
| lyarwood | they're not going to use it for anything | 12:13 |
| lyarwood | it's just a troubleshooting tool | 12:13 |
| sean-k-mooney | which i dont think shoudl be at the api level | 12:14 |
| sean-k-mooney | if we put it in the api then it will be used for other things | 12:14 |
| sean-k-mooney | the fact that nova caches this info is an internal implementation detail | 12:15 |
| sean-k-mooney | we also have a network info cache but we dont expose it via the api | 12:15 |
| sean-k-mooney | i dont think we shoudl be treatign novas copy of the the connection info as something different from cinders at the api level | 12:16 |
| sean-k-mooney | its just a cache | 12:16 |
| sean-k-mooney | IMO | 12:16 |
| lyarwood | Partly, there's also some additional stuff we stash in there on the Nova side at the moment | 12:17 |
| lyarwood | like the device path, multipath UUIDs etc | 12:17 |
| lyarwood | I still think it's entirely valid in the API | 12:17 |
| lyarwood | there's nothing a caller could do with it anyway outside of calling os-brick with it | 12:18 |
| sean-k-mooney | well you could use it to connect to the backend | 12:18 |
| lyarwood | right I mean with our APIs | 12:18 |
| lyarwood | so the fact it's going away in the future shouldn't matter | 12:19 |
| lyarwood | and there's always another way of getting it | 12:19 |
| sean-k-mooney | i dont know to me this just feels like adding tech debt | 12:20 |
| sean-k-mooney | the admin should not really need to know or care about this | 12:20 |
| sean-k-mooney | i get that its for troble shooting | 12:20 |
| sean-k-mooney | but wont the nova manage command provide a better way to do that | 12:21 |
| sean-k-mooney | as that will also supprot refershing it | 12:21 |
| sean-k-mooney | so fixing the problem if it exitis | 12:21 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Unify 'nova.db.api', 'nova.db.sqlalchemy.api' https://review.opendev.org/c/openstack/nova/+/799524 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Move remaining 'nova.db.sqlalchemy' modules https://review.opendev.org/c/openstack/nova/+/799525 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Post reshuffle cleanup https://review.opendev.org/c/openstack/nova/+/799526 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Avoid use of ALTER in initial migration https://review.opendev.org/c/openstack/nova/+/800076 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Add initial alembic migration for main DB https://review.opendev.org/c/openstack/nova/+/799527 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Add initial alembic migration for API DB https://review.opendev.org/c/openstack/nova/+/799528 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Trivial style changes https://review.opendev.org/c/openstack/nova/+/799529 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Normalize migrations tests https://review.opendev.org/c/openstack/nova/+/799684 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Integrate alembic https://review.opendev.org/c/openstack/nova/+/799530 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Enable auto-generation of migrations https://review.opendev.org/c/openstack/nova/+/800077 | 12:24 |
| opendevreview | Stephen Finucane proposed openstack/nova master: docs: Add documentation on database migrations https://review.opendev.org/c/openstack/nova/+/800078 | 12:24 |
| viks__ | hi, i'm facing some issue in network interface naming... after i create an ubuntu instance, i assign a private interface, and then ubuntu instance gets an interface named `ens7`... but when i power off and then start the instance again, the interface name changes to `ens4`. I'm not sure how to avoid this name changing? Can someone plz guide? | 12:34 |
| sean-k-mooney | viks__: that is because of two things one the pci adddreess of the instance likely change and 2 hotplug name are normally not stable in general | 12:39 |
| sean-k-mooney | one way to adress this is with udev rules that mach on the mac to set the name | 12:39 |
| sean-k-mooney | viks__: in generally if you shoudl leverage device role tagging https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html | 12:40 |
| opendevreview | Merged openstack/nova stable/ussuri: [neutron] Get only ID and name of the SGs from Neutron https://review.opendev.org/c/openstack/nova/+/787253 | 12:41 |
| viks__ | sean-k-mooney: if we tag, the names will persist after instance comes up again? | 12:44 |
| sean-k-mooney | no | 12:45 |
| sean-k-mooney | the name is out of the contol of openstack | 12:45 |
| sean-k-mooney | but if you tag it will provide a way for you to lookup the device and not depend on the name | 12:46 |
| sean-k-mooney | in the metadata api you will get info like this | 12:46 |
| sean-k-mooney | { | 12:46 |
| sean-k-mooney | "type": "nic", | 12:46 |
| sean-k-mooney | "bus": "pci", | 12:46 |
| sean-k-mooney | "address": "0000:00:03.0", | 12:46 |
| sean-k-mooney | "mac": "01:22:22:42:22:21", | 12:46 |
| sean-k-mooney | "tags": ["nfvfunc2"] | 12:47 |
| sean-k-mooney | }, | 12:47 |
| sean-k-mooney | and you can have a script at boot name you interfaces as you wish | 12:47 |
| sean-k-mooney | viks__: the nic names should not change again provide you dont add or remvoe any nics or volumes to the vm | 12:47 |
| viks__ | sean-k-mooney: Thanks a lot.. will try out... | 12:49 |
| sean-k-mooney | lyarwood: +1 on https://review.opendev.org/c/openstack/nova-specs/+/799624 i an alternitive approch inline and just want you to confirm it wont work | 13:18 |
| opendevreview | Elod Illes proposed openstack/nova stable/train: [neutron] Get only ID and name of the SGs from Neutron https://review.opendev.org/c/openstack/nova/+/787316 | 13:18 |
| *** liuyulong__ is now known as liuyulong_ | 13:40 | |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] refactor assertPortMatchesAllocation https://review.opendev.org/c/openstack/nova/+/792458 | 13:54 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] refactor asserts in qos tests https://review.opendev.org/c/openstack/nova/+/798930 | 13:54 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] ports with both bw and pps resources https://review.opendev.org/c/openstack/nova/+/792394 | 13:54 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Parse extended resource request from the port https://review.opendev.org/c/openstack/nova/+/800085 | 13:54 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Transfer RequestLevelParams from ports to scheduling https://review.opendev.org/c/openstack/nova/+/791506 | 14:00 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Support boot with extended resource request https://review.opendev.org/c/openstack/nova/+/800086 | 14:01 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Support move ops with extended resource request https://review.opendev.org/c/openstack/nova/+/800087 | 14:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [func test]Refactor interface attach with qos https://review.opendev.org/c/openstack/nova/+/800088 | 14:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Support interaface attach / detach with new resource request format https://review.opendev.org/c/openstack/nova/+/800089 | 14:03 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] move unshelve test to the proper place https://review.opendev.org/c/openstack/nova/+/793621 | 14:06 |
| opendevreview | Kashyap Chamarthy proposed openstack/nova master: libvirt: Switch the default video model from 'cirrus' to 'virtio' https://review.opendev.org/c/openstack/nova/+/798680 | 15:02 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Support boot with extended resource request https://review.opendev.org/c/openstack/nova/+/800086 | 16:17 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Support move ops with extended resource request https://review.opendev.org/c/openstack/nova/+/800087 | 16:17 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [func test]Refactor interface attach with qos https://review.opendev.org/c/openstack/nova/+/800088 | 16:17 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Support interaface attach / detach with new resource request format https://review.opendev.org/c/openstack/nova/+/800089 | 16:17 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [func test] move unshelve test to the proper place https://review.opendev.org/c/openstack/nova/+/793621 | 16:19 |
| melwitt | lyarwood: the error in https://bugs.launchpad.net/nova/+bug/1931707 is the same but downstream it's happening during a server show | 17:09 |
| *** melwitt is now known as Guest322 | 17:31 | |
| *** melwitt_ is now known as melwitt | 17:57 | |
| *** melwitt is now known as jgwentworth | 17:58 | |
| *** TheJulia is now known as needssleep | 18:04 | |
| opendevreview | Rodrigo Barbieri proposed openstack/nova stable/stein: Error anti-affinity violation on migrations https://review.opendev.org/c/openstack/nova/+/800114 | 18:23 |
| opendevreview | Rodrigo Barbieri proposed openstack/nova master: Improve prep_resize reschedule unit test https://review.opendev.org/c/openstack/nova/+/800297 | 18:53 |
| opendevreview | Merged openstack/nova stable/train: [neutron] Get only ID and name of the SGs from Neutron https://review.opendev.org/c/openstack/nova/+/787316 | 22:33 |
| opendevreview | melanie witt proposed openstack/nova stable/stein: [neutron] Get only ID and name of the SGs from Neutron https://review.opendev.org/c/openstack/nova/+/791402 | 22:39 |
| opendevreview | melanie witt proposed openstack/nova master: Make test_archive_task_logs deterministic https://review.opendev.org/c/openstack/nova/+/800313 | 22:40 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!