Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-10-26
14:40:48 sean-k-mooney we disucssed that in the spec
14:40:56 sean-k-mooney ill have to compare to what we agreed
14:41:16 dansmith gibi: you were +2 on this initially, can you +W now that I've addressed the feedback? https://review.opendev.org/#/c/756534/
14:46:03 tobias-urdin sean-k-mooney: that means the race is there, so the better way would be that neutron notifiers nova when the port is done on the destination node (i.e the neutron agent has fixed the port and it's ready for use)
14:46:30 tobias-urdin i can provide more debug information from the neutron ovs agent details if you want, i.e more lines than i posted in the launchpad bug
14:46:35 sean-k-mooney tobias-urdin: to be clear this is a seperate issue form the bug your commeting on
14:47:05 tobias-urdin sean-k-mooney: yeah, i understand that now, hence we will be running the patch is linked as a workaround for now
14:47:06 sean-k-mooney tobias-urdin: there is an implcit race in this logic by desgin
14:47:10 tobias-urdin or do you think there is a better workaround?
14:47:29 tobias-urdin i got a little big scared by your comment on that patch, did u see the question there?
14:47:36 sean-k-mooney it seam like you are hitting that implict race but its not clear we can ever fix that
14:47:51 gibi dansmith: looking...
14:48:51 sean-k-mooney tobias-urdin: the conclict/question basicely comes down to should neutron set the link state to active for inactive port bindings
14:50:11 gibi dansmith: done +2 +A
14:50:58 tobias-urdin sean-k-mooney: im thinking in the terms of neutron sending a network-vif-up to nova, so that nova can wait for the port to come up, but maybe the nova driver hands of the resume of a migrated instance to libvirt so it never handles the last part of the live-migration
14:51:23 dansmith gibi: thanks
14:51:37 sean-k-mooney when there was only one port binding pre rocky neutorn would wire up the port and sicne there was only one binding it would consider it active at that point
14:52:12 tobias-urdin sean-k-mooney: it's a pretty bad race though, since it's a complete outage for a vm until some traffic is generated from inside (which could be pretty much never)
14:52:28 tobias-urdin sean-k-mooney: what do you see as the best workaround?
14:52:32 tobias-urdin for now
14:52:50 tobias-urdin also my last comment on https://review.opendev.org/#/c/741529/
14:52:53 sean-k-mooney tobias-urdin: are you using postcopy
14:53:52 tobias-urdin live_migration_permit_post_copy is unset so default (false)
14:54:06 sean-k-mooney tobias-urdin: so our libvirt/qemu team say that once you use the qemu commands it marks the instacne as tainted and they nolonger will support it
14:54:38 sean-k-mooney e.g. if you ever use raw qemu command vi libvirt you nolonger have support for that vm from redhat virt team
14:55:43 sean-k-mooney tobias-urdin: some qemu monitor command can break libvirt or currpt the guest
14:56:10 sean-k-mooney tobias-urdin: specificly some of the lowlevel block deivce commands
14:56:40 tobias-urdin sean-k-mooney: ok, i'm more curious the reasoning because, if the command im running adds a risk
14:56:52 tobias-urdin but maybe that more of a question for somebody on that team
14:56:53 sean-k-mooney that command does not
14:57:12 sean-k-mooney but we dont want ot say yes and no on a per command basis
14:57:42 sean-k-mooney that said danpb said adding a libvirt api for this would be a resonable thing to do
14:58:39 tobias-urdin sean-k-mooney: i c, so the workaround is to stop using the new multiple port binding feature (which means patching code) or using my patch (which means patching code)
14:58:55 sean-k-mooney tobias-urdin: no there is a longer race in that case
14:59:08 sean-k-mooney tobias-urdin: i think neutron change teh behavior in the l2 agent
14:59:24 sean-k-mooney to require that it has an active portbining on the host
14:59:27 tobias-urdin so if no changes are merged upstream, i still have to fix it downstream in our running nova/neutron code by patching it
14:59:58 sean-k-mooney i think this is something we need to talk about with the neutron folks
15:00:21 sean-k-mooney and come up with a supportable way forward
15:00:29 tobias-urdin sean-k-mooney: roger that, thanks for your time!
15:40:12 gibi stephenfin: mypy is killing me. :) these tests mypy tests work until I add a simple member function to the class here https://github.com/gibizer/ovo-mypy-plugin/blob/main/ovo_mypy_plugin/tests/test.py#L54
15:40:51 gibi stephenfin: somehow it makes the fields.IntegerField name undefined in the scope of the fields dict
15:41:00 gibi craaazyyy
15:59:18 bauzas gibi: one of my points => if you need more time for providing mypy types to all the methods than the time you need to review new changes, then why should we supporting it ?
15:59:38 bauzas we have gerrit for this :)
16:00:18 lbragstad gmann o/ is there a way for project admins to discover host information?
16:00:19 lbragstad https://opendev.org/openstack/nova/src/branch/master/nova/policies/servers.py#L178-L190
16:01:30 lbragstad gmann i'm wondering if a deployment opted into using the new defaults for nova, would that expose an API to project-administrators that they shouldn't have?
16:01:47 lbragstad or if it's not really useful since they can't discover compute hosts anyway
16:05:09 bauzas anyway, /me needs to leave \o
16:05:14 gibi bauzas: I'm working on a mypy plugin that understands oslo versionedobjects and inject the dynamic field information to the static analyzer. If I can make it work then it potentially opens up the possibility to typecheck a lot of nova code tight to o.vos
16:05:51 bauzas well ok
16:06:12 bauzas but honestly, I can still review on any object modification and look at this
16:06:29 gibi bauzas: sure it is not to replace code review
16:06:35 sean-k-mooney lbragstad: we dont really have project admins
16:06:35 bauzas it's simple for o.vo objects
16:06:45 bauzas gibi: but fair enough
16:06:46 sean-k-mooney lbragstad: project admins are admins
16:06:58 lbragstad sean-k-mooney ok - i was just looking through the policy and noticed that comment
16:07:13 lbragstad it looks like only system administrators can list and view hypervisors and services
16:07:27 sean-k-mooney i dont think we make a distinciton
16:07:48 sean-k-mooney lbragstad: between a system admin and any other type of admin
16:08:02 sean-k-mooney unless that has changed with the scopes thing
16:08:27 lbragstad https://opendev.org/openstack/nova/src/branch/master/nova/policies/hypervisors.py#L37
16:08:27 lbragstad looks like it did
16:08:32 lbragstad https://opendev.org/openstack/nova/src/branch/master/nova/policies/base.py#L111
16:18:51 lbragstad sean-k-mooney i think i figured it out - thanks
16:22:40 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: Re-propose "Secure Boot support for KVM & QEMU guests" for Wallaby https://review.opendev.org/759731
17:53:35 gmann lbragstad: yeah that is one of the todo to make system admin to create server for projects so that host info etc can be passed in.
17:54:12 lbragstad gmann got it
17:54:13 gmann lbragstad: project admin can get host info of existing server via GET /servers
17:55:00 lbragstad any project user can do that, but only project administrators can exploit creating a server on a specific host, right?
17:55:02 gmann and that way they can use current default which is PROJECT_ADMIN. not perfect default for now but something to improve with microversion
17:55:12 gmann lbragstad: yes
17:55:27 lbragstad ok - cool
18:00:55 admin0 hi guys .. how to fix placement database .. a compute node with instances has now a different uuid than what it was originally added as
18:01:29 admin0 so when nova-compute runs, it says unable to add host as name already exists
18:01:45 admin0 is it safe to rename a compute node while there are instances running there
18:05:17 openstackgerrit Balazs Gibizer proposed openstack/nova master: WIP: add ovo-mypy-plugin to type hinting o.vos https://review.opendev.org/758851
22:17:36 gmann gibi: I added one topic 'Allow system admin to create server for other projects' in etherpad L458 - https://etherpad.opendev.org/p/nova-wallaby-ptg
22:18:18 gmann gibi: I will be TC sessions on friday, if we can discuss it before Friday. anytime other than Friday I am ok.
22:18:36 gmann sorry for adding it late.
22:30:26 gmann gibi: basically two, one for policy warning also
#openstack-nova - 2020-10-27
00:55:17 openstackgerrit Merged openstack/nova stable/stein: Allow tap interface with multiqueue https://review.opendev.org/757886
08:03:22 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Re-proposes 'Proposal for a safer remote console with password authentication https://review.opendev.org/759828
08:07:35 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Re-proposes 'Proposal for a safer remote console with password authentication https://review.opendev.org/759828
08:36:31 gibi gmann: OK, I moved both of your topic for Thursday
08:38:04 bauzas good morning Nova
08:39:00 gibi bauzas: good morning
08:45:20 lyarwood Morning
08:47:35 bauzas :)
08:48:06 bauzas gibi: fwiw, I was trying to attend the cyborg session this morning about vGPU management, but I didn't have time for it
08:48:43 bauzas gibi: I'm trying to shepherd their spec https://review.opendev.org/#/c/758925
08:48:58 bauzas brinzhang_: around ?
08:50:50 openstackgerrit Jorhson Deng proposed openstack/nova master: Reject to attach and detach volume while task_state is not None https://review.opendev.org/758918
08:59:43 gibi bauzas: There is a long writeup on https://etherpad.opendev.org/p/nova-wallaby-ptg for the cyborg crossproject about gpus
08:59:56 gibi ~L50
09:00:33 bauzas gibi: yup i saw it, but I have a lot of open questions about it
09:01:31 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Only ask tpool.Proxy to autowrap vir* classes https://review.opendev.org/759831
09:02:27 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Only ask tpool.Proxy to autowrap vir* classes https://review.opendev.org/759831

Earlier   Later