| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-07 | |||
| 07:20:15 | jaosorior | gibi: also, what was the site for the notification work status? | |
| 07:25:54 | gibi | jaosorior: hi! worklist is on https://vntburndown-gibi.rhcloud.com/index.html | |
| 07:26:28 | gibi | jaosorior: let me check the code to answer the instance.update on metadata question | |
| 07:28:42 | openstackgerrit | Maho Koshiya proposed openstack/nova master: Add interfaces functional negative tests https://review.openstack.org/442892 | |
| 07:30:28 | jaosorior | gibi: thanks a lot | |
| 07:39:56 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Add live-migration-force-after-timeout https://review.openstack.org/430218 | |
| 07:39:57 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: [WIP] API: Add os-migrateLive input parameters https://review.openstack.org/454578 | |
| 07:42:37 | gibi | jaosorior: deleting a metadata has the notification code https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L1108 | |
| 07:43:13 | jaosorior | gibi: but, setting it? | |
| 07:43:26 | gibi | jaosorior: and there is notification for instance.save https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L794 but I have to look more | |
| 07:43:40 | gibi | jaosorior: to see if that is called for metadata too | |
| 07:44:26 | jaosorior | instance.save ... interesting | |
| 07:44:31 | jaosorior | didn't know about that one | |
| 07:44:36 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: [WIP] API: Add os-migrateLive input parameters https://review.openstack.org/454578 | |
| 07:54:32 | seitan | Nova libvirt part: https://blueprints.launchpad.net/nova/+spec/custom-emulator-path thank you for your help. | |
| 07:54:32 | seitan | Good morning. I'm struggling with my first blueprint in Nova. There are many points, where I fail with my patch (still haven't figured out correct workflow with gerrit). But patch submission should be second step as I'm guessing now. If I understand documentation correcly, - my blueprint has to be approved before submitting any code? If so, should I attend Nova IRC meeting next week and propose my blueprint there? My blueprint is small patch for | |
| 07:57:11 | gibi | jaosorior: it seems that metadata change goes through instance.save so there should be notification but I will spin up a devstack and try it out | |
| 07:58:08 | jaosorior | gibi: dude! that would be awesome! | |
| 07:58:26 | jaosorior | gibi: is this something that works as well for legacy notifications? or is it exclusive for versioned notifications? | |
| 07:59:22 | jaosorior | gibi: also, instance.save is then called for both new instances and when updating instances? | |
| 07:59:47 | gibi | jaosorior: instance.update codepath quite similar for both legacy and versioned so it should work for both | |
| 08:00:39 | gibi | jaosorior: when instance is created then first instance.create() will be called and there will be instance.create notification | |
| 08:01:26 | gibi | jaosorior: after instance create the instance goes through couple of state changes so there will be instance.save() calls and instance.update notifications emitted | |
| 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 :) | |