Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-07-14
19:42:29 gmann POST /servers which accept hostname today and start accepting host uuid is soemthing need microversion
19:43:27 sean-k-mooney mnaser: its in neutron and cinder also
19:43:38 melwitt oh, sorry, the details of this must have fallen out of my brain
19:44:07 sean-k-mooney mnaser: we set the az in the device_owner field in the neutron port bindings and i think in the cinder volumlue attachments
19:44:38 mnaser sean-k-mooney: right.. in this case those are purposely non-bfv systems so no cinder attachments, now neutron is a good point
19:44:51 mnaser but still.. nova api reports old az still, not sure where to change
19:45:11 mnaser looks for instance_extra and instance_system_metadata
19:45:35 sean-k-mooney ya one of those would be likely but maybe this is nin the api db somewhere
19:45:54 sean-k-mooney we had a list at onepoint
19:46:47 mnaser build_requests has nothing, i already updated nova_api.request_specs.spec
19:46:51 mnaser maybe its cached at this point
19:48:00 melwitt yeah, you might be getting https://github.com/openstack/nova/blob/master/nova/availability_zones.py#L195-L211
19:48:41 mnaser ahhh so it is cached
19:49:37 sean-k-mooney do you know where we block you removing host form az if it has instnaces
19:49:59 sean-k-mooney the commit that blocked that has a list of all the places where az are stored i think too
19:50:42 mnaser yeah i think in my case it's more of the cache getting the host az to present via the api
19:51:19 melwitt https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/services.py#L281-L284
19:52:05 sean-k-mooney https://github.com/openstack/nova/commit/8e19ef4173906da0b7c761da4de0728a2fd71e24
19:52:10 sean-k-mooney there we go ^
19:52:59 mnaser ok so melwitt theory that i'm hitting the case where the az for the compute node != az for instance record, and then its just getting the compute node one
19:53:34 melwitt maybe. I didn't look deep into it
19:54:01 sean-k-mooney mnaser: did you rename the az or move the compute node
19:54:18 mnaser sean-k-mooney: neither.. i am trying to cold migrate to another az :X
19:54:28 sean-k-mooney ah ya that breaks things
19:54:41 sean-k-mooney gibi: and bauzas were working on that recently
19:54:42 mnaser in theory it all works but just the scheduler is not happy
19:54:44 sean-k-mooney one sec
19:55:14 sean-k-mooney mnaser: well if the vm requeted an az in the first place you are nota llowed to migrate to another az
19:55:23 mnaser melwitt: that was it, removing the compute node (that was disabled) out of the host aggregate that was setting the az made to go back to hte db value
19:55:24 sean-k-mooney if it did not yes it can work
19:55:40 mnaser sean-k-mooney: but what if you use default_schedule_zone=nova :)
19:55:59 sean-k-mooney then it will populate that in the request spec
19:56:06 sean-k-mooney and you cna migrate within that
19:56:26 mnaser but in my case, lets imagine it was set to default_schedule_zone=foobar and now we're trying to clean it up to be all inside `nova`
19:56:41 sean-k-mooney mnaser: right that is not supported
19:56:49 mnaser hence the bad things(tm)
19:56:50 sean-k-mooney so your in for pain
19:56:55 sean-k-mooney yep
19:57:13 sean-k-mooney operator do tend to do that form time to time i have noticed
19:57:15 mnaser i expect to be told collect the broken pieces on my own if it breaks :)
19:57:24 sean-k-mooney so maybe there should be a way to do that at some point
19:57:40 mnaser i think its cause operator feel that az's are not very 'heavy' constraints
19:57:53 mnaser and then many years go by and you're like oh wait this isn't straight forward...
19:58:32 sean-k-mooney right AZ are thigns you set up once and never touch as its user facing
19:58:47 sean-k-mooney host aggrartes you can change to your hearts delight as they are not
19:59:45 sean-k-mooney you proably know as well as anyone that openstack AZ are not like aws AZ where each maps to a different datcenter/fault domain
20:00:04 sean-k-mooney but in terem of thinking about changing them you shoudl treat them that way
20:01:05 mnaser yeah but im saying host aggregates seem flexible, az's are hard set
20:01:16 mnaser the mix of both probably gives the impression that one is just as flexible as the other
20:01:39 sean-k-mooney yep and the fact that an az is just a metadata tag on a hsot aggreate probly does not help
20:02:55 sean-k-mooney i never want to write this but i could see someine writing a nova manage command or something that would move a host or vms betwen azs but realticly that will better live out of tree
20:04:08 sean-k-mooney there are far to many choices to make on what to do. do you jsut update the AZ in the db or do you move vm to other node in the az they requested if set and move the other or one that are in a specifed az to the new az
20:04:53 mnaser yeah the combination of possible scenarios is .. a lot
20:06:01 sean-k-mooney and likely will be defferent for each operator/case
20:06:15 sean-k-mooney which is why we have never stdardised a tool to do this in nova
20:08:32 sean-k-mooney mnaser: https://review.opendev.org/c/openstack/nova/+/798145 for https://bugs.launchpad.net/nova/+bug/1934770
20:08:44 sean-k-mooney mnaser: that is proably of interset to you
20:09:32 sean-k-mooney mnaser: your migrate issue might be similar
20:10:56 sean-k-mooney mnaser: we could consider allowing cross az live/cold migrate explcitly in the api as a new fature at somepoint
20:11:34 sean-k-mooney mnaser: that would allow you to move host between az by live migrating the vms to the new az and then when the host is empty just remove it form one and add it to the other
20:12:19 sean-k-mooney spcifying an az to live/cold migrate woudl have to update the request spec and other db filed with the new az but it could be done
20:12:27 sean-k-mooney althogh not this cycle at this point
20:12:42 sean-k-mooney anyway i need to call it a day
23:01:53 opendevreview Ghanshyam proposed openstack/nova master: DNM: testing https://review.opendev.org/c/openstack/nova/+/794863
#openstack-nova - 2021-07-15
01:31:28 opendevreview Ghanshyam proposed openstack/nova master: DNM: testing https://review.opendev.org/c/openstack/nova/+/794863
02:28:45 opendevreview Takashi Kajinami proposed openstack/nova master: Fix request path to query a resource provider by uuid https://review.opendev.org/c/openstack/nova/+/800855
03:33:17 zhangtongjian songwenping__:hi
03:34:10 zhangtongjian songwenping__: hello
08:06:08 bauzas hola folks
08:09:09 bauzas just reading a few things
08:10:17 bauzas mnaser: never ever play with default_schedule_zone=nova ;) see the big warning quote in red on our upstream docs : https://docs.openstack.org/nova/latest/admin/availability-zones.html
08:28:14 gibi bauzas: o/
08:28:20 gibi bauzas: welcome back
08:28:59 gibi bauzas: if you are looking for a review for warm up then I suggest https://review.opendev.org/c/openstack/placement/+/784020 :)
09:06:18 bauzas gibi: doing email scrubbing will look for surez
09:25:02 gibi thanks
09:47:24 opendevreview Stephen Finucane proposed openstack/nova master: tests: Silence SQLAlchemy warnings https://review.opendev.org/c/openstack/nova/+/800900
09:47:25 opendevreview Stephen Finucane proposed openstack/nova master: tests: Remove unnecessary warnings filter https://review.opendev.org/c/openstack/nova/+/800901
09:54:04 stephenfin bauzas: Think you could look at the first of those. It's dead simple and would remove a *lot* of noise from our CI logs. I'll bug gibi/melwitt when they're back
09:54:08 stephenfin / around
10:03:27 bauzas stephenfin: ack
10:43:58 opendevreview Stephen Finucane proposed openstack/placement master: objects: Replace implicit conversion of SELECT into FROM https://review.opendev.org/c/openstack/placement/+/800910
10:43:59 opendevreview Stephen Finucane proposed openstack/placement master: tox: Remove psycopg2 warning filter https://review.opendev.org/c/openstack/placement/+/800911
10:44:28 stephenfin bauzas: Another two for you. That should get rid of all of our warnings, hopefully ^
11:00:10 stephenfin gibi: Care to look at https://review.opendev.org/c/openstack/nova/+/800900 to silence all those awful SQLAlchemy warnings for now?
11:13:15 gibi stephenfin: thanks for creating that WA ^^
11:16:48 opendevreview Merged openstack/placement master: Move placement specs from nova https://review.opendev.org/c/openstack/placement/+/800769
11:44:01 opendevreview Merged openstack/nova master: tests: Silence SQLAlchemy warnings https://review.opendev.org/c/openstack/nova/+/800900
11:44:47 gibi gmann: I've read the spec and the IRC discussion about the hypervisor uuid. I think if we want to make progress in X then we should go with the microversion route (option 3 in the spec) as we have specfreeze today. This should not prevent us to continue talking about creating some solution that is backportable.
11:46:16 gibi gmann: regarding the backportable fix; is there a way today for the admin to customize the new RBAC policies in a way to implement option 1?
11:47:03 gibi I got that our default is not good for them out of the box, but is there a way for them to change the policy.yaml in a way that solves the listing problem?
11:50:56 opendevreview Merged openstack/nova-specs master: Re-propose nova-audit spec for Xena https://review.opendev.org/c/openstack/nova-specs/+/800570
12:08:14 opendevreview Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362
12:08:15 opendevreview Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363
12:08:16 opendevreview Yongli He proposed openstack/nova master: smartnic support - create arqs https://review.opendev.org/c/openstack/nova/+/758944
12:08:16 opendevreview Yongli He proposed openstack/nova master: smartnic support - build instance with smartnic arqs https://review.opendev.org/c/openstack/nova/+/798249
12:08:17 opendevreview Yongli He proposed openstack/nova master: smartnic support - cleanup arqs https://review.opendev.org/c/openstack/nova/+/798054
12:08:17 opendevreview Yongli He proposed openstack/nova master: smartnic support - reject server move and suspend https://review.opendev.org/c/openstack/nova/+/779913
12:08:19 opendevreview Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147
12:52:08 ganso bauzas, lyarwood: Hi! sorry to bother about this again, if you could please take a look at backport https://review.opendev.org/c/openstack/nova/+/800114 when you have a minute, it is the last in the series, just needs one last +2 and +W to go. Thanks in advance!

Earlier   Later