Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-17
15:23:58 sean-k-mooney spatel: its a console-script that is generated by setuptools/pbr https://github.com/openstack/nova/blob/master/setup.cfg#L66
15:24:04 spatel its no there.. i have installed all nova utility tools but didn't find that tool
15:24:31 sean-k-mooney spatel: on what distro?
15:24:37 spatel CentOS 7.5
15:24:51 spatel Installation method is Openstack-ansible
15:25:18 sean-k-mooney openstack ansible installs form source right?
15:25:28 sean-k-mooney or are you using nova form the distro rpms
15:25:29 spatel yes they use source
15:25:48 sean-k-mooney then when osa did pip install nova it should have been genreated
15:25:50 spatel openstack-ansible use source from git repo, they don't use RPM
15:26:09 sean-k-mooney spatel: without it they would not have been able to create the nova db and could not run the db migrations
15:26:17 spatel Let me ask openstack-ansible channel and see if they offer any suggestion
15:27:05 odyssey4me spatel nova-manage is in the nova venv, as with all the openstack packages we build
15:27:21 spatel there you are!!
15:27:26 odyssey4me so it'll be /openstack/venvs/nova-<tag>/bin/nova-manage ...
15:28:24 spatel odyssey4me: so that command won't be available in utility container right?
15:28:39 odyssey4me spatel nope, it'll only be on hosts where the nova service is installed
15:29:06 spatel odyssey4me: thank for clarification
15:29:15 odyssey4me it requires database access, so best is to use it from the control plane hosts - compute may not have the db connection string in nova.conf
15:29:20 mriedem gibi: in reading the spec, it looks like we need to handle cleaning up bw allocations when a port is detached - do you have code for that up yet?
15:29:43 mriedem gibi: because it seems we'd want that code in place first, which would be a noop until the server create code lands, right?
15:29:45 gibi mriedem: that is the patch I've just sneak into the list
15:29:54 odyssey4me spatel no problem - happy to assist :)
15:30:07 gibi mriedem: hm regarding the ordering you are right
15:30:54 mriedem also, why aren't the "reject ports with qos" patches first in the series?
15:30:58 gibi mriedem: so this https://review.openstack.org/#/c/622421/6 needs to be earlier in the stack
15:31:14 mriedem i'm just trying to think of the order in which this rolls out,
15:31:34 mriedem where the groundwork is done first so that when the scheduler bits are turned "on" the rest of it is in place
15:31:49 mriedem sort of like how we handle adding new api features which require changes to compute
15:31:53 mriedem we start from the bottom up
15:33:54 gibi mriedem: the API bit here is the neturon API extension that adds the resource_request field to the port
15:33:59 mriedem as of https://review.openstack.org/#/c/567268/ will we be allocating bw resources during server create?
15:34:09 gibi mriedem: if that field is not there then nothing happens in nova
15:34:34 mriedem this right? https://review.openstack.org/#/c/567268/36/nova/network/neutronv2/api.py
15:35:05 openstackgerrit Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646
15:36:36 mriedem yeah and that's used here https://review.openstack.org/#/c/567268/36/nova/scheduler/utils.py
15:36:38 gibi mriedem: yes. and that data ends up in the RequestSpec here https://review.openstack.org/#/c/567268/36/nova/compute/api.py@884 which leads to bandwidth allocations
15:36:44 mriedem to build the resource request to allocation candidates
15:36:59 gibi mriedem: yes
15:37:41 mriedem so if we were to merge the first patch in the series, we'd be allocating these things on server create, but not handling them for moves, or port detach
15:38:20 yan0s if I want to have the same set of flavors in two Regions
15:38:30 mriedem gibi: i kind of see two options, neither of which is probably great for you:
15:38:36 yan0s do I need to duplicate them in both Regions?
15:38:52 yan0s or is there another solution for them to exist in just one place?
15:38:53 mriedem 1. re-order the series so the bottom-up changes (nova-compute) happens first and we build to the top where the api transfers the port request to the scheduler
15:39:31 mriedem 2. we don't merge the bottom changes in the series until we're happy with the whole thing, at which point we approve it all and hope it merges in the same day/week
15:40:20 gibi mriedem: there is one catch. Unitl https://review.openstack.org/#/c/590363/27/neutron/services/qos/qos_plugin.py@128 merges there is no resource_request field in the neutron ports. And after that patch merges there is still a manual step to enable the neutron port extension to turn on the whole feature
15:40:22 mriedem yan0s: does nova-api span regions?
15:41:07 mriedem gibi: is there a nova change which depends on that neutron change?
15:41:20 yan0s I'm still just in theory about it
15:41:21 mriedem i would think https://review.openstack.org/#/c/567268/ should depend on https://review.openstack.org/#/c/590363/
15:41:39 gibi mriedem: no direct dependency as if there is no code that fails if the resource_request is missing
15:41:58 mriedem sure, but it's a functional dependency
15:41:59 yan0s What do you mean by that?
15:42:17 yan0s HA deployment of nova-api?
15:42:22 mriedem yan0s: your question depends on if you have separate nova deployments (separate api endpoints) per region
15:42:25 gibi mriedem: the neutron api extension that introduces resource_request is lik a feature flag for the whole bandwidth series
15:42:25 yan0s over the 2 regions?
15:42:47 gibi mriedem: I can make a depends-on to the neutron patch, that is easy
15:42:51 mriedem if you have separate compute api endpoints per region, using isolated dbs, then yes you'd need to duplicate across regions (i think that's what project kingbird is for)
15:43:08 gibi mriedem: what I'd like to achive is to consider the neutron api extension as a feature flag
15:43:11 mriedem gibi: so what do you think about the 1 or 2 options above?
15:43:53 mriedem personally i'd like to merge some stuff to see it continue moving, but i probably won't do that while the control-plane changes are coming before the backend nova-compute changes to handle cleaning up
15:44:11 mriedem which just means you'd be dealing with merge conflicts longer...
15:44:17 gibi mriedem: I'd like to propose 3.: the neutron api extension is marked experimental till a good set of usecases are covered by the code merges.
15:45:09 yan0s I think, since my regions are going to be in the same DC, the best option will be to have one nova-api
15:45:15 gibi mriedem: if that doesn't work for you, then I can move the reject cases and the detach case to the front of the series
15:45:58 gibi mriedem: detach might not work when moved to the front so I might need to reject detach until some create logic merges
15:46:03 mriedem gibi: it might work. i'll just finish reading the spec again, start going through the nova changes and +1 if i'm cool with a change and we'll see where it goes from there once i have the whole thing in my head
15:46:47 yan0s could you point to me some documentation on same nova-api region deployment?
15:47:00 gibi mriedem: I will run an experiment locally to see how hard is the re-arrange
15:47:23 gibi mriedem: will not push anyting before we sync
15:50:29 mriedem yan0s: i'm aware of https://docs.openstack.org/operations-guide/ops-capacity-planning-scaling.html#segregating-your-cloud but it's old
15:50:42 mriedem https://wiki.openstack.org/wiki/Kingbird
15:51:30 mriedem yan0s: note the cells mention in that ops guide is about cells v1, which is deprecated and replaced with cells v2 in nova which is not experimental nor optional - all nova deployments since ocata are by default a cells v2 cell of 1
15:53:58 yan0s mriedem: thanks!
15:55:03 yan0s so shared nova-api means using cells instead of regions
15:55:05 yan0s correct
15:55:06 yan0s ?
15:55:09 mriedem yes
16:01:20 mriedem https://storyboard.openstack.org/#!/story/2004625 if anyone wants to cleanup the 'cells' reference in the old ops scaling guide
16:01:49 gibi mriedem: if we want to go with good order that means either I cannot allow booting an instance with bandwidth until nova supports migrate, evacuate, unshelve for that instance, or reject migrate, evacuate, unshelve, for that instance
16:02:03 yan0s So choosing in which region to launch a VM is a matter of using this regions API
16:02:11 gibi mriedem: neither looks really good to me :/
16:02:27 yan0s how do I specify in which cell to launch a VM?
16:03:20 mriedem yan0s: cells are not exposed out of the rest api, so if you want a vm to go to a specific cell, you pick a host (or az) that's in that cell
16:04:14 mriedem gibi: realistically we shouldn't be supporting creating servers with qos-enabled ports today anyway right? since we don't honor the actual qos request.
16:04:29 mriedem and that's why it's all disabled in neutron
16:05:19 yan0s ok got it, thanks again!
16:05:24 mriedem i know during the spec review we talked about this sort of like with multiattach volumes, which you could always use before nova actually supported them for attaching to at most 1 server
16:05:27 gibi mriedem: yeah, in nova we cannot really support qos requests unilt we merge a _lot_ of code
16:06:15 mriedem gibi: yeah, which is why i said i guess we could just +1 our way to a point where we think it's ready to merge and then try to merge it all as a big chunk
16:06:31 mriedem rather than try to merge effectively noop pieces from the bottom up
16:06:41 mriedem the former is more like a feature branch
16:06:44 gibi mriedem: that will be at least 20 patches (I have 15 already without any server move)
16:07:28 gibi mriedem: we can consider evey nova patch no-op while the neutron api extension is disabled :)
16:07:43 mriedem gibi: given it's 5pm for you, how about i just continue reviewing this today and you not worry about it for a bit :)
16:07:51 gibi mriedem: sure
16:07:52 gibi :)
16:08:12 mriedem we likely can't merge anything until the first week of january anyway...

Earlier   Later