| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-02-26 | |||
| 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 | |
| 11:47:37 | rm_work | yeah that is why this filter is fine for us, we always know the segment we want | |
| 11:47:38 | sean-k-mooney | fundemetally there is no way around that | |
| 11:47:59 | sean-k-mooney | but you dont know if there is enough compute resouces in that segment to run the vm | |
| 11:48:11 | sean-k-mooney | so you will have to handel the no valid host case | |
| 11:48:17 | rm_work | we have no choice | |
| 11:48:21 | sean-k-mooney | and either choose a differnt segment or give up | |
| 11:48:27 | rm_work | usually we are doing this on an object that has existing for a long time | |
| 11:48:47 | rm_work | we have a VIP port, and two VMs that serve HAProxy behind it | |
| 11:48:55 | rm_work | they are in a keepalived pair | |
| 11:49:07 | rm_work | when one fails, we need to boot a new one in the same segment | |
| 11:49:10 | rm_work | there is no choice | |
| 11:49:22 | sean-k-mooney | for routed networks yes | |
| 11:49:31 | sean-k-mooney | although | |
| 11:49:39 | sean-k-mooney | only the vip needs to stay the same | |
| 11:49:46 | sean-k-mooney | sorry | |
| 11:49:59 | sean-k-mooney | octavia the vip is assigned to the vm you are booting | |
| 11:50:48 | sean-k-mooney | rm_work: the vip is the public loadblancer ip right? | |
| 11:51:06 | sean-k-mooney | the one that applciation will use to connect to the services that are behind it | |
| 11:51:38 | rm_work | yes | |
| 11:51:59 | rm_work | the VIP is static and is known to the user | |
| 11:52:07 | sean-k-mooney | yep | |
| 11:52:14 | rm_work | and will always persist (it is unbound, and uses allowed-address-pairs) | |
| 11:52:22 | sean-k-mooney | ya | |
| 11:53:29 | sean-k-mooney | so even in routed network you could use a /32 route to make that available rigth even if the ha proxy vm ip is not in the same subnet range | |
| 11:53:30 | rm_work | so, i'm aware we will have problems if the aggregate fills up, but we have no choice :( | |
| 11:53:50 | rm_work | that'd be possible if we had a different network architecture, maybe | |
| 11:53:56 | rm_work | as it is, we cannot | |
| 11:54:11 | sean-k-mooney | well bgp would be able to supprot that | |
| 11:54:16 | sean-k-mooney | but ya ok | |
| 11:54:35 | mlycka | Hello. Is there a specific person responsible for adding new version templates and folders to nova-spec? | |