| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-19 | |||
| 16:18:24 | openstackgerrit | Eric Fried proposed openstack/nova master: Service user token requested with no auth https://review.openstack.org/512329 | |
| 16:18:42 | stephenfin | Otherwise is just deleting some dead code but no more. cliff delivers enough tangible benefits to justify its inclusion | |
| 16:18:56 | stephenfin | and means nova is using the exact same tooling as everyone else in OpenStack | |
| 16:18:59 | stephenfin | *CLI tooling | |
| 16:19:00 | bauzas | stephenfin: what I'm saying is that we don't need a spec for something just pure internal refactoring, but I guess pulling a dependency like cliff is more than just internal refactoring | |
| 16:19:17 | bauzas | stephenfin: how do you see the implementation path ? | |
| 16:19:20 | stephenfin | Yeah, I'm not sure if it is, hence the question :) | |
| 16:19:33 | stephenfin | Pretty much what I said in the spec (I think) | |
| 16:19:38 | bauzas | stephenfin: fix first some issues, then use cliff for only some subcommands? | |
| 16:19:38 | stephenfin | Dump all the deprecated stuff | |
| 16:19:56 | bauzas | or do you plan to just change all at once ? | |
| 16:20:32 | bauzas | stephenfin: the problem is that a cliff move would be like super low priority | |
| 16:20:42 | bauzas | so I'm afraid that effort could be multi-cycle | |
| 16:21:01 | bauzas | hence my question about how you plan to migrate all the existing commands | |
| 16:21:12 | stephenfin | I plan to add the cliff stuff one by one with tests, but not register the 'console_scripts' entry points | |
| 16:21:29 | stephenfin | then, once it's done, we switch entry points and delete all the existing crud | |
| 16:21:30 | openstackgerrit | Eric Fried proposed openstack/nova master: Service user token requested with no auth https://review.openstack.org/512329 | |
| 16:21:38 | bauzas | 'one by one', one being a subcommand like Cellv2 ? | |
| 16:21:54 | stephenfin | Yup | |
| 16:22:18 | stephenfin | You wouldn't be able to run any of them via the command-line but they'd have unit tests | |
| 16:22:41 | stephenfin | There's only four or five sub-commands to migrate once the deprecated stuff is removed, in fairness | |
| 16:23:11 | bauzas | if I'm using the existing CLI, would I go thru a different codepath ? | |
| 16:23:25 | stephenfin | Also, I know it's low priority. This is purely a tech debt reductionexercise | |
| 16:23:33 | stephenfin | For the CLI aspects of it, yes | |
| 16:23:38 | bauzas | FWIW, I played with cliff but it lasts (4 or 5 years I don't remember exactly) | |
| 16:23:53 | stephenfin | For the actual underlying command, shared code path | |
| 16:24:03 | bauzas | k | |
| 16:24:26 | stephenfin | new UTs would only exercise the arg parsers plus any gaps I will uncover | |
| 16:24:28 | bauzas | mriedem: do you think we would really a spec for the above ? | |
| 16:24:40 | bauzas | mriedem: honestly a specless BP seems good if we don't change the CLI | |
| 16:25:12 | bauzas | then we could defer the CLI change in a Rocky spec I guess | |
| 16:37:23 | stephenfin | bauzas: Just to reiterate, the CLI won't change from a usage perspective (minus some help messages, return codes). How it's implemented under the hood would | |
| 16:50:27 | openstackgerrit | Eric Fried proposed openstack/nova master: [Trivial] Fix up a docstring https://review.openstack.org/513447 | |
| 16:50:39 | efried | sdague ^ that's been on my backlog for a while :) | |
| 16:53:13 | sdague | +A | |
| 17:17:37 | dansmith | jaypipes: are you working on a rev to 415921? | |
| 17:32:52 | mriedem | ildikov: ok notes are in https://review.openstack.org/#/c/499777/ | |
| 17:32:59 | mriedem | groot: johnthetubaguy: ^ | |
| 17:35:42 | ildikov | mriedem: thanks! | |
| 17:47:03 | ildikov | mriedem: johnthetubaguy: how much time do I have to upload the new version? | |
| 17:59:06 | openstackgerrit | sahid proposed openstack/nova-specs master: virt: allow instances to be booted with trusted VFs https://review.openstack.org/485522 | |
| 17:59:28 | openstackgerrit | Ildiko Vancsa proposed openstack/nova-specs master: Add multiattach support to Nova https://review.openstack.org/499777 | |
| 18:00:38 | melwitt | mriedem: I was talking to penick_ the other day and they've been testing ocata internally, and noticed delete is really slow (same as you encountered in your devstack fakedriver testing) | |
| 18:00:51 | ildikov | mriedem: johnthetubaguy: jgriffith: new old version of the spec ^^ | |
| 18:01:05 | melwitt | as in, the REST API call returns fast but it takes like a minute for the instance to disappear | |
| 18:01:58 | melwitt | hopefully they can investigate but I've made myself a TODO to look into it when I get a chance | |
| 18:07:56 | jaypipes | dansmith: yes | |
| 18:09:37 | dansmith | alright. | |
| 18:11:14 | mriedem | ildikov: 4 hours? | |
| 18:11:46 | ildikov | mriedem: uploaded a new version plz check :) | |
| 18:11:49 | mriedem | melwitt: cool, ok - i think what huawei did internally was run the volume and network cleanup in parallel like when you're creating the instance | |
| 18:12:07 | mriedem | melwitt: understanding if there is a regression would be nice too though | |
| 18:12:24 | jgriffith | ildikov couple questions/nits in review | |
| 18:12:33 | melwitt | mriedem: and that solved it? will they upstream it? | |
| 18:12:51 | mriedem | melwitt: not sure, i think they were still saying it's slow, but they are on mitaka | |
| 18:13:04 | melwitt | mriedem: yeah, it was a regression for sure compared with juno, so I'll dig into what happened there | |
| 18:13:20 | dansmith | mriedem: you didn't have volumes in your test, right? | |
| 18:13:25 | mriedem | nope | |
| 18:13:29 | mriedem | nor networking | |
| 18:13:31 | dansmith | yeah | |
| 18:13:41 | dansmith | so the networking parallelism isn't going to buy you as much on delete I think | |
| 18:13:46 | melwitt | yahoo/oath doesn't have volumes either | |
| 18:13:55 | dansmith | the point there is to overlap some long-running things like image download with network provisioning, | |
| 18:13:57 | melwitt | and they're using nova-net via hack | |
| 18:14:03 | melwitt | so it's not related to neutron | |
| 18:14:07 | dansmith | which wouldn't be as much of a thing on delete | |
| 18:14:17 | mriedem | ocata would mean cleaning up allocations in placement | |
| 18:14:24 | mriedem | but not sure why that would take much longer | |
| 18:14:44 | openstackgerrit | sahid proposed openstack/nova-specs master: update: introducing isolate emulthreads on host https://review.openstack.org/511188 | |
| 18:15:04 | melwitt | but huawei said mitaka is slow and that's pre-placement | |
| 18:15:05 | jaypipes | dansmith: I don't see how cur_gen can be None in that patch. | |
| 18:15:19 | dansmith | jaypipes: you're doing a .get() on it, that's how | |
| 18:16:12 | jaypipes | dansmith: the comment I removed is this: | |
| 18:16:13 | jaypipes | # Update our generation immediately, if possible. Even if there | |
| 18:16:13 | jaypipes | # are no inventories we should always have a generation but let's | |
| 18:16:13 | jaypipes | # be careful. | |
| 18:16:33 | jaypipes | dansmith: I should have just replaced the get() with a dict access. | |
| 18:16:40 | sahid | jaypipes: about your tweet, i understand that it's a bit confusing, i just try to address an use-case | |
| 18:16:40 | dansmith | jaypipes: that's what I'm saying | |
| 18:16:45 | jaypipes | dansmith: because there simply isn't a way to get a None value there. | |
| 18:16:56 | sahid | in any case i update the spec to fix the issue with ci I hope everytinhg is ok now :) | |
| 18:17:08 | dansmith | jaypipes: either do that so we break, or check the result of the get() and raise something specific | |
| 18:17:09 | dansmith | jaypipes: but don't just ignore it and pass None to placement | |
| 18:17:22 | jaypipes | dansmith: will do the former. | |
| 18:17:42 | sahid | oh... I just noticed your comments, let see | |
| 18:17:58 | dansmith | jaypipes: thanks | |
| 18:18:17 | penick_ | melwitt: we "fixed" the delete timing this morning by setting reclaim_instance_interval to a non-zero number. Deletes still take a minute or two on the backend, but at least it'll seem fast for users. | |
| 18:18:38 | mriedem | melwitt: the new internal perf thing i got yesterday was they were saying claims were taking too long in the compute because of the lock | |
| 18:18:49 | mriedem | they are testing creating 70 instances on the same host at the same time | |
| 18:19:47 | melwitt | penick_: you are now leveraging soft-delete | |
| 18:19:56 | penick_ | yep | |
| 18:20:33 | melwitt | mriedem: claims in mitaka, right? the old style claim | |
| 18:20:43 | mriedem | yes | |
| 18:20:58 | mriedem | but, we still have all that code if you're using the ram/core/disk filters | |
| 18:21:03 | mriedem | and/or caching scheduler | |
| 18:21:26 | melwitt | so the COMPUTE_RESOURCE_SEMAPHORE | |
| 18:21:28 | mriedem | anyway, there was no low level profiling done | |
| 18:21:29 | mriedem | yeah | |
| 18:21:35 | dansmith | and that's all been there for a long time | |
| 18:21:41 | mriedem | i was going to see if there are things we hit in the db while we have the lock held that could be moved out | |