Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-19
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?
15:45:24 gibi lyarwood: there was some timeout but did not look deeper
15:46:08 gibi lyarwood: nvm, I looked at a different job
15:47:05 lyarwood https://4cc1d8431535199f530e-fcfc85786424b7f5a3fcadff9da35f94.ssl.cf2.rackcdn.com/704759/10/gate/grenade-py3/9dc93d2/logs/grenade.sh.txt - looks like grenade failed to update libvirt/qemu
15:47:51 gibi yep
15:50:26 gibi nova team meeting in 10 minutes on #openstack-meeting-3
15:52:10 stephenfin Can someone != gibi take a look at this, the final remove-nova-network patch? https://review.opendev.org/#/c/703974/
15:52:47 stephenfin I don't want your kind round here :P
16:01:34 gibi nova meeting is running on #openstack-meeting-3
16:24:10 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Fix unit test error block info on non x86 architecture https://review.opendev.org/713905
16:46:26 stephenfin CI stability patch here looking for another core https://review.opendev.org/#/c/713611/
16:48:33 openstackgerrit Merged openstack/nova master: nova-live-migration: Ensure subnode is fenced during evacuation testing https://review.opendev.org/713674
16:48:40 openstackgerrit Merged openstack/nova master: virt: Pass request context to extend_volume https://review.opendev.org/706899
16:50:16 lyarwood stephenfin: nice!
16:50:25 lyarwood stephenfin: did you end up fixing that upstream?
16:50:41 stephenfin Yup, thankfully
16:50:59 sean-k-mooney so they accpeted your change related to async stream handeling?
16:51:02 stephenfin My original fix was correct. It just took a while to figure out why
16:51:29 lyarwood awesome
16:52:03 stephenfin It wasn't anything to do with async. Turns out 'read(N)' on anything inheriting from 'RawIOBase' doesn't guarantee N bytes
16:52:13 stephenfin unlike 'BufferedIOBase'
16:54:35 stephenfin lyarwood: is this a real issue? https://zuul.opendev.org/t/openstack/build/9dc93d24e9634d7e95ee6f2763b38613/log/logs/screen-n-cpu.txt#5506
16:54:49 stephenfin trying to figure out why https://review.opendev.org/#/c/704759/10 failed
16:57:27 stephenfin actually, nvm, it's not that. It's a simple 404 https://zuul.opendev.org/t/openstack/build/9dc93d24e9634d7e95ee6f2763b38613/log/logs/grenade.sh.txt#46542
16:57:49 lyarwood stephenfin: no that's fine
16:58:03 lyarwood stephenfin: yeah I spoke about it earlier, apt-get install failing right
16:58:09 stephenfin yuup
16:58:24 stephenfin from http://mirror.ord.rax.opendev.org/
16:58:58 sean-k-mooney stephenfin: it returns upto N bytes correct
16:59:09 stephenfin sean-k-mooney: correct
16:59:23 sean-k-mooney stephenfin: i think that is the same behavior as the read syscall
16:59:36 sean-k-mooney e.g. if you were to invoke it form c
16:59:58 sean-k-mooney so you have to check how many bytes you actully got
17:00:04 stephenfin also correct
17:00:27 sean-k-mooney im guessign that was causing the header or soemthign to be tuncated
17:00:37 sean-k-mooney or other strange hard to dignose error
17:01:11 sean-k-mooney in anycase im glad you managed to fix it
17:03:34 efried_gone sean-k-mooney: re rootwrap, I think there's some vestigial code that we needed to keep because of a weird os-brick thing. I don't remember the details exactly. But we never figured out whether we could safely remove it, or how.
17:10:29 sean-k-mooney efried_gone: did we not remove all usage in nova itself
17:10:40 sean-k-mooney you might be very well right about os-brick
17:11:03 sean-k-mooney but we merged all the patches in the remove root wrap series
17:12:02 stephenfin sean-k-mooney: https://github.com/openstack/nova/tree/master/etc/nova/rootwrap.d/compute.filters
17:17:26 efried_gone yeah
17:20:33 sean-k-mooney right so that is so it can launch its own privsep deamon right
17:21:16 sean-k-mooney os-vif also launches its own privsep deamon and we dont have a rootwrap entry
17:40:01 sean-k-mooney is there a reason that os-brick needs to have rootwap to start privsep?
17:43:09 sean-k-mooney ok so it still uses rootwap directly https://github.com/openstack/os-brick/blob/master/os_brick/privileged/rootwrap.py
17:46:27 sean-k-mooney stephenfin: so ya i think nova nolonger need to have that rootwap filter. it could be move to os-brick but basically if that is the only usage i satand by my comment that nova does not use rootwap os-brick does
17:47:08 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Use virDomainBlockCopy to swap volumes when using -blockdev https://review.opendev.org/696834
17:47:41 sean-k-mooney it looks like os-brick only has 4 usages of rootwap remining too

Earlier   Later