| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-07 | |||
| 10:09:38 | kashyap | sfinucan: Look at get_capabilities() method in nova/virt/libvirt/host.py: | |
| 10:10:42 | kashyap | sfinucan: Curious, why do you ask? | |
| 10:11:45 | sfinucan | kashyap: I got asked to review https://review.openstack.org/#/c/454042/, which seems to be looking to do just that | |
| 10:11:53 | sfinucan | albeit in a different project | |
| 10:12:39 | sfinucan | personally, I think everything they're looking for can be accomplished by resource-providers and traits (and I'm saying as much), but I was curious to know if there was anything already there | |
| 10:13:35 | kashyap | I see | |
| 10:14:12 | kashyap | sfinucan: Incidentally, I was thinking of working on allowing an ability to turn on / off CPU features / flags for the named CPU models | |
| 10:15:29 | kashyap | That'll allow us to supply specific features (like VMX, or SVM) when using a custom CPU mode (via Nova's 'cpu_mode'). | |
| 10:16:02 | sfinucan | kashyap: Hmm, sounds very...uncloudy :) | |
| 10:16:18 | kashyap | sfinucan: Allow me to tell why it's useful: | |
| 10:17:20 | kashyap | sfinucan: If you have the above capability, _along_ with the ability to turn on / off said CPU features per flavor, a Cloud Admin, can then decide to whom they can give access to nested Virt | |
| 10:17:46 | kashyap | A perfectly Cloudy Thing, if you ask me :-) This discussion came up with danpb in the past. | |
| 10:18:15 | sfinucan | kashyap: Sure you'd be better to expose an "allow nested virt?" option then, rather than exposing every CPU flag? | |
| 10:18:17 | kashyap | I have a TODO item to write up a bug with details for this | |
| 10:18:25 | sfinucan | *Surely | |
| 10:19:27 | kashyap | sfinucan: To expose that (non-existent) option, you need to supply *explicitly* either Intel's VMX or AMD's SVM CPU flag | |
| 10:19:56 | kashyap | The idea is to not expose every CPU flag :-) | |
| 10:20:08 | sfinucan | kashyap: Yeah, sorry I mean abstract all that stuff away and present just a single flag to the user | |
| 10:20:18 | sfinucan | do all the CPU flag magic under the hood | |
| 10:20:27 | sfinucan | Aha - my mistake :) | |
| 10:22:31 | kashyap | Agreed, we should be able to abstract that all. | |
| 10:22:47 | kashyap | Also, related topic is that, in the past we've had multiple bugs with guest / host CPU compatibility | |
| 10:23:14 | kashyap | Now, with QEMU 2.9 (about to be released) & libvirt 3.2, there has been major improvements -- | |
| 10:24:07 | kashyap | Where now, when someone asks to do a 'host-passthrough', libvirt simply asks QEMU to provide a supported CPU model, in the past it used to use the CPUID instruction -- which led to enabling all kinds of CPU flags that QEMU didn't support | |
| 10:24:11 | kashyap | Anyway... | |
| 10:24:49 | sfinucan | kashyap: So instead of 'cpu_mode' being a static thing applied to all VMs, you'd now have a magic 'hw:nested_virt' flavor extra spec that admins could use on certain flavours? | |
| 10:25:18 | kashyap | sfinucan: Yep, something like that | |
| 10:25:29 | sfinucan | kashyap: Do QEMU publish pre-release release notes? | |
| 10:26:08 | kashyap | sfinucan: There's a Wiki page where we try to collect feature items upcoming in a release, let me see | |
| 10:26:17 | sfinucan | kashyap: nifty. I've reviewed specs which proposed exposing the entire cpu_mode, cpu_model fields via flavors. That's less nice | |
| 10:26:21 | sfinucan | (y) | |
| 10:26:42 | kashyap | sfinucan: Where are those specs? Got a handy URL, btw? | |
| 10:26:51 | sfinucan | sec | |
| 10:27:22 | sfinucan | kashyap: https://review.openstack.org/#/c/387295/2/specs/ocata/approved/modify-cpu-mode-precedence.rst | |
| 10:27:40 | kashyap | sfinucan: Thanks | |
| 10:28:02 | sfinucan | kashyap: Also https://review.openstack.org/#/c/168982/, https://review.openstack.org/#/c/170397/ and https://review.openstack.org/#/c/170396/ | |
| 10:28:03 | kashyap | sfinucan: For the release notes, see the "FIXME" (it should be fixed, I'll do that) - http://wiki.qemu-project.org/ChangeLog/2.9#x86 | |
| 10:28:03 | sfinucan | :) | |
| 10:28:14 | kashyap | It's the 'query-cpu-model-expansion' | |
| 10:28:35 | kashyap | It took about 6 years (!) to fix all of it, there's a post somewhere from Eduardo, who maintains that stuff | |
| 10:29:08 | kashyap | Thanks for the links | |
| 10:33:03 | openstackgerrit | jichenjc proposed openstack/nova master: Remove the extension check for os-quota-class-sets https://review.openstack.org/451193 | |
| 10:46:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data (3) https://review.openstack.org/452820 | |
| 10:46:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data https://review.openstack.org/452818 | |
| 10:46:44 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Factor out duplicated notification sample data (2) https://review.openstack.org/452819 | |
| 10:47:24 | sean-k-mooney | sfinucan: not sure if you got your answer but the cpu info is available via the hypervior api | |
| 10:48:35 | sean-k-mooney | sfinucan: you can just the json filter to schedule to a node with a specific feature you may be able to also use the compute capablity filter | |
| 11:07:04 | openstackgerrit | jichenjc proposed openstack/nova master: [placement] Add doc for resource provider usages https://review.openstack.org/450105 | |
| 11:14:11 | bhagyashris | johnthetubaguy: Hi, I have one doubt regarding patch: https://review.openstack.org/#/c/409644/4/nova/compute/api.py . Do I need to check condition if rotation==0 in nova/cells/messaging.py? Should I set the instance.task_state as IMAGE_BACKUP in nova/cells/messaging? Because this is already set in nova/cells/messaging.py | |
| 11:16:58 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: provide an RFB security proxy implementation https://review.openstack.org/345399 | |
| 11:18:20 | johnthetubaguy | bhagyashris: you see the compute_rpcapi call in compute/api.py, that runs the cells messaging code on the lower cell (https://github.com/openstack/nova/blob/master/nova/cells/messaging.py#L914) so if you skip the DB change in compute/api.py, you would also have to skip that change in the cells messaging logic. But I think you shouldn't skip that DB call in either, so your updated patch may mean you don't need to | |
| 11:18:21 | johnthetubaguy | change the cells messaging layer | |
| 11:22:17 | bhagyashris | johnthetubaguy: Thank you, For clearing my doubt. :) | |
| 11:22:38 | johnthetubaguy | bhagyashris: no problem | |
| 11:28:08 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for GET RP inventories https://review.openstack.org/449765 | |
| 11:28:08 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for DELETE RP inventories https://review.openstack.org/452708 | |
| 11:28:09 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for PUT RP inventories https://review.openstack.org/452707 | |
| 11:31:37 | openstackgerrit | jichenjc proposed openstack/nova master: [placement] Add doc for resource provider classes https://review.openstack.org/451661 | |
| 11:35:23 | openstackgerrit | Jens Rosenboom proposed openstack/nova master: Fix network metadata information - part 3/3 https://review.openstack.org/450297 | |
| 11:35:24 | openstackgerrit | Jens Rosenboom proposed openstack/nova master: Fix network metadata information - part 2/3 https://review.openstack.org/450212 | |
| 11:35:24 | openstackgerrit | Jens Rosenboom proposed openstack/nova master: Fix network metadata information - part 1/3 https://review.openstack.org/450211 | |
| 11:58:21 | dims | sdague : looks like we can't promote new novaclient to u-c - http://logs.openstack.org/64/454164/1/check/gate-grenade-dsvm-neutron-ubuntu-xenial/77e30c8/logs/grenade.sh.txt.gz#_2017-04-07_04_04_14_593 | |
| 11:58:28 | dims | sdague : good morning :) | |
| 11:58:45 | sdague | oh, I had never fixed that eh? | |
| 11:59:07 | sdague | I wonder if there is an outstanding patch for that | |
| 11:59:56 | sdague | I remember talking to dtroyer about it at the PTG | |
| 12:04:43 | sdague | dims: https://review.openstack.org/454694 | |
| 12:04:56 | sdague | yeh, I guess we'd just never gotten around to fixing that | |
| 12:10:02 | dims | sdague : +1 | |
| 12:16:54 | zioproto | is anyone familiar with the nova.conf setting live_migration_tunnelled ? | |
| 12:37:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Remove **kwargs passing in payload __init__ https://review.openstack.org/418489 | |
| 12:49:02 | frickler | the ceph tests seems to be failing with a single error during volume backup creation: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%20%5C%22tempest.exceptions.VolumeResourceBuildErrorException%3A%20backup%5C%22 | |
| 12:49:21 | frickler | I haven't found anything obvious, maybe skip that test until someone can fix it? | |
| 12:50:57 | frickler | hmm, seems it also affects sheepdog, so I guess I better ask cinder folk | |
| 12:51:30 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/453896 | |
| 13:15:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: provide an RFB security proxy implementation https://review.openstack.org/345399 | |
| 13:21:35 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: introduce basic framework for security proxying https://review.openstack.org/345396 | |
| 13:21:36 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: introduce framework for RFB authentication https://review.openstack.org/345397 | |
| 13:21:36 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: introduce the VeNCrypt RFB authentication scheme https://review.openstack.org/345398 | |
| 13:21:37 | openstackgerrit | Stephen Finucane proposed openstack/nova master: console: provide an RFB security proxy implementation https://review.openstack.org/345399 | |
| 13:35:39 | dims | sdague : horizon is busted too fyi, pinging robcresswell on horizon channel now (http://logs.openstack.org/64/454164/2/check/gate-cross-horizon-python27-ubuntu-xenial/de047f5/console.html#_2017-04-07_12_17_05_822830) | |
| 13:40:06 | mriedem | alex_xu: did you see jichenjc's question about os-quota-class-show in the ML? | |
| 13:40:14 | openstackgerrit | John Garbutt proposed openstack/nova master: api-ref: fix os-extended-volumes:volumes_attached in servers responses https://review.openstack.org/449809 | |
| 13:40:36 | dims | mriedem : grenade and horizon are busted with the python-novaclient release. https://review.openstack.org/#/c/454164/ | |
| 13:40:50 | dims | mriedem : sdague has a fix for grenade that works fine | |
| 13:41:02 | dims | mriedem : oh, puppet-nova too | |
| 13:41:13 | dims | pinged EmilienM for puppet-nova and robcresswell for horizon. fyi | |
| 13:41:30 | EmilienM | dims: I don't know why you mentionned tripleo but we don't use it fyi | |
| 13:42:08 | dims | EmilienM : not tripleo, puppet-nova, i saw you were active there too | |
| 13:42:21 | EmilienM | dims: yeah, we'll update it soon, thanks again | |
| 13:44:00 | mriedem | dims: how are things broken when 8.0 isn't in upper-constraints? | |
| 13:44:27 | mriedem | i believe horizon already knew they were going to be broken | |
| 13:44:32 | mriedem | but again, upper-constraints | |
| 13:44:52 | mriedem | oh that's the change | |
| 13:44:52 | mriedem | i see | |
| 13:45:02 | dims | mriedem : it's trying to get stuff into u-c that's broken :) | |
| 13:45:09 | mriedem | robcresswell already knows about this for horizon | |
| 13:45:11 | dims | apologies | |
| 13:45:12 | mriedem | it was in the ML a couple of weeks ago | |
| 13:45:13 | mriedem | np | |