Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-12
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
18:50:44 rm_work kk
18:50:52 gheorghe_ mriedem i get only info messages within /var/log/nova ... if you want, i can try i migration now and give you the nova logs. do you want to see the ones from controller or the ones from kvm?
18:51:10 mriedem gheorghe_: i don't want to debug your logs no
18:51:18 edleafe cdent: yes, the filtering by traits is still alive. It can also be adapted for filtering the new allocation candidates method.
18:51:21 mriedem gheorghe_: run it with debug=True in the nova.conf on all nodes, computes and controller
18:52:19 mriedem and then i'd trace the request id through the nova-api, conductor and compute logs
18:52:35 gheorghe_ request id returns only an info message
18:52:49 mriedem the request id is logged with all messages for the given request context
18:52:57 mriedem so if you have debug logging enabled, you should be able to see it there also
18:53:34 mriedem e.g. http://logs.openstack.org/90/481290/3/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/fcc4b2f/logs/screen-n-cpu.txt.gz#_Jul_08_18_07_57_384617
18:53:45 gheorghe_ omg mariedem i actually found something
18:53:49 mriedem req-df8aac96-7d4f-4652-9237-d6da65164ee5 is the request id
18:54:03 gheorghe_ https://paste.gnome.org/pg7hkufiz
18:54:13 gheorghe_ i will troubleshoot this, brb
18:54:48 mriedem yup that would make it fail
18:56:47 gheorghe_ kvm-04 is not even listening on 16509
18:59:11 rm_work melwitt: ah, I was wrong about keypairs already being associated with a project
18:59:21 rm_work they are purely user associated at the moment :(
18:59:40 gheorghe_ mriedem does it work only with insecure conn? https://paste.gnome.org/pfdfgbkaj
18:59:41 rm_work so yeah pretty big change I think T_T
19:03:49 melwitt rm_work: *looks* yeah, I didn't know project_id isn't even part of the data model. so yeah, much bigger change than I was thinking too
19:03:53 mriedem gheorghe_: there are lots of different ways to configure it i think,
19:03:57 mriedem devstack uses ssh
19:04:16 mriedem you could also run in tunneled mode but that slows it down
19:04:52 gheorghe_ mriedem this is not devstack, this is the tutorial with 1 controller and 4 kvm hosts
19:05:14 mriedem sure
19:05:17 mriedem that's not my point though

Earlier   Later