| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-07-14 | |||
| 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! | |
| 14:07:20 | opendevreview | Alexandre arents proposed openstack/nova master: libvirt: Abort live-migration job when monitoring fails https://review.opendev.org/c/openstack/nova/+/764435 | |
| 14:12:55 | aarents | lyarwood: thks for review https://review.opendev.org/c/openstack/nova/+/764435 , I fixed the nits, As I said in comments I'm wondering if it closes also https://bugs.launchpad.net/nova/+bug/1536589 https://bugs.launchpad.net/nova/+bug/1924585 | |
| 14:13:43 | aarents | (older bugs I didn't see before) | |
| 14:26:52 | gmann | gibi: for option1, it cannot be olved via modified poliyc.yaml as GET hypervisor API is scoped to 'system' which is not overridable in policy. | |
| 14:28:32 | gmann | gibi: but we have workaround in different way, 1. system admin give hypervisor name to project admin via non-api way (some document, email or so) 2. assigning the multi role to token like project admin gets the system admin role for that specific request. | |
| 14:30:06 | gibi | gmann: I guess making the scope overridable via policy.yaml would also be considered a feature and hence wont be backportable | |
| 14:30:07 | gmann | gibi: regarding spec for Xena, as we still support legacy policy we have not broken operator yet. I am not so confident/confirm on what solution is best for which use case from operator. I think it is better not to hurry for Xena. | |
| 14:30:54 | gmann | gibi: humm, that will change the design of new RBAC. initial thought was to keep scope as hardcoded for secure security. | |
| 14:31:49 | gibi | gmann: OK, then that is probably a rabbit hole we don't want to go down | |
| 14:32:16 | gmann | yeah, or need more discussion as these project-admin issue were not considered before | |
| 14:32:51 | gmann | I think we should discuss this again in PTG, and also what other project doing for their project-mapped resources need system info | |
| 14:33:18 | gmann | having a consistent solution among all service will matter for operator even that is not best | |
| 14:33:21 | gibi | maybe we can create a simple WA config flag in nova conf that changes the scope of the hypervisor API. that would be ugly but backportable | |
| 14:35:28 | gmann | we have flag to disable the scope check so that is what operator can do. for scope, I am more inclined towards hardcoded only. | |
| 14:35:41 | gmann | but that flag is for all the policy not for particular one | |
| 14:36:55 | gmann | gibi: dansmith but on backport I am re-thinking - does it solve the issue of interrogability or feature-notification ? as many cloud might be upgrading from ocata or less where we cannot backport ? | |
| 14:37:29 | gmann | gibi: dansmith ah sorry, new RBAC is since ussuri so we are good if any backportable soltuion. | |
| 14:37:56 | gmann | and for < ussuri, we anyways have old policy keep working for them | |
| 14:40:48 | gibi | gmann: so the disable scope check flag can be used as a WA? | |
| 14:41:49 | gmann | gibi: right, "disable scope check + override policy.yaml" is WA | |
| 14:42:10 | gmann | that way I think this is not so bad right? | |
| 14:42:26 | gibi | is that enough for stable branches or you would like some extra help for the deployers? | |
| 14:42:41 | gibi | for me it does not sound bad | |
| 14:43:06 | gmann | and fix the default with microversion... ? | |
| 14:43:44 | gibi | yep, fix the situation master | |
| 14:45:14 | gmann | my only concern is disable scope check is for all the policy. BUT nobody has moved to scope check yet so I think it is fine. | |
| 14:45:52 | gmann | gibi: do i have time to make it in Xena. if i update the spec today (right after the TC meeting 1.15 hr from now) ? | |
| 14:46:31 | gmann | I think I am fine on 'doing it in microversion + document the WA' | |
| 15:10:18 | melwitt | elodilles: heads up, I backported the super squash to stable/train https://review.opendev.org/c/openstack/nova/+/795435 here, although ... afaict the gate is no longer broken on train? not sure what happened | |
| 15:10:19 | gibi | gmann: sure. I will review the spec after you updated and we can ask sean-k-mooney or dansmith to give the other +2 | |
| 15:12:43 | gmann | gibi: thanks | |
| 15:13:35 | gibi | gmann: also I don't think anyone will be mad if we land that spec tomorrow :) | |
| 15:17:17 | gmann | gibi: ack | |
| 15:18:27 | gibi | gmann: just ping me when the spec is up. I will be on and off during my evening / night but I will be working as my wife does too | |
| 15:19:10 | gmann | gibi: sure, thanks | |
| 15:25:07 | opendevreview | Merged openstack/nova stable/stein: Error anti-affinity violation on migrations https://review.opendev.org/c/openstack/nova/+/800114 | |
| 15:39:47 | opendevreview | Balazs Gibizer proposed openstack/placement master: Bump os-resource-classes requirements https://review.opendev.org/c/openstack/placement/+/796595 | |
| 15:41:18 | elodilles | melwitt: the gate was not broken in train, but tosky suggested that for convenience we should backport the zuulv3 job patch to train as well. however I am not fond of this patch to backport when we don't really need it o:) | |
| 15:42:21 | melwitt | elodilles: ah, ok, I wasn't 100% clear on the context there. I am neutral about it | |
| 15:43:49 | elodilles | well, I don't have hard feelings either, so if stable cores insist then I'm not completely against it :) | |