| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-14 | |||
| 17:22:13 | sean-k-mooney | one one trait againts too different things e.g. traits against the host and traits againts the virtulisation context. | |
| 17:22:34 | sean-k-mooney | efried: yes that would be bad | |
| 17:23:06 | sean-k-mooney | * that was ment to be or one trait. | |
| 17:23:09 | mriedem | bauzas: dansmith: sdague: i'm thinking we want these in for ocata and newton before eol too, since i'll be cutting a release today or tomorrow for that cve https://review.openstack.org/#/q/Icb418f2be575bb2ba82756fdeb67b24a28950746 | |
| 17:23:31 | mriedem | fixes bug 1675676 | |
| 17:23:31 | openstack | bug 1719730 in OpenStack Compute (nova) ocata "duplicate for #1675676 Reschedule after the late affinity check fails with "'NoneType' object is not iterable"" [High,In progress] https://launchpad.net/bugs/1719730 - Assigned to Matt Riedemann (mriedem) | |
| 17:23:53 | efried | sean-k-mooney Ah, so now we're talking about overloading the trait semantic to say, "not only do I want to make sure I wind up on a SECURE_BOOT_CAPABLE host, I also want this vm to be secure boot." | |
| 17:24:02 | efried | sean-k-mooney And *that* is the cardinal sin according to the PTB. | |
| 17:24:20 | efried | sean-k-mooney They would have you specify that second thing via some completely separate mechanism. | |
| 17:24:40 | efried | sean-k-mooney Perhaps image metadata; perhaps a different extra_spec; perhaps some other confy thing... | |
| 17:24:55 | sean-k-mooney | efried: the traith that you use for secure boot should not change based on the compute context you choose | |
| 17:25:08 | sean-k-mooney | e.g. it should be the same for vm,baremetal and contianer | |
| 17:25:27 | sean-k-mooney | in the ironic case the compute context is the same as the host | |
| 17:25:32 | efried | sean-k-mooney I'm on board with that. | |
| 17:25:39 | sean-k-mooney | in the containter and vm case the are not | |
| 17:26:02 | sdague | mriedem: make it so | |
| 17:26:05 | sdague | i.e. +A | |
| 17:26:46 | mriedem | thanks | |
| 17:26:59 | sean-k-mooney | efried: personally i would see these are two differnt traits request. one is find me a host with X and the second is find me a hypervisor capable of emulating Y and then we take the intersection of both | |
| 17:30:17 | openstackgerrit | Elod Illes proposed openstack/nova master: Use FakeLiveMigrateDriver in notification test https://review.openstack.org/519405 | |
| 17:30:34 | openstackgerrit | Eric Fried proposed openstack/nova master: Test helper: validate provider summaries https://review.openstack.org/518982 | |
| 17:30:56 | efried | gibi I rebased this on top of the series, and added affordance for traits too ^ | |
| 17:50:51 | bauzas | yay, I got a new bouncer \o/ | |
| 17:58:27 | hongbin | mriedem: ack | |
| 18:04:39 | mriedem | alaski: didn't you at one point have a doc on your thoughts for the tasks api, or was that just a patch that never merged? | |
| 18:05:59 | mriedem | i found a really old juno spec https://review.openstack.org/#/c/86938/ | |
| 18:06:40 | mriedem | oh maybe https://specs.openstack.org/openstack/nova-specs/specs/backlog/approved/instance-tasks.html | |
| 18:12:12 | mordred | mriedem: questoin about scheduler hints ... the API ref https://developer.openstack.org/api-ref/compute/#create-server seems to indicate that os:scheduler_hints can be put as a key on the server dict in the request, or that OS-SCH-HNT:scheduler_hints can be used outside of the server dict. | |
| 18:12:54 | mordred | mriedem: but there's an old guide https://docs.openstack.org/kilo/config-reference/content/section_compute-scheduler.html that shows using os:scheduler_hints at the top level ... and i just got a patch: https://review.openstack.org/#/c/519705/2/shade/openstackcloud.py to move using os:scheduler_hints to outside of the server dict | |
| 18:13:29 | mordred | mriedem: is the story that it always goes into the top level of the payload and that either key works? | |
| 18:16:04 | mriedem | i think the latter, i think it's a top-level key https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/scheduler_hints.py#L75 | |
| 18:16:10 | mriedem | and either works | |
| 18:16:25 | mriedem | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/scheduler_hints.py#L18 | |
| 18:17:24 | sean-k-mooney | for consitnecy sake shade and osc should proably pass scheduler hints the same way | |
| 18:17:46 | mriedem | i don't think you can send it in the server body | |
| 18:17:50 | mriedem | it's a top-level key | |
| 18:17:57 | mriedem | the server create api-ref in nova is just confusing | |
| 18:18:04 | mriedem | "The dictionary of data to send to the scheduler. Alternatively, you can specify OS-SCH-HNT:scheduler_hints as the key in the request body." | |
| 18:18:13 | mriedem | that's just saying, you can use either key | |
| 18:18:30 | mriedem | i don't know why we have 2 keys, i'm assuming v2 api extension fun | |
| 18:18:40 | mriedem | gmann, sdague or oomichi might remember | |
| 18:20:00 | mriedem | mordred: yeah e.g. https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#differenthostfilter | |
| 18:20:05 | mriedem | "With the API, use the os:scheduler_hints key. For example:" | |
| 18:20:40 | mordred | ok. cool. so it just shows up weird in the api ref docs ... | |
| 18:20:49 | mordred | since it's in the same block as key_name and whatnot | |
| 18:20:50 | mriedem | yeah, we should be clear that it's a top-level key | |
| 18:20:53 | mriedem | yup | |
| 18:21:04 | mriedem | i, or someone else, can amend the doc | |
| 18:22:21 | mordred | cool. thanks! | |
| 18:23:10 | openstackgerrit | Elod Illes proposed openstack/nova master: Transform instance-live_migration_pre notification https://review.openstack.org/482070 | |
| 18:24:10 | mriedem | the example request shows it's top-level too | |
| 18:24:10 | mriedem | https://developer.openstack.org/api-ref/compute/#create-server | |
| 18:24:27 | mriedem | so that helps somewhat | |
| 18:27:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: make a note about os:scheduler_hints being a top-level key https://review.openstack.org/519717 | |
| 18:27:56 | mriedem | mordred: see if this floats your boat ^ | |
| 18:28:46 | jaypipes | crlb: I'll pull your patch and run locally and see what's up. | |
| 18:29:05 | mordred | mriedem: yes! that's super helpful | |
| 18:30:10 | mriedem | cburgess: semi interesting live migration abort scenario for you | |
| 18:30:29 | cburgess | OK shoot | |
| 18:30:32 | mriedem | cburgess: today you can list in-progress live migrations for a given server | |
| 18:30:33 | mriedem | https://github.com/openstack/nova/blob/16.0.0/nova/db/sqlalchemy/api.py#L4789 | |
| 18:30:38 | mriedem | if it's in one of those 4 states ^ | |
| 18:30:50 | mriedem | however, you can only abort a running migration https://github.com/openstack/nova/blob/16.0.0/nova/compute/api.py#L3952 | |
| 18:31:05 | mriedem | presumably because the migration transitions fast enough that it gets to the hypervisor and starts running | |
| 18:31:08 | mriedem | however, | |
| 18:31:21 | mriedem | we have this max_concurrent_live_migrations config option in compute which defaults to 1, | |
| 18:31:36 | mriedem | so you could be trying to move 10 instances off a host via live migration, and by default those are all going to queue up, | |
| 18:31:48 | mriedem | let's say you wanted to abort half of those (1 in 10 are running) | |
| 18:31:53 | mriedem | the abort would fail | |
| 18:32:47 | cburgess | mriedem Give me a few... sorry had someone talking to me | |
| 18:32:51 | mriedem | one solution is just bump up your max_concurrent_live_migrations value to 10, but then you hit issues with running a bunch of migrations at once | |
| 18:32:58 | mriedem | np, just looking for some ops feedback | |
| 18:33:55 | alaski | mriedem: there was http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/backlog/approved/instance-tasks.rst | |
| 18:34:35 | mriedem | alaski: yup i found it later via google, i was mistakenly searching the nova docs | |
| 18:34:43 | alaski | cool | |
| 18:38:42 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/pike: Handle exception on adding secgroup https://review.openstack.org/515418 | |
| 18:40:33 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/ocata: Handle exception on adding secgroup https://review.openstack.org/515421 | |
| 18:42:44 | jaypipes | crlb: https://pastebin.com/maKwN7pM -- failures are reproduceable for me. Only suggestion I have is do an rm -rf .tox/ and then retry the tox -epy27,pep8. Other than that... perhaps you forgot to git review and push your latest changes to gerrit? | |
| 18:43:13 | efried | crlb If you run tox with -r it'll rebuild the venv. | |
| 18:43:23 | openstackgerrit | Merged openstack/nova stable/newton: Functional regression test for evacuate with a target https://review.openstack.org/516118 | |
| 18:43:25 | efried | easier than rm -rf .tox | |
| 18:45:26 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/pike: Handle exception on adding secgroup https://review.openstack.org/515418 | |
| 18:46:13 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/pike: Handle exception on adding secgroup https://review.openstack.org/515418 | |
| 18:48:33 | openstackgerrit | Hongbin Lu proposed openstack/nova stable/ocata: Handle exception on adding secgroup https://review.openstack.org/515421 | |
| 19:12:22 | openstackgerrit | Hongbin Lu proposed openstack/nova master: Handle not found error on taking snapshot https://review.openstack.org/511074 | |
| 19:17:40 | openstackgerrit | Ken'ichi Ohmichi proposed openstack/nova master: Add error message on metadata API https://review.openstack.org/517152 | |
| 19:20:59 | crlb | jaypipes: checked pastebin. The test_versions.py that you are running is not the latest, but patch set 2 updated it and dealt with the pep8 errors. If i try it review, I get: git review | |
| 19:20:59 | crlb | Creating a git remote called "gerrit" that maps to: | |
| 19:20:59 | crlb | ssh://crlb@review.openstack.org:29418/openstack/nova.git | |
| 19:20:59 | crlb | No changes between HEAD and gerrit/master. Submitting for review would | |
| 19:20:59 | crlb | be pointless. | |
| 19:22:23 | mnaser | crlb: did you commit anything on your local branch? | |
| 19:22:58 | mnaser | also, puppet fun, we suspect that we're seeing some weird timeout in puppet openstack intergration due to this change - https://github.com/openstack/puppet-nova/commit/df638e2526d2d957318519dfcfb9098cb7726095 | |
| 19:23:23 | mnaser | we go from multiple threads in a single process, to single thread in multiple processes | |
| 19:23:55 | mnaser | but it seems to have spawned some strange timeouts with floating ip assignment. what's the nova team stance on this in terms of "best practice" ? | |
| 19:25:24 | efried | jaypipes Can I do stuff to this series? https://review.openstack.org/#/c/516778/ | |
| 19:27:25 | mnaser | looks like devstack uses API_WORKERS for # of processes in uwsgi, and has an 'enable-threads' feature | |
| 19:36:13 | crlb | jaypipes. I'm sorry, I didn't realize that subsequent git reviews would give you different change numbers. The 2nd and 3rd patch sets are on change #518119. | |
| 19:45:13 | mriedem | dansmith: i reckon i should put out a release note for that cve on the stable branches, so i guess i'll do that right quick | |
| 19:45:17 | mriedem | and we can ram it through | |