Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-08-31
16:18:32 sean-k-mooney we dont actully have the instance object where this is called https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/scheduler/manager.py#L150
16:19:01 bauzas sean-k-mooney: right, because that's in the scheduler
16:19:31 bauzas sean-k-mooney: a simple approach would be to mention the requested networks on the main request spec object
16:19:33 sean-k-mooney sure but the fact we are in schduling means the object exists
16:19:42 sean-k-mooney bauzas: yes
16:19:54 bauzas sean-k-mooney: do you think we would persist those ?
16:20:18 bauzas or should we guess them for a move operation ?
16:20:36 sean-k-mooney the requested networks
16:20:39 bauzas yes
16:20:46 bauzas this is risky
16:20:57 sean-k-mooney if we add them to the request spec and use them we need to update them when we add or remove interfaces
16:21:13 sean-k-mooney oh
16:21:13 bauzas only when you want a scheduling decision
16:21:22 bauzas so, yeah we need to recalculate them
16:21:28 sean-k-mooney is the network info cache populated yet
16:21:36 sean-k-mooney we have the instance uuid right
16:21:36 bauzas no, I don't think
16:21:41 sean-k-mooney damb
16:21:46 bauzas sean-k-mooney: only for the first instance
16:22:14 bauzas sean-k-mooney: but I'd say, just populate this field at boot time based on the base options
16:22:20 sean-k-mooney well select destinations has instance_uuids
16:22:28 bauzas sean-k-mooney: and for a move, just try to get them from the info cach
16:23:00 bauzas sean-k-mooney: I don't want to add a new arg to the filter
16:23:10 bauzas sean-k-mooney: all of this needs to be in the request spec
16:23:13 bauzas but I get your point
16:23:40 sean-k-mooney well we can update the request_spec.instance_uuid field
16:23:48 bauzas we could get the requested networks from the info cache in the scheduler, add them on the fly before calling the pre-filter and wipe them after
16:23:56 bauzas oh please no
16:24:15 sean-k-mooney for i think we already do in once case for multicreate
16:24:21 sean-k-mooney we had to fix someting related to this
16:24:45 sean-k-mooney i think it was the numa toplogy
16:25:47 sean-k-mooney bauzas: yes
16:25:52 sean-k-mooney so if you were to do that
16:25:56 sean-k-mooney i would not add a new fiedl
16:26:08 sean-k-mooney jsut set the info on the object directly
16:26:12 sean-k-mooney that way it wont persist
16:26:23 sean-k-mooney we do that in some places today
16:26:42 sean-k-mooney e.g. request_spec.temp_var = my thing
16:27:09 sean-k-mooney im not sure its the request spec object we do that for but its why we dont error if you set a filed on an ovo that does not exist
16:27:24 sean-k-mooney because nova ocationally stores info in them that is never serialised
16:28:04 gibi you can add a proper ovo field that is not persisted
16:28:10 gibi that would be a bit more readable
16:28:22 sean-k-mooney can you? i did not know that
16:28:28 bauzas surely you can
16:28:41 sean-k-mooney well i was not aware we were already doing that
16:28:57 bauzas the network metadata field, for example :D
16:29:14 bauzas this one is lazy loaded
16:30:10 sean-k-mooney is that contoled by https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L36?
16:30:15 gibi requested_resourceshttps://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L566-L573
16:30:48 bauzas sean-k-mooney: not really controlled, just we know what to look up from DB with this list
16:31:01 sean-k-mooney https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L538-L556
16:31:07 sean-k-mooney so that is built form the info cache
16:31:20 bauzas https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L137
16:31:35 bauzas sean-k-mooney: only for all ops but create
16:33:28 sean-k-mooney this is where its filtered out
16:33:31 sean-k-mooney https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/objects/request_spec.py#L655-L657
16:34:39 sean-k-mooney which we call in create before we create it in the db
16:34:51 sean-k-mooney then we load back from the db object
16:35:41 bauzas sean-k-mooney: that's the standard way of providing a ovo field that's not persisted
16:36:01 sean-k-mooney "standard" i was expecting to have a flag in the field deffintion
16:36:12 sean-k-mooney like nullable=false
16:36:20 sean-k-mooney but persit=false instead
16:36:20 bauzas ie. you explicitely provide a lazy-loading mechanism for getting it, but you also delete its primitive before persisting to the DB
16:36:36 bauzas sean-k-mooney: oh no, that's made thru code patterns :)
16:37:04 bauzas so, I could technically add a new field
16:37:09 bauzas make it lazy-loadable
16:37:11 sean-k-mooney ya this is proably less readable then just doing object.whatever=somethign
16:37:29 sean-k-mooney its certenly more complicated and eaiser to mess up
16:37:29 bauzas and make sure we populate it from the info cache when we can
16:38:04 bauzas sean-k-mooney: well, I know our objects before they were called o.vo :)
16:38:14 bauzas that certainly helps :)
16:38:33 sean-k-mooney yep but that does not mean we should keep doing it this way
16:38:38 sean-k-mooney its rather archane
16:38:50 sean-k-mooney i can follow it but its not obvious and its not a clean approch
16:38:54 sean-k-mooney it certenly works
16:39:08 sean-k-mooney but this is definetly techdebth
16:39:25 sean-k-mooney addign a property to the class and using it would be cleaner
16:39:40 sean-k-mooney or addign it as a flag on the field and doing it in ovo
16:40:04 sean-k-mooney i guess its not really ovo but the db code
16:48:42 bauzas sean-k-mooney: I'll make a proposal tomorrow morning
16:50:02 sean-k-mooney we shoudl put the segment info in the nova.network.vifobject
16:50:10 sean-k-mooney then get those form the cache
16:50:43 sean-k-mooney https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/model.py#L380-L404
16:50:59 sean-k-mooney well nova.network.model.Vif
16:51:21 sean-k-mooney or nova.network.model.VIF i guess is the corerct capitalisation
16:52:07 sean-k-mooney we can add a new segment filed to that object
16:52:26 sean-k-mooney these are not ovos
16:53:35 sean-k-mooney but those are what is stored in the info cache
16:54:16 sean-k-mooney they are constucted here https://github.com/openstack/nova/blob/b5d48043466b53fbdfe7b93c2e4efd449904e593/nova/network/neutron.py#L3026-L3076
16:58:57 sean-k-mooney this is called via allocate_for_instance which is also what populates the info cache
17:02:09 sean-k-mooney oh...
17:02:48 sean-k-mooney that is called first on the compute host. because we only auto allocate networks on compute host if we are passed network ids
17:09:27 bauzas sean-k-mooney: again, I won't modify the vif object
17:09:35 bauzas I think I have everything I need
17:09:53 bauzas we have the requested networks at boot time, so we can directly pass them thru the spec object
17:10:11 bauzas for the move operations, we can recalculate the requested networks from the vifs
17:10:15 bauzas that's it
17:10:43 bauzas hopefully, tomorrow I should be able to provide a new re
17:10:44 sean-k-mooney yes although im suggestign we should have the segments in the vif object anyway
17:10:45 bauzas rev

Earlier   Later