Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-02-26
11:14:23 gibi that would remove the need of a hint
11:14:40 gibi so it would remove the ~ API impact due to the hint
11:14:40 sean-k-mooney yes
11:15:07 rm_work sean-k-mooney: so, a post-filter that isn't in-tree, can't be a dependency of other services? I think?
11:15:09 sean-k-mooney it does require ues to lookup the segment of every neutron port however
11:15:22 rm_work I mean...
11:15:26 sean-k-mooney rm_work: well not normally no
11:15:38 sean-k-mooney rm_work: what other service are you thinking of
11:15:39 rm_work so, I'm trying to merge code in octavia that would use this
11:15:53 rm_work I linked the change earlier... let me find it again
11:15:57 gibi sean-k-mooney: we do lookup of neutron port information anyhow due to qos so while it is an extra query it is not a totally new thing in the boot and migrate code path
11:15:58 sean-k-mooney well you could package the filter in octavia
11:16:03 sean-k-mooney then i think it would be fine
11:16:13 sean-k-mooney but really im not sure there is time to do this this cycle
11:16:21 rm_work https://review.opendev.org/#/c/706153/
11:17:05 rm_work sean-k-mooney: i was hoping an "optional filter" that was essentially just a few lines would be easier to digest, and we could merge it with less controversy T_T
11:17:47 sean-k-mooney well from a paper work point of view that is not really allowed but being pragmatic maybe. this technical requirs a spec
11:17:59 gibi rm_work: the problem is the new hint, if we merge the filter now, we cannot really remove it later when a better approach is made as the hint becomes an API
11:18:07 rm_work it's fine, we are already running this filter internally (it's very simple to drop-in, as you say) so it's not a big deal. I am trying to unlock some of these features we're using to more folks by putting it upstream
11:18:44 sean-k-mooney rm_work: yep which is nice to see
11:19:13 rm_work for example: we have octavia working in a routed-network setup, and we have live-migrate working
11:19:20 gibi rm_work: and by being here and helping me understand the feature you actually made it a bit more likely that there will be upstream support for this
11:19:27 rm_work sorry, the "we" in this case is actually two orgs, but I've worked for both of them, heh
11:19:56 sean-k-mooney rm_work: for what its worth you could get the same effect by having an availabity zone per ip segment
11:19:59 gibi rm_work: so you made a good step forward here. sorry that this is not that straight forward that is could be. but I think we are in a good track
11:20:01 rm_work (I am working with jroll currently)
11:20:10 rm_work sean-k-mooney: unfortunately that's not an option, heh
11:20:11 sean-k-mooney that is what i know people have done in the past
11:20:23 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Remove native LUKS compat code https://review.opendev.org/669121
11:20:38 openstackgerrit Brin Zhang proposed openstack/nova master: Introduce scope_types in os-volumes-attachments policy https://review.opendev.org/709388
11:21:02 sean-k-mooney so there are a few paths forward.
11:21:34 sean-k-mooney 1.) experimtal prefilter that is disabled by default which would lookup the segment id of each port and add a member of
11:21:53 sean-k-mooney 2.) post filter that woudl use a schduler hint (packaged in octavia)
11:22:04 sean-k-mooney 3.) wait for full solution next cycle
11:22:25 gibi I think I can give some help in 1.)
11:22:29 sean-k-mooney and start on the spec now to have agreement
11:22:31 rm_work well, we'd also like to use the same filter for nova live-migrate, and ironic
11:22:51 rm_work so maybe 1 is ok, and we can continue to use the filter for now
11:23:02 rm_work and swap over when this is ready upstream
11:23:47 gibi rm_work, sean-k-mooney: I will write a summary for the ML about this discussion to see what others think
11:24:04 gibi I'm not jumping into writing a full spec yet
11:24:14 sean-k-mooney so the only thing i really care about here is ensuring that whatever we decide it does not tie our hands next cycle. which is why i want it to be experimental
11:24:31 gibi rm_work: I would appreciate if you could review the currently proposed tempest tests https://review.opendev.org/#/c/665155/16/tempest/scenario/test_routed_provider_network.py
11:26:14 rm_work ok
11:26:20 gibi rm_work: thanks
11:26:46 gibi sean-k-mooney: sure, this is why I don't like the in three hint idea, as that would become an API
11:27:12 gibi sean-k-mooney: pre-filter can be a lot more fluid impl, and later we can make neutron to provide the agg ids in the resource_request
11:27:28 sean-k-mooney gibi: ya i could live with the perfromance hit if its disabled by default meaning we have to do the api query for the port info in the prefilter
11:28:02 sean-k-mooney gibi: yep and even the allcoations in some cases
11:28:37 sean-k-mooney wehn you create a port that is consuming an ip it should realy have allready created a placmente allocation for that
11:29:11 gibi sean-k-mooney: agreed, this pre-filter is costly so it should be disable by default
11:29:16 sean-k-mooney so we would want to pass the aggreate 1 the allcotion unless you defer the ip asginment
11:29:42 sean-k-mooney *agggreate and the allocation
11:29:43 gibi sean-k-mooney: agree, that allocating IPs needs to be handled as resources in placement but that is really fare in the future based on your current amount of people working on this
11:30:11 gibi s/your/our/
11:30:46 sean-k-mooney if we put a concerted effort in i think it could be done next cycle but this would require a resonable amount of work in neutron
11:31:22 rm_work i thought neutron already DID all the work in placement
11:31:28 rm_work there's more?
11:31:35 sean-k-mooney it does not do it the way we want it to
11:31:47 sean-k-mooney it is reporting segments as placmenet aggreates
11:32:08 sean-k-mooney but its not reporting inventoreis of ips as sharing aggreates
11:32:36 gibi sean-k-mooney: at the moment this is not prioritized on my end so I won't commit to this as a spec for the next cycle. I will try to ease the immediate pain with a pre-filter
11:32:47 sean-k-mooney nor is its tracking segmenation id per segmentation_type (vlan,vxlan,...) and mapping those to addtional aggreates
11:33:01 gibi rm_work: there is always more work :)
11:33:30 sean-k-mooney yep
11:34:07 sean-k-mooney its frustrating becasue i have wanted to solve this problem for longer then plamcnet has existed
11:34:37 sean-k-mooney gibi: did you come to intel shannon with jay after the briton mid cycle
11:35:02 gibi sean-k-mooney: nope, I wasn't there
11:35:34 rm_work yeah that was kinda why i like the simplicity of the filter... it just... works? there's not really many complications
11:35:45 rm_work but yeah, it's not the absolute most optimal
11:35:55 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Don't print user_data for 'nova show' https://review.opendev.org/708850
11:36:06 rm_work the question is, would we be able to get anything else in the forseeable future? lol
11:36:18 rm_work because this filter was technically mergable like ... in newton
11:36:24 sean-k-mooney ah ok well i pitched the idea of a json toploogy api for neutron that basicaly exposed a tree based view of resouces and capablites of network backend. this was pre placment and was a staic view but ya i have been wanting to fix this but not had time too for years.
11:37:27 sean-k-mooney rm_work: actully the prefilter will not just work it will increase the likelyhood of novalid host on a modertly full cloud
11:38:13 sean-k-mooney at least if you dont use ip_alloction defer
11:38:30 sean-k-mooney if you use the default ip_allocation=immediate
11:38:50 rm_work yeah we use defer
11:39:07 rm_work this is not for nova to use for initial scheduling really
11:39:11 sean-k-mooney then when the neutron port is created it will get an ip and a segment and then we will only consider that segment
11:39:54 sean-k-mooney ya with defer it will work as we will schdule to any host then we will only assgin an ip when we bind it the host
11:40:16 sean-k-mooney from that point on it will not migrate outside of that segment
11:40:30 rm_work right, not intending to mess with the initial scheduling stuff
11:40:45 rm_work it's for re-scheduling tasks
11:40:53 rm_work like what octavia or live-migrate does
11:41:08 sean-k-mooney the same would be true fo nova careated ports actully since we do that on the compute node
11:41:11 rm_work when we're already locked to a segment due to an existing port
11:41:22 sean-k-mooney ya
11:41:54 sean-k-mooney the only case that breaks is precreated port where you have not set ip_allocaton
11:42:01 sean-k-mooney the only case that breaks is precreated port where you have not set ip_allocaton=defer
11:43:17 rm_work err no, that's exactly one of our cases
11:43:32 rm_work octavia creates a port, it gets an IP... then we need to boot nova VMs in that segment
11:45:28 sean-k-mooney can octavia use ip_allocatio=defer in that case
11:45:38 rm_work no
11:46:00 sean-k-mooney ok then it will work until the cloud start to get full
11:46:01 rm_work the whole point of us creating that port is to pre-allocate an IP up-front
11:46:03 sean-k-mooney or that aggreate
11:46:09 rm_work yes, that's true
11:46:50 sean-k-mooney righ if you preallcoate the ip up front then that determins the segemnt so and with the prefilter we will not consider any other host
11:47:12 sean-k-mooney with all the pros and cons that brings

Earlier   Later