| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-07 | |||
| 08:02:36 | jaosorior | gibi: oh, so instance.update will also run for new instances, not only when one updates parameters for them? | |
| 08:03:04 | jaosorior | say I do a nova boot, will I receive an instance.update notification? | |
| 08:17:04 | bauzas | tonyb: around by that time ? | |
| 08:18:04 | bauzas | tonyb: I have a bugfix that we merged in Pike and Ocata-RC2, but I wonder if it would be worth cherry-picking it for Newton too | |
| 08:18:19 | bauzas | tonyb: https://review.openstack.org/#/c/392643/6 looks to me reasonable | |
| 08:20:30 | bauzas | tonyb: FWIW https://review.openstack.org/#/c/454593/ comments welcome | |
| 08:38:24 | frickler | sfinucan: sorry for missing the meeting yesterday and thanks for taking up my patches. I'm going to add reno+tests and then let's see what other reviewers think | |
| 08:41:14 | gibi | jaosorior: you will receive instance.update when nova update the instance state during the boot | |
| 08:42:24 | gibi | jaosorior: here is a functional test that shows what notifications are triggered during nova boot https://github.com/openstack/nova/blob/master/nova/tests/functional/notification_sample_tests/test_instance.py#L157 | |
| 08:43:30 | jaosorior | I see | |
| 08:43:44 | jaosorior | gibi: is there a specific notification for instance.save? Would probably be less cumbersome than listening on instance.update | |
| 08:46:59 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 08:47:33 | gibi | jaosorior: there is no specific notification for instance.save, you have to listen to instance.update | |
| 08:47:39 | jaosorior | ok | |
| 08:47:41 | jaosorior | that works | |
| 08:47:46 | jaosorior | gibi: thanks a lot dude | |
| 08:47:56 | gibi | jaosorior: I'm still in a process testing the metadata update question | |
| 08:47:57 | johnthetubaguy | seitan: hi, can I help with your blueprint? | |
| 08:48:07 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Add live-migration-force-after-timeout https://review.openstack.org/430218 | |
| 08:48:23 | johnthetubaguy | seitan: is this the patch you are wondering about: https://review.openstack.org/#/c/445558 | |
| 08:52:30 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: [WIP] API: Add os-migrateLive input parameters https://review.openstack.org/454620 | |
| 08:56:18 | gibi | jaosorior: here are the notifications from a devstack about an nova boot | |
| 08:56:21 | gibi | jaosorior: http://paste.openstack.org/show/605721/ | |
| 08:56:55 | jaosorior | brilliant | |
| 08:56:58 | gibi | jaosorior: and then here are the notifications about a nova meta |
|
| 08:57:23 | gibi | jaosorior: it confirms that instance.update is emitted for meta set | |
| 08:57:35 | jaosorior | gibi: excellent, this is very useful for me. Thanks a lot | |
| 08:58:31 | gibi | jaosorior: no problem. You can easily log notifications if you set the in the nova.conf driver = log | |
| 08:58:43 | gibi | jaosorior: in the section [oslo_messaging_notifications] | |
| 08:59:23 | gibi | then you just grep the nova logs for oslo.messaging.notification lines | |
| 08:59:49 | jaosorior | that's good to know | |
| 09:00:08 | jaosorior | I was hacking up my service to output all the notifications it detected | |
| 09:00:19 | jaosorior | this is a bit easier for testing a bit | |
| 09:01:01 | seitan | johnthetubaguy: Hello, yes, this is the correct one | |
| 09:03:16 | johnthetubaguy | seitan: how can I help you? it seems you have quite a lot of patches up against that blueprint right now | |
| 09:04:20 | johnthetubaguy | seitan: this guide might help you: https://docs.openstack.org/infra/manual/developers.html | |
| 09:04:37 | johnthetubaguy | seitan: I think you need to click abandon on all the patches that aren't the "best" one so far | |
| 09:05:18 | johnthetubaguy | seitan: at a quick look at your patch, I would have a read of this doc on the git commit message: https://wiki.openstack.org/wiki/GitCommitMessages | |
| 09:06:22 | seitan | johnthetubaguy: Yes, I have read this documents, but still have some things unclear | |
| 09:06:33 | johnthetubaguy | seitan: it looks like you are squashing your changes locally, but you end up with multiple change-ids in your git commit messages | |
| 09:08:27 | johnthetubaguy | seitan: basically, you need to get one single gerrit entry, and has in one commit your latest and best code for your blueprint | |
| 09:09:01 | johnthetubaguy | seitan: you might do that as lots of little git commits locally, but we need one git commit to review for merge into our master branch in gerrit | |
| 09:09:11 | seitan | johnthetubaguy: So basically I should abandon all patches but the first one. Then to update that first release i just edit my Change-Id before putting to review? | |
| 09:09:35 | johnthetubaguy | seitan: I would do that to tidy things up, yes | |
| 09:11:29 | johnthetubaguy | seitan: the git hook adds the change-id to all your commits right? if you do an interactive rebase, I would use the "fix up" thing, and that should drop all the commit messages from your various commits, and stop you needing to tweak the change-id | |
| 09:11:58 | johnthetubaguy | seitan: personally I just do git commit --amend locally, because I know the history is stored in the gerrit versions of my match | |
| 09:12:22 | gibi | johnthetubaguy: there is a small bugfix with +2 and lot of +1 ons https://review.openstack.org/#/c/430026 Could you check it please? | |
| 09:12:40 | johnthetubaguy | gibi: not done my already has +2 sweep yet, it should get hit as part of that | |
| 09:13:20 | gibi | johnthetubaguy: cool, thanks a lot! | |
| 09:13:25 | seitan | johnthetubaguy: okay, that makes things more clear. Thank you. What about approving the blueprint? Should i attend irc meeting to propose it? | |
| 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_detach notification https://review.openstack.org/408676 | |
| 09:33:51 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform instance.volume_attach notification https://review.openstack.org/401992 | |
| 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? | |