| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-01 | |||
| 09:02:43 | ftersin | more checks, probably. But anyway you'll have to develop a pretty common transition system (at least to commonize lvm and ceph things), so it will be not very big extra work to additionaly support another driver there | |
| 09:04:27 | johnthetubaguy | ftersin: in my head the hard bit is "import" volume into Cinder, which feels like its going to be specific to each platform, the common bit is just the loop to call that function for each disk on the system in init_host, but I could be missing something | |
| 09:04:34 | ftersin | under 'that call' you mean the switching to Cinder backend or adding new volume based backends? | |
| 09:05:34 | johnthetubaguy | I mean working out how to "move" the volume from being managed by Nova to being managed by Cinder, I think though using this call somehow: https://developer.openstack.org/api-ref/block-storage/v2/index.html?expanded=manage-existing-volume-detail#manage-existing-volume | |
| 09:08:29 | ftersin | but you'll not need to acquire all volumes, only used for local disks. At the first glance the only not common thing is to fill connection strings | |
| 09:09:25 | johnthetubaguy | ftersin: filling in the "ref" parameter worries me I guess, and ensuring each backend supports that cinder API in the same way | |
| 09:10:29 | johnthetubaguy | ftersin: I think the action here is to discuss the cost of this all in the alternatives section in the spec. Just a few sentences, thats all, to show it has been considered | |
| 09:11:51 | ftersin | sure, each volume driver in Nova can compose a new connection string to attach a volume. But if they can to compose the string for attached volumes? | |
| 09:14:28 | johnthetubaguy | ftersin: yeah, maybe thats not as bad as I think it is. I didn't discover that cinder API till just now, which makes me worry a little bit less | |
| 09:14:52 | ftersin | johnthetubaguy: ok, i may add a consideration of Cinder backend alternative. Do you have a link to appropriate discussion or the result docs or smth else? | |
| 09:15:42 | johnthetubaguy | ftersin: good question, I think jgriffith was taking the action on that one, I am hoping to see a nova-spec from him around that | |
| 09:19:08 | sfinucan | mriedem_away: https://review.openstack.org/#/c/412390/ | |
| 09:20:18 | sfinucan | mriedem_away: I /did/ deprecate firewall_driver :) (along with pretty much everything else nova-network'y - https://review.openstack.org/#/q/topic:bp/centralize-config-options-pike+owner:%22Stephen+Finucane+%253Csfinucan%2540redhat.com%253E%22+status:open) | |
| 09:20:36 | sfinucan | tonyb: What are we celebrating? :) | |
| 09:24:42 | ftersin | johnthetubaguy: well, i'll try to monitor gerrit for that, or ask him. Right now i'm going to add that alternative to the spec and reupload it. Is it ok for you? | |
| 09:24:57 | johnthetubaguy | ftersin: that sounds perfect, thank you | |
| 09:28:03 | ftersin | johnthetubaguy: thank you too | |
| 09:31:44 | openstackgerrit | sahid proposed openstack/nova master: numa: add numa constraints for emulator threads policy https://review.openstack.org/385023 | |
| 09:31:47 | openstackgerrit | sahid proposed openstack/nova master: libvirt: return a CPU overhead if isolate emulator threads requested https://review.openstack.org/385364 | |
| 09:31:48 | openstackgerrit | sahid proposed openstack/nova master: numa: fit instance topology with cpus reserved onto cores https://review.openstack.org/400875 | |
| 09:31:50 | openstackgerrit | sahid proposed openstack/nova master: virt: update overhead to take into account vCPUs https://review.openstack.org/385024 | |
| 09:31:54 | openstackgerrit | sahid proposed openstack/nova master: libvirt: make emulator threads to run on the reserved pCPU https://review.openstack.org/400878 | |
| 09:31:55 | openstackgerrit | sahid proposed openstack/nova master: numa: take into account cpus reserved https://review.openstack.org/400876 | |
| 09:31:56 | openstackgerrit | sahid proposed openstack/nova master: numa: update numa usage incording the cpu reserved https://review.openstack.org/400877 | |
| 09:37:56 | gmann | alex_xu: johnthetubaguy I would not be available for today meeting due to other works. | |
| 09:38:09 | alex_xu | gmann: got it | |
| 09:47:29 | openstackgerrit | Alfredo Moralejo proposed openstack/nova master: Remove domains *-log-* from compile_catalog https://review.openstack.org/439500 | |
| 09:47:50 | tonyb | sfinucan: the merge of your pbr patch ... and then it all went horribly wrong | |
| 09:48:07 | sfinucan | tonyb: oh, do tell | |
| 09:48:21 | openstackgerrit | Alfredo Moralejo proposed openstack/nova master: Remove domains *-log-* from compile_catalog https://review.openstack.org/439500 | |
| 09:49:28 | bauzas | tonyb: not sure I fully understood the pbr major version potential problem you raised | |
| 09:52:01 | tonyb | sfinucan: It seems a few projects (in and out of OpenStack) have defensive caps on pbr < 2.0.0 so we're stuck until they get fixed | |
| 09:52:50 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Backlog spec describing Nova's quota needs https://review.openstack.org/429678 | |
| 09:52:52 | tonyb | bauzas: it *shoudln't* affect nova but projects under Telemtry will be a little broken until we fix the pbr thing (or they land a local patch) | |
| 09:53:34 | johnthetubaguy | tonyb: I meant to ping you about that spec on capabilties, although sounds like you are busy with other fires | |
| 09:53:48 | prometheanfire | was there any docs made for the install guide for setting up the placement api? | |
| 09:54:30 | tonyb | johnthetubaguy: I hope they'll be damped by tomorrow, so I shoudl be able to focus on it tomorrow | |
| 09:54:34 | prometheanfire | because https://docs.openstack.org/developer/nova/placement.html seems kinda lacking, for instance, doesn't say what port it's running on | |
| 09:55:16 | johnthetubaguy | prometheanfire: yeah, I was just going to point to https://docs.openstack.org/developer/nova/placement.html#deployment | |
| 09:55:19 | johnthetubaguy | tonyb: coolness | |
| 09:55:27 | bauzas | tonyb: okay, thanks for the feeback | |
| 09:55:38 | tonyb | prometheanfire: check devstack or wit for the docs install guide | |
| 09:55:46 | johnthetubaguy | prometheanfire: basically its done the same way keystone is deployed, so the port etc is defined by mod_wsgi, etc | |
| 09:56:06 | johnthetubaguy | prometheanfire: and +1 tonyb, devstack shows how thats done, to some extent | |
| 09:56:30 | johnthetubaguy | prometheanfire: jaypipes would know more of the doc plan when he comes online later today | |
| 09:57:03 | prometheanfire | tonyb: I'm actually checking osa first :P | |
| 09:57:32 | tonyb | prometheanfire: fair enough | |
| 09:57:41 | prometheanfire | though osa has it as optional | |
| 09:57:45 | johnthetubaguy | prometheanfire: yeah, I walked through that with OSA, so it should be there now | |
| 09:57:45 | prometheanfire | and it's not :P | |
| 09:58:00 | johnthetubaguy | prometheanfire: I thought they had updated that for this cycle, I guess not | |
| 09:58:10 | johnthetubaguy | by this I mean ocata | |
| 09:58:32 | prometheanfire | right | |
| 09:58:39 | johnthetubaguy | andymccr: did you make placement api required yet in OSA ^ | |
| 09:58:58 | prometheanfire | maybe it's meant to only be configured on certian nodes | |
| 09:59:13 | prometheanfire | johnthetubaguy: so... what's the default port for it? | |
| 09:59:21 | prometheanfire | like nova has a default port | |
| 09:59:21 | johnthetubaguy | prometheanfire: looking here https://github.com/openstack-dev/devstack/blob/55dab95237302fa371b88a2edce06de201d83f52/files/apache-placement-api.template bauzas might be able to help | |
| 09:59:37 | johnthetubaguy | prometheanfire: placement doesn't have a default port, just like keystone, AFAIK | |
| 09:59:38 | prometheanfire | 8780, thanks :D | |
| 09:59:55 | bauzas | prometheanfire: johnthetubaguy: sorry, on meeting atm | |
| 09:59:57 | johnthetubaguy | oh, I guess that kinda is the default | |
| 10:00:02 | prometheanfire | keystone isn't 5000 / 35357 ? | |
| 10:00:23 | johnthetubaguy | well, in theory, none of that matters, you just get the URL from the service catalog | |
| 10:00:40 | prometheanfire | I know it can be discovered, but it's nice to be consistant :P | |
| 10:01:06 | johnthetubaguy | prometheanfire: actually looks like us and keystone might be on 443, technically, https://github.com/openstack-dev/devstack/blob/55dab95237302fa371b88a2edce06de201d83f52/files/apache-keystone.template | |
| 10:01:11 | johnthetubaguy | prometheanfire: but I am not sure | |
| 10:01:17 | andymccr | johnthetubaguy: it's on by default - originally i set it up with a flag but i will probably remove that flag | |
| 10:01:38 | prometheanfire | andymccr: cool, was confused about that :D | |
| 10:01:50 | johnthetubaguy | andymccr: ah, cool, that makes sense, just a transition thing | |
| 10:02:01 | andymccr | prometheanfire: yeah i wanted to set it up prior to it being required and never got it going - and then didn't remove the flag :P | |
| 10:02:03 | andymccr | but yeah it should go now | |
| 10:02:21 | andymccr | either way if you dont force it off - it gets set up | |
| 10:02:47 | prometheanfire | johnthetubaguy: I think it's also on 443 in devstack, but primarily on PUBLICPORT/ADMINPORT | |
| 10:03:00 | johnthetubaguy | yeah, that makes sense | |
| 10:05:34 | andymccr | prometheanfire: there is a discussion about the default ports on the mailing list - essentially there is no default the idea is you use port 80/443 - but we needed one for our backend since we dont have it setup to do that at this point. | |
| 10:05:51 | andymccr | so we went with what the tripleo/puppet people had to keep it at least default in that regard | |
| 10:06:16 | prometheanfire | ya +nova_placement_service_port: 8780 | |
| 10:18:12 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Remove unused variable https://review.openstack.org/439516 | |
| 10:23:26 | openstackgerrit | Lee Yarwood proposed openstack/nova master: objects: Add attachment_id to BlockDeviceMapping https://review.openstack.org/437665 | |
| 10:23:27 | openstackgerrit | Lee Yarwood proposed openstack/nova master: db: Add attachment_id to block_device_mapping https://review.openstack.org/437597 | |
| 10:23:27 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Make BlockDeviceMapping object support uuid https://review.openstack.org/242603 | |
| 10:23:29 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add uuid column to BlockDeviceMapping https://review.openstack.org/242602 | |
| 10:23:29 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP compute: Move detach logic into driver BDM https://review.openstack.org/439520 | |
| 10:27:30 | johnthetubaguy | bauzas: do you know the plans around updating install docs for placement? asettle might start chasing you about that :) | |
| 10:27:57 | johnthetubaguy | mriedem_away might be able to co-ordinate the doc update efforts for asettle, as I guess the cells stuff probably needs adding too | |
| 10:28:58 | prometheanfire | johnthetubaguy: yep, that was missing as well | |
| 10:30:56 | asettle | bauzas and mriedem_away - context, the docs here: https://docs.openstack.org/ocata/install-guide-obs/nova.html are out of date and missing some key elements | |
| 10:31:11 | asettle | We'll need to ensure that in future the docs are being updated with each release | |
| 10:33:16 | johnthetubaguy | asettle: I suspect for many thinks will have to wait until the packages are updated after the release, but getting ahead of that can't halm | |
| 10:34:14 | asettle | Yeah, so, in theory you shouldn't have to wait until the packages are updated. Especially if the nova changes in question have nothing ot do with distro packages | |
| 10:36:30 | bauzas | asettle: johnthetubaguy: sorry, was in meeting | |
| 10:36:34 | bauzas | how can I help ? | |
| 10:36:51 | johnthetubaguy | install docs are out of date | |
| 10:36:57 | johnthetubaguy | for placement-api | |
| 10:37:04 | johnthetubaguy | (and cells stuff actually) | |
| 10:37:05 | asettle | bauzas: documentation for the nova portion of the install guide requires updates. ARe there plans to get this updated, or is there someone we can work with to get this updated? | |
| 10:41:49 | bauzas | looks like a huge knowledge transfer to do | |
| 10:42:10 | bauzas | asettle: we have a couple of dev docs that are intended to be user-facing tho | |
| 10:44:24 | asettle | bauzas: if you already have the dev docs, are there any plans to move them and improve on the install guide? | |