Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-12
15:03:06 sdague efried: what's the concern?
15:03:10 mriedem zioproto: this session was selected: http://forumtopics.openstack.org/cfp/details/21
15:03:20 efried sdague The opts are defined in castellan itself
15:03:43 efried sdague And they're *used* within castellan itself, not directly from Nova.
15:03:52 sdague oh, interesting
15:04:04 sdague how much do they diverge?
15:04:45 efried sdague So I could register the ksa opts in Nova with deprecations for the barbican names. And what I think would then happen is that castellan (still referring to them by their barbican names) would pick them up because the deprecations would alias them.
15:05:26 sdague yeh, it would be good to get the barbican/castellan folks engaged on that to figure out what their preference is
15:06:00 efried wrt divergence: there's barbican_endpoint vs. endpoint_override. And api_version vs. version - BUT in the ksa stuff we've been not letting the op dictate versions for the other services - I have a util that rips those opts out.
15:06:27 efried Sorry, barbican_api_version*
15:07:01 efried sdague So yeah, I think long term what we want is for castellan to deprecate in favor of the ksa opts.
15:07:15 efried If that happened, Nova wouldn't have to change anything.
15:07:25 gibi mriedem: could you report about the notification meeting on my behalf on the nova meeting?
15:08:20 efried sdague ...which I think is better than trying to force it in Nova in the interim.
15:09:42 efried sdague What IRC channel would a guy use to talk to barbican/castellan folk?
15:09:48 efried or should I hit the ML?
15:10:38 mriedem gibi: sure
15:11:09 mriedem efried: #openstack-barbican
15:11:14 efried got it
15:11:34 mriedem sdague: the keypair + rebuild spec updated the security impact section, i think this is what you were asking for but wanted to confirm http://docs-draft.openstack.org/21/375221/11/check/gate-nova-specs-docs-ubuntu-xenial/1f04019//doc/build/html/specs/queens/approved/rebuild-keypair-reset.html#security-impact
15:11:46 mriedem basically, you can't rebuild a server for another user and update the keypair at the same time
15:11:59 mriedem so don't inject user B's key into user A's serer
15:12:01 mriedem *server
15:12:07 sdague efried: also, if you find active people over there, please get them to come join here, because I've got a big chunk of feedback on their image singing work that needs to be there
15:12:21 sdague mriedem: honestly, it's not a security issue
15:12:42 sdague users don't really own servers
15:13:23 gibi mriedem: thanks a lot
15:13:25 mriedem so you think this is fine to do and should just be documented?
15:13:37 mriedem sdague: i'm trying to think if this would be surprising behavior
15:14:23 sdague mriedem: yeh, I just think we should document it
15:15:00 sdague I think it highlights that our notion of users owning keys is actually bad
15:15:08 sdague and projects should own keys
15:15:09 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Add release note for running nova-api under wsgi in Ocata https://review.openstack.org/511503
15:15:10 mriedem dansmith: reno for ocata to maybe help with the wsgi service version thing ^
15:16:12 mriedem sdague: ok want to make that comment on here https://review.openstack.org/#/c/375221/11/specs/queens/approved/rebuild-keypair-reset.rst@89 ?
15:16:17 sdague sure
15:16:29 mriedem the spec writer might not have been clear on this in PS10
15:16:34 mriedem i know i wasn't really
15:28:46 mriedem need dane-fichter around for this one too https://review.openstack.org/#/c/312225/
15:34:56 efried alex_xu My review is going to be missing some depth with respect to shared RPs and aggregates. Can you help me understand the architecture of those things a bit more?
15:35:29 efried Perhaps I need to go read the shared RP spec again. Maybe it'll make more sense now.
15:36:34 mdbooth dansmith: I replied to your 2 review comments on https://review.openstack.org/#/c/511466/ . If you get a chance to look again I'll update asap. Thanks!
15:41:06 openstackgerrit Stephen Finucane proposed openstack/nova master: disable numa feature when virt_type is not kvm https://review.openstack.org/465160
15:42:59 mriedem mdbooth: counter replied
15:43:18 mdbooth mriedem: Looking, thanks.
16:01:23 sean-k-mooney mriedem: do you have a second to discuss the multiple bindings? i have a question regarding mix old+new hosts
16:05:14 mriedem sean-k-mooney: sure
16:05:20 mriedem i haven't made it back to your replies in the spec yet
16:07:49 sean-k-mooney mriedem: going form old to new i can add code to create the binding if they are not found in the migration data and update the xml
16:07:58 sean-k-mooney mriedem: going for new to old i cannot
16:08:42 sean-k-mooney mriedem: so in this case if i detect that the bindings differ e.g. source linux bridge and dest ovs should i fail the migration at that point since
16:08:48 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Reset the instance keypair while rebuilding (spec) https://review.openstack.org/375221
16:08:49 mriedem sdague: updated ^
16:08:51 sean-k-mooney i know the xml will not be updated correctly
16:10:32 mriedem sean-k-mooney: when going from old to new, if you create the port binding, is it just for the dest host or both the source and dest?
16:11:29 mriedem i was kind of hoping to avoid the retype complexity in this, because that makes things weird
16:11:44 mriedem one reason for doing this is to simply cut down on network downtime during live migration,
16:11:47 sean-k-mooney well there will always be the source portbinding. so i would create the destination port binding on the destination host in that case and clean up the source binding if migration succeeded
16:11:52 mriedem another reason is to change vif types, yes?
16:12:18 sean-k-mooney mriedem: yes they are the 2 main usecases
16:12:25 mriedem how is there always a source port binding? i thought we didn't create port binding resources today at all? or you just mean the binding:profile in the port we already have?
16:12:42 mriedem like,
16:12:52 sean-k-mooney the port binding profile in the port we already have
16:13:00 mriedem i thought there is literally going to be a new neutron api which is like POST /ports/{uuid}/bindings
16:13:13 sean-k-mooney i need to double check but i taught that would be expsed via the new api automatically
16:13:23 openstackgerrit David Rabel proposed openstack/nova master: VMware: add support for graceful shutdown of instances https://review.openstack.org/494169
16:13:44 sean-k-mooney mriedem: yes there will be https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html#list-bindings
16:13:48 mriedem so if i do GET /ports/{id}/bindings, for existing ports it will give me at least one result based on the existing port's binding profile?
16:14:12 mriedem is there some data migration that neutron is going to do for that? or just a fallback lookup in the api code?
16:14:42 mriedem maybe this is already modeled and the API is just exposing it? https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html#data-model-changes
16:15:36 mriedem sean-k-mooney: so going back to your question,
16:16:00 mriedem what happens today if you try live migrating an instance with a linuxbridge vif on the source host to a dest host which is using ovs?
16:16:04 mriedem does vif plugging explode?
16:16:23 sean-k-mooney no everything works perfectly with no error... in that direction
16:16:30 sean-k-mooney but you have no network connectivity
16:16:49 mriedem ok so it doesn't work
16:16:57 mriedem it doesn't blow up, but it doesn't work, right?
16:17:03 sean-k-mooney what libvirt did undder the hood was creat a linux bridge an plug the tap into it and neutron never knew about it
16:17:27 sean-k-mooney so the live migration succeeds
16:17:43 sean-k-mooney if you do a hard reboot everything gets fixed
16:17:53 sean-k-mooney but the bridge does not get cleaned up
16:18:24 sean-k-mooney going the other way os-vif explodes if your linux bridge node does not have ovs-vsctl available
16:19:05 sean-k-mooney if it does same thing. we create and ovs bridge called br-int and add the tap to it and the linux bridge agent never know about it so it never get wired up
16:19:57 mriedem huh, seems like something we should be explicitly checking for and failing on during pre live migration
16:20:38 mriedem LB and OVS aside, i mean you also have like macvtap and vhostuser and all of the other vif types
16:20:46 mriedem so who know what goes wrong when migrating between those right?
16:20:50 sean-k-mooney mriedem: you would think so but this actully used to work before hevana but it was a undocument "feature" so it got broken in icehouse
16:21:27 sean-k-mooney mriedem: provided the vif model is still virtio then it actully works correctly if we can update the xml
16:21:54 mriedem can't we just assert that if both nodes in the live migration are not new enough to do the port binding thing that we don't allow it?
16:22:03 mriedem and the vif type changes i mean
16:22:23 sean-k-mooney yes we can that was what i was going to suggest
16:22:35 mriedem if the vif type doesn't change, then maybe we can still support the port binding thing for mixed version computes?
16:23:08 mriedem although if the dest host is old we won't have a port binding to flip to active in post live migrate
16:23:14 sean-k-mooney if the vif_type and vif binding_details does not change we should not need to update the xml either so we could activate the binding before live migrate
16:23:21 mriedem so we can really only do the port binding if going from old to new yes?
16:24:01 mriedem to reset, we plan to create the dest host port binding during pre live migration yes?
16:24:18 sean-k-mooney there are basically 3 cases where we have old+new. i am going to document them in the spec
16:24:21 mriedem that may or may not happen if we're doing that on an old ode
16:24:22 mriedem *node
16:24:30 mriedem that would be helpful :)

Earlier   Later