| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-12 | |||
| 15:20:14 | ildikov | gibi: that fixture is a mess :( | |
| 15:22:47 | gibi | ildikov: I have my sticker to clean up it, but first I will optimize out some db query related to the instance.create | |
| 15:23:15 | gibi | ildikov: or do you have some time to work on it? ;] | |
| 15:23:23 | ildikov | gibi: I have a patch touching it with a note to figure something out there :) | |
| 15:23:42 | ildikov | gibi: well, let's see who gets there first ;) | |
| 15:24:31 | gibi | ildikov: well, that will be a real fight for that juicy commit | |
| 15:24:44 | ildikov | gibi: lol :) | |
| 15:26:37 | mriedem | gmann: i'm not sure i agree with this https://review.openstack.org/#/c/482994/ | |
| 15:26:45 | mriedem | it gets really confusing which is why i left it out of my patch | |
| 15:26:50 | mriedem | to mark 'events' as optional | |
| 15:30:46 | bauzas | gibi: may I ask a silly question about https://review.openstack.org/#/c/448779/39 ? | |
| 15:31:18 | bauzas | gibi: why some notifications samples provide an empty list for bdm notifications objects while others provide it? | |
| 15:31:20 | gibi | bauzas: sure | |
| 15:32:27 | gibi | bauzas: in some cases the bdm is overridden during the test | |
| 15:32:46 | gibi | bauzas: like test_volume_swap_server_with_error | |
| 15:33:04 | gibi | bauzas: or test_create_delete_server_with_instance_update | |
| 15:33:52 | gibi | bauzas: in test_create_delete_server_with_instance_update the bdm appears only after the instance goes through the block device mapping step during the create | |
| 15:34:20 | gibi | bauzas: so the early instance-updates has no bdm but at that point it starts appearing | |
| 15:34:33 | gibi | bauzas: and I don't want to store different sample files for each steps | |
| 15:40:21 | gibi | bauzas: specially in the instance.create case we only attach the volume after the boot not during it | |
| 15:42:19 | mriedem | Vek: can you take a look at this? https://review.openstack.org/#/c/480392/ | |
| 15:42:54 | mriedem | or andreykurilin ^ | |
| 15:43:01 | gibi | bauzas: disregard my statement about test_create_delete_server_with_instance_update | |
| 15:43:18 | gibi | bauzas: in that case the bdm is empty as there the volume also attached after the create | |
| 15:44:20 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Enable cold migration with target host(2/2) https://review.openstack.org/408964 | |
| 15:45:40 | andreykurilin | looking | |
| 15:49:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: mark instance action events parameter as optional https://review.openstack.org/480792 | |
| 15:49:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322 | |
| 15:53:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322 | |
| 16:00:40 | bauzas | gibi: okay, that's reasonable, those notifications mutated ? | |
| 16:01:03 | gibi | bauzas: the sample is mutated during the test | |
| 16:02:47 | gibi | bauzas: but I'm not sure this is what you are after | |
| 16:02:54 | mriedem | sean-k-mooney: ralonsoh: i wouldn't block on that out of band port update thingy, as i said, but i am not really an authority on that entire series of changes either as i haven't gone into it in detail, | |
| 16:03:01 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 16:03:04 | mriedem | and my understanding of a lot of the pci stuff in nova is very limited | |
| 16:03:09 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 16:03:10 | bauzas | gibi: it was just for my understanding | |
| 16:03:26 | bauzas | gibi: I have all I need, I was just in a short meeting beforehand | |
| 16:03:33 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: api-ref: Add parameters in cold migrate action https://review.openstack.org/410042 | |
| 16:04:07 | ralonsoh | mriedem: thanks for your comments! | |
| 16:04:15 | gibi | bauzas: OK. I will leave soon for today but just ping me tomorrow if you have questions | |
| 16:04:57 | bauzas | gibi: that's not necessary :) | |
| 16:05:34 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add functional tests for cold migration to same host https://review.openstack.org/414926 | |
| 16:05:43 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Add functional tests for cold migration to same host https://review.openstack.org/414926 | |
| 16:07:55 | gibi | bauzas: there are patches up to help keeping the style of the sample files consistent. I left the links under your comment | |
| 16:08:02 | bauzas | ++ | |
| 16:08:25 | bauzas | not really super important, but for review time, it helps | |
| 16:10:17 | gibi | bauzas: I agree | |
| 16:14:05 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: List/show all server migration types (2/2) https://review.openstack.org/459483 | |
| 16:28:34 | mriedem | jaypipes: given sdague was +2 on https://review.openstack.org/#/c/454322/ and is out for the rest of this week, if you're cool with it, want to just fast approve that one? | |
| 16:28:54 | jaypipes | mriedem: done | |
| 16:28:58 | mriedem | thanks | |
| 16:32:08 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777 | |
| 16:36:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove plug_ovs_hybrid, unplug_ovs_hybrid https://review.openstack.org/483030 | |
| 16:36:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Remove useless test https://review.openstack.org/483031 | |
| 16:38:35 | edleafe | 1/away | |
| 16:38:39 | edleafe | geez | |
| 16:43:08 | bauzas | edleafe: 2/there | |
| 16:43:19 | edleafe | bauzas: :) | |
| 16:57:36 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: add claim_resources() to report client https://review.openstack.org/482382 | |
| 16:57:37 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: claim resources in filter scheduler https://review.openstack.org/482383 | |
| 16:58:29 | jaypipes | edleafe, mriedem, bauzas, dansmith: ^^ squashed the "alternate destinations" patch into the claim resources in filter scheduler patch and re-ordered the patches so the add claim_resources() to report client can be reviewed ahead of the claim in scheduler patch. | |
| 16:58:36 | jaypipes | still need to handle the cells thing. | |
| 17:01:22 | mriedem | ok | |
| 17:17:19 | mriedem | gmann: https://review.openstack.org/#/c/467999/ needs some work | |
| 17:17:23 | mriedem | it's merged but the docs are lacking | |
| 17:21:19 | edleafe | jaypipes: regarding filtering alternates by cell, feel free to take as much of this as works: https://review.openstack.org/#/c/465768/8/nova/scheduler/filter_scheduler.py@181 | |
| 17:27:24 | openstackgerrit | Merged openstack/python-novaclient master: Microversion 2.49 - Virt device tagged attach https://review.openstack.org/480392 | |
| 18:16:25 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient master: WIP: Microversion 2.50 - fix quota class sets resource usage https://review.openstack.org/483060 | |
| 18:36:09 | cdent | edleafe: filtering rps by traits: https://review.openstack.org/#/c/474602/ still alive? | |
| 18:39:35 | gheorghe_ | is there something wrong with migrations on ocata? my VMs are on the same host after migration...always... | |
| 18:40:12 | mriedem | gheorghe_: are there errors in the logs? | |
| 18:40:21 | mriedem | are you doing cold migration, live migration, or resize? | |
| 18:40:42 | mriedem | there are no known issues, upstream integration test for migrations is fine | |
| 18:43:40 | rm_work | Hey, I'm about to look into making keypairs be project-level scope instead of user+project | |
| 18:43:41 | rm_work | Just wondering if there is some easy way to just enable this | |
| 18:43:43 | rm_work | or if someone has already done this before | |
| 18:43:56 | rm_work | (not necessarily to push upstream, we just need this in our cloud) | |
| 18:44:03 | rm_work | ^^ before anyone freaks out | |
| 18:44:13 | mriedem | rm_work: ask melwitt - quotas could be a problem | |
| 18:44:22 | rm_work | we currently have quotas as -1 for keypairs | |
| 18:44:34 | rm_work | so i'm not especially concerned | |
| 18:44:47 | rm_work | but i'll take that note down | |
| 18:45:17 | gheorghe_ | mriedem i am doing live migration, with block and without block (i also have some VMs on iscsi target) and in both cases the migration is not reporting any errors, but the VM stays on the same host | |
| 18:45:29 | mriedem | gheorghe_: then something is failing | |
| 18:45:41 | rm_work | melwitt: have you worked on keypairs per project? | |
| 18:45:42 | mriedem | and it's either rolling back to the source host, or it's never even getting to the destination host | |
| 18:46:54 | melwitt | rm_work: what do you mean by make it project scope instead of project+user? do you mean set a limit across a project and count allocated keypairs only across a project? | |
| 18:46:58 | gheorghe_ | mriedem, i don't see anything in /var/log/libvirt/qemu# so i suspect something is failing on nova level | |
| 18:47:41 | rm_work | melwitt: I mean, if user A on project X uploads a keypair, we want user B on project X to also see that keypair in that project | |
| 18:47:46 | rm_work | and be able to use it | |
| 18:47:51 | melwitt | oh, I see | |
| 18:48:08 | rm_work | in most other clouds, this is the way key auth works | |
| 18:48:41 | rm_work | and users are incredibly confused when they set up keypairs and then their service account or whatever goes to create a VM and errors out because the keypair isn't there (but THEY see it) | |
| 18:49:40 | rm_work | and rather than try to educate/correct an ongoing set of users who have experience with other clouds or make an expectation based on how *everything else* works, we'd rather just ... enable the functionality they expect, because I can't see a good reason not to :P | |
| 18:49:41 | rm_work | it's just public keys... | |
| 18:49:50 | rm_work | my public key is posted on my website... | |
| 18:50:08 | mriedem | gheorghe_: sure, and that should be in the /var/log/nova logs | |
| 18:50:20 | rm_work | melwitt: have you worked on anything like this? | |
| 18:50:37 | melwitt | rm_work: yeah, use case makes sense. I haven't heard of anyone doing it before though. I'm not sure what it would take, whether it would be hard. AFAIK it can't just be easily enabled | |