Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-07
09:14:17 johnthetubaguy seitan: you don't have to attend, its more about adding it to the agenda and including enough information in the blueprint to describe why you are doing what you are doing
09:16:55 johnthetubaguy seitan: the other thing I think your patch is missing is a unit test
09:18:36 seitan johnthetubaguy: that would be third question - i'm not sure, how to submit unit test.
09:19:20 johnthetubaguy seitan: do you see how to run the unit tests local on your dev box, and where the code for them lives?
09:20:50 seitan johnthetubaguy: yes, I'm able to run tox test locally if this is it
09:21:50 seitan johnthetubaguy: oh, i should make a test script to check if my patch works?
09:24:35 johnthetubaguy seitan: yeah, thats the idea, basically modify or add a test to ensure your patch generates the correct domain XML
09:27:36 seitan johnthetubaguy: aha, will do that. And the last question: do i need to create more information for this patch e. g. create specification file and add URL to it in blueprint?
09:33:51 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.volume_attach notification https://review.openstack.org/401992
09:33:51 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.volume_detach notification https://review.openstack.org/408676
09:41:58 johnthetubaguy seitan: I don't think you need a nova-spec for this one, the blueprint alone should be fine
09:45:16 seitan johnthetubaguy: thank you for your help!
09:45:23 johnthetubaguy seitan: no problem
09:53:03 sfinucan vladikr, artom, cfriesen, sean-k-mooney: Do we expose any information about CPU features at the moment in nova?
09:53:24 sfinucan i.e. support for SSE etc.
10:03:43 openstackgerrit jichenjc proposed openstack/nova-specs master: Add host-command-with-POST https://review.openstack.org/303388
10:08:41 kashyap sfinucan: Not as near as I know
10:09:01 kashyap sfinucan: But to compute the most feature-rich CPU which is compatible with all given host CPUs, we use the libvirt's baselineCPU() API
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?

Earlier   Later