Earlier  
Posted Nick Remark
#openstack-nova - 2020-03-19
13:50:48 sean-k-mooney gibi: we do the evacuation tests after all the others
13:51:05 gibi OK. thanks. then it make sense
13:51:10 lyarwood yeah the previous behaviour was to leave libvirt stopped on the subnode anyway
13:51:19 lyarwood I'm still plannig to break this out into seperate jobs btw
13:51:29 lyarwood Just want to get it stable again before I start with that
13:51:59 sean-k-mooney yep makes sense
13:52:15 gibi lyarwood: thank you for taking care of this. +2
13:52:48 lyarwood np it has stopped my stuff from landing so this is the least I could do ;)
13:54:20 gibi lyarwood: you are unblocking everyone and that is highly appreciated :)
14:33:06 sean-k-mooney gibi: is the nova team meeing happing now by the way
14:33:23 sean-k-mooney oh its later i need to update my calandar
14:33:25 gibi sean-k-mooney: each occasion moved to 16:00 UTC
14:33:33 sean-k-mooney yep
14:37:48 sean-k-mooney ical file for anyone else http://eavesdrop.openstack.org/calendars/nova-team-meeting.ics
15:02:28 gibi dansmith: I went through the cyborg patch series. left comments. I did not find any ground breaking problem.
15:02:52 dansmith gibi: okay I haven't even looked at my reviews box yet this morning but will try to do that soon
15:03:17 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Use virDomainBlockCopy to swap volumes when using -blockdev https://review.opendev.org/696834
15:04:27 gibi dansmith: ack
15:08:01 gmann sean-k-mooney: a bug related to flavor. id with name or vice versa are not unique. If we do some change in flavor things what we discussed yesterday, i think we can stop taking flavor id in request and always generate one- https://bugs.launchpad.net/nova/+bug/1858019
15:08:01 openstack Launchpad bug 1858019 in OpenStack Compute (nova) "The flavor id is not limited when creating a flavor" [Wishlist,Triaged] - Assigned to Choi-Sung-Hoon (knu-cse)
15:08:29 gmann because i do not think fixing 1858019 alone is worth for microversion bump
15:08:36 sean-k-mooney gmann: im not sure about that
15:08:44 gmann any specific reason for flavor id in request ?
15:08:55 sean-k-mooney well people often just use the id
15:09:10 sean-k-mooney i know we frequently do that in ci
15:09:31 sean-k-mooney so we know that the m1.nano flaovr is 42 and that is just used in ci jobs
15:09:46 sean-k-mooney gmann: the flavor id is always uniqute
15:09:52 sean-k-mooney but the name is not
15:10:12 gmann name is also unique to each other but id with name is not
15:10:33 sean-k-mooney yes but you can have two flaovr with the same name
15:10:43 sean-k-mooney you cant have two flavors with the same id
15:10:47 sean-k-mooney right?
15:10:48 gmann no, it will be 409 i think
15:10:57 gmann in name case also
15:11:02 sean-k-mooney i would have to go check
15:11:07 gmann let me confirm quickly
15:11:08 sean-k-mooney i know we look for deleted status
15:12:21 sean-k-mooney gmann: i guess we could stop taking the id in the new microverion i just know i often specify the id if i am using ci jobs or locally so i dont know how wide spread that is
15:12:34 sean-k-mooney gmann: you suggesign blocking it on flavor create right
15:12:40 openstackgerrit Kevin Zhao proposed openstack/nova master: fix scsi disk unit number of the attaching volume when cdrom bus is scsi https://review.opendev.org/712607
15:12:44 sean-k-mooney not for other operations
15:12:46 gmann yeah, in create
15:12:52 gmann create request only
15:13:38 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L415-L418
15:13:53 sean-k-mooney im not sure if we still use the instance_types table
15:14:16 sean-k-mooney but the unique constratif for that is just flavor id and deleted
15:14:32 sean-k-mooney oh and name
15:15:30 gmann only thing will be create will generate the uuid. current id in request can be just anything easy to remember like number of string
15:15:44 gmann number or string
15:15:59 sean-k-mooney well its ment to be an int or a uuid
15:16:12 sean-k-mooney but a sting can work
15:16:18 sean-k-mooney *string
15:16:43 sean-k-mooney the idiomatic usage is uuid or int
15:17:02 sean-k-mooney i guess we would make it just a uuid if we auto generated it. i think that is what we do today correct
15:17:17 gmann yeah, if people find uuid difficult to use than int
15:17:34 gmann yes, https://github.com/openstack/nova/blob/master/nova/compute/flavors.py#L69
15:17:40 sean-k-mooney ya if i set it i alwasy set it to an int
15:17:50 sean-k-mooney if i dont set it i use the name
15:18:20 sean-k-mooney the only reason i have ever used the id is when its shorter then typing the name
15:18:45 sean-k-mooney i guess since you can always use an older microversin if you need to set the id then i would be ok with the change
15:19:00 gmann same. i do not know why bug repartee want to give exiting flavor's name as id for new one
15:19:55 gmann i do not think that is normal usage that is why i marked that bug as wishlist but we could say would not fix or somethings.
15:19:58 sean-k-mooney so the microverion would make the flavor_id auto generated and then either make is_public mutable or remove is_public right?
15:20:43 sean-k-mooney those are the two changes you were suggesting combining?
15:21:10 gmann yeah and anything else there in flavor side cleanup. other way is to do another single cleanup microversion we did in stein or train and combine other API cleanup which are worth to do.
15:21:43 sean-k-mooney ya i think that makes sense. im not sure if there are other change we were thinking of for the flavor
15:22:00 openstackgerrit Lee Yarwood proposed openstack/nova master: virt: Provide block_device_info during rescue https://review.opendev.org/700811
15:22:01 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue https://review.opendev.org/700812
15:22:01 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Report COMPUTE_RESCUE_BFV and check during rescue https://review.opendev.org/701429
15:22:02 openstackgerrit Lee Yarwood proposed openstack/nova master: api: Introduce microverion 2.83 allowing boot from volume rescue https://review.opendev.org/701430
15:22:02 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212
15:22:03 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Support boot from volume stable device instance rescue https://review.opendev.org/701431
15:22:03 openstackgerrit Lee Yarwood proposed openstack/nova master: DNM - Test stable device rescue tests with BFV instances https://review.opendev.org/710050
15:22:21 sean-k-mooney we have talked about things like removing rxtx_factor and vcpu_weight in the past
15:22:35 sean-k-mooney i think those are both for vmware but they should have been extraspecs
15:22:58 gmann let me find the etherpad of cleanup tihngs if we have those already
15:23:57 sean-k-mooney the disabled field also has some overlap with private/public https://github.com/openstack/nova/commit/f371198b843ba17ad6a6e4bc77a58afb006ab677
15:25:19 gmann https://etherpad.openstack.org/p/nova-api-cleanup
15:25:58 openstackgerrit Lee Yarwood proposed openstack/nova master: Add config option for neutron client retries https://review.opendev.org/712226
15:26:34 gmann yeah, only admin in access list make it disable
15:26:58 sean-k-mooney ah its an internal field
15:27:08 sean-k-mooney i was looking at the client and did not see how to set it
15:28:23 gmann I will add these two candidates in etherpad.
15:29:27 sean-k-mooney ok. i assume this would all be done in Victoria too right
15:29:58 sean-k-mooney e.g. we cant approve a spec for this at this point and this would not qualify for a bug fix right
15:32:45 gmann yeah, not before Vistoria. or i will say wait till W cycle also to collect more.
15:36:49 openstackgerrit Kevin Zhao proposed openstack/nova master: fix unit test error block info on non x86 architecture https://review.opendev.org/713905
15:36:58 lyarwood hmm so zuul doesn't kick a failing change out of the gate until all jobs have returned?
15:38:12 gmann lyarwood: yeah.
15:38:44 lyarwood gmann: kk, this might take some time then :D
15:39:15 sean-k-mooney zuul will kick it out if you propsoe a new version
15:39:32 lyarwood it's not my change
15:39:37 gmann one trick is if you have Depends-On then failure or change on Depends-On
15:40:12 lyarwood https://review.opendev.org/#/c/704759/ is first in the queue but failing
15:40:29 lyarwood I was just checking what zuul was going to do in this case
15:41:27 gibi lyarwood: yeah that is mine, failing on some neutron tempest test case :/
15:41:34 sean-k-mooney lyarwood: is this related to your evacuate change
15:44:16 lyarwood sean-k-mooney: no, my change is below it
15:44:23 lyarwood actually that doesn't matter does it
15:44:40 lyarwood gibi: was that the subnet creation bug I linked in my email?

Earlier   Later