Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-24
15:02:00 mriedem yeah the bug needs to be fixed regardless
15:02:03 mriedem and most likely backported
15:03:11 bauzas okay, thanks for cleaning up the mess in my brain
15:03:15 bauzas I'm all clear
15:05:19 bauzas jaypipes: so, you told me we don't DELETE allocations right now but only when we self-heal ?
15:05:23 openstackgerrit Stephen Finucane proposed openstack/os-vif master: HW offload support for openvswitch https://review.openstack.org/398277
15:05:24 openstackgerrit Stephen Finucane proposed openstack/os-vif master: Add documentation for Linux Bridge plugin https://review.openstack.org/459291
15:05:32 bauzas jaypipes: that's something that needs to change then
15:06:31 jaypipes bauzas: no, sorry, I was referring to instances that were terminated but the compute host was down at the time.
15:06:53 jaypipes bauzas: in a "normal" DELETE /servers call, the allocations are indeed deleted.
15:07:05 bauzas okay, looking at code
15:07:41 sean-k-mooney sfinucan: moshele: on the vnic type i dont think this should be documented seperatly per plugin as they are common across all plugins
15:08:09 sfinucan sean-k-mooney: Have you seen the patches themselves
15:08:31 sfinucan They're common, yes, but not all VIF types are supported across all plugins
15:08:41 sfinucan I didn't grasp that nuance until this morning
15:09:30 bauzas jaypipes: mmm, can't find where we call DELETE /allocations in the compute manager, but only in the RT
15:09:42 sean-k-mooney sfinucan: no i havent atleast not lately. correct that is why im working on https://review.openstack.org/#/c/441590/
15:10:09 sean-k-mooney i am hoping to implement the nova neutron negociation this cycle if i can ever finish the supprot for ovs-dpdk in kolla
15:10:15 jaypipes bauzas: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L716-L731
15:10:38 jaypipes bauzas: that's called at the end of the manager's _delete_instance() method.
15:10:49 bauzas ok, seeing it noxw
15:10:54 bauzas we force a RT update
15:11:00 bauzas which will delete the allocation, gotcha
15:11:02 jaypipes bauzas: the _update_resource_tracker() call eventually calls the scheduler client.
15:11:06 jaypipes right.
15:11:14 sean-k-mooney sfinucan: the host_info object discribes what vif types are supported by each plugin and it will with that patch allso describe what port profiles are supporte db each vif_type per plugin
15:11:27 bauzas jaypipes: okay, no explicit allocation delete, RT handles that
15:11:45 bauzas jaypipes: thanks, so nothing needed from a scheduler claims spec perspective
15:11:51 bauzas jaypipes: except the local delete problem
15:12:01 sean-k-mooney sfinucan: this object will be serialsed into the neutron binding profile and read by the mechanisum drivers as part of the port binding call.
15:12:11 jaypipes bauzas: no, that's still called for soft deletes.
15:12:20 sfinucan sean-k-mooney: Nice. I wasn't aware of host_info either
15:12:23 bauzas jaypipes: local delete != soft delete
15:12:37 jaypipes bauzas: no?
15:12:38 bauzas jaypipes: if the RPC compute service is down, we local delete in the api worker
15:12:57 bauzas totally unrelated to soft deletes, which are just a specific VM state
15:12:59 jaypipes bauzas: right. the api worker sets instance to SOFT_DELETED
15:13:04 bauzas no no
15:13:07 bauzas sec
15:13:07 jaypipes no?
15:13:14 bauzas yet another fun
15:13:22 sfinucan sean-k-mooney: Do you think there's value in documenting the built-in plugins, in that case, as done here https://review.openstack.org/#/c/459258/2
15:14:01 bauzas jaypipes: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2001 and https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2027-L2032
15:14:05 sfinucan i.e. the plugins themselves along with a little summary of how a given VIF type works in the given plugin/networking backend
15:14:08 sean-k-mooney sfinucan: so the other part of this is that in the future the mapping we currently do between teh existing vif types and the os-vif ones will go away with neutron specifying plugin,vif_type and port prifile in a single os-vif object as a responce to nova in the port binding call
15:14:15 sean-k-mooney sfinucan: ill take a look at it now
15:14:33 mriedem melwitt: dansmith: some easy dead code cleanup in conductor https://review.openstack.org/#/c/434615/
15:14:35 bauzas jaypipes: mriedem mentioned a bug report because we do delete the instance but we don't delete the allocation
15:14:51 bauzas jaypipes: https://bugs.launchpad.net/nova/+bug/1679750
15:14:52 openstack Launchpad bug 1679750 in OpenStack Compute (nova) "Allocations are not cleaned up in placement for instance 'local delete' case" [Medium,Confirmed]
15:15:04 bauzas FWIW, I'll assign myself to the bug since it's related to the claims spec
15:15:09 mriedem jaypipes: we don't soft delete in the api if the compute host is down
15:15:28 mriedem jaypipes: we send out notifications saying we're soft deleting, but really we don't
15:15:30 mriedem we hard delete that mofo
15:15:41 sean-k-mooney sfinucan: so i dont think we should have redefinition of the vif types per plugin but i would be ok with referencing the vif types that are definded globally
15:15:41 mriedem this has been keeping gibi awake at night
15:16:06 sean-k-mooney sfinucan: essentailly like you have done with the glossary
15:16:26 sean-k-mooney define each fo them as a term or link back to the singel definition.
15:16:28 dansmith mriedem: I don't think that's dead code
15:16:31 mriedem jaypipes: https://review.openstack.org/#/c/443764/1/nova/compute/api.py@2066
15:16:32 bauzas oh man, just got an email asking me to take all my holidays before end of May
15:16:40 bauzas that's going to be legendary
15:16:53 sfinucan sean-k-mooney: Basic VIF definitions do exist - see 'doc/source/vif_types'
15:16:59 sfinucan bauzas: dibs!
15:17:43 mriedem dansmith: you can't upgrade the schema if you don't have cell0 in ocata
15:17:46 sean-k-mooney each plugin could discibe the the vif types it support but i would prefer to auto generate that documention form https://github.com/openstack/os-vif/blob/e133b8a3771ce6a49594af83b90586bdd88630ae/vif_plug_ovs/ovs.py#L67-L83 if we could
15:17:53 bauzas I'm always ashamed to speak about that here, but if I would take all my holidays, it could probably require me to stop working right after I come back from BOS :/
15:18:02 dansmith mriedem: unless you have an empty database because you're installing ocata for the first time
15:18:03 bauzas like not working for May
15:18:16 dansmith mriedem: and if you miss putting that record in, you get a unhelpful error condition
15:18:21 mriedem dansmith: if you have any empty db, how are you creating instances?
15:18:23 jaypipes mriedem: lovely..
15:18:25 sean-k-mooney sfinucan: any chance we could use something like your sphix click intergration to do taht
15:18:40 sean-k-mooney if not im sure i coudl script something up
15:18:57 dansmith mriedem: you had an empty database when applying the schema migrations, which made it past the cell0 check, then you start creating instances without doing your cell record setup
15:19:02 mriedem dansmith: this https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api_migrations/migrate_repo/versions/030_require_cell_setup.py
15:19:13 dansmith mriedem: right but that doesn't do anything for a fresh install
15:19:15 mriedem oh the gd flavor thing
15:19:21 mriedem ffs
15:19:52 mriedem jaypipes: yes soft delete is a turd
15:19:55 mriedem which should be flushed
15:21:21 mdbooth +1
15:21:38 sean-k-mooney sfinucan: basically in the docs job all we would need to do is load os-vif. loop over all the in tree plugins, call discribe and template our a descripts into a folder and then have sphinx auto include it in the docs that way its automatic and always up to date
15:22:37 sfinucan sean-k-mooney: I could but it might be overkill
15:22:50 sfinucan Realistically, how often are those lines going to change
15:23:25 sfinucan and, iirc, the plan is not to add any more plugins in os-vif (they should live in separate repos)
15:23:38 sean-k-mooney not that often we could just make it a requirement for adding more vif_types or port profiles to existing plugins as part of ongoing reviews
15:23:50 sean-k-mooney yep
15:24:31 mriedem dansmith: ok left a reply - but if we don't have cell0 to bury, we still have the build requests to list 'instances' and delete that 'instance', but we don't update the vm_state on the build request to ERROR
15:24:43 mriedem so those 'instances' just get stuck in scheduling state until you delete them (i think)
15:24:50 sean-k-mooney more vif types will be added to both plugins though and more port poriles but it wont be a large overhead to manually update the docs.
15:25:19 sfinucan sean-k-mooney: Yeah, I don't think it would be too much of a requirement
15:25:36 sfinucan docs usually help reviews anyway because they give way more context
15:26:33 sean-k-mooney sfinucan: one of the requests i got from the neutron folks was to allow os-vif to plug non vm interfaces so they could use it to plug the dhcp,l3 and tunnel ports when its intergrated into neutron
15:26:52 sean-k-mooney i opened some bugs for those with too do to fill them out later
15:27:47 dansmith mriedem: yep, but we have to have the big red warning I think
15:28:31 mriedem yeah i suppose.
15:28:45 sean-k-mooney we will need about 5 or 6 new vif_types to cover that (patch,vif_pair,vxlan,gre,geneve) i think im missing one but basically same pattern as vms and form and os vif point of view we dont really care what uses the port anyway.
15:29:00 mriedem dansmith: if we wanted to get the instance into ERROR state, we'd have to deserialize the build_request.instance, set it's vm/task state and then update the build_request right?
15:29:07 sfinucan sean-k-mooney: nova wouldn't care about those new ones, right?

Earlier   Later