Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-19
15:40:35 bauzas graaaah, the Gerrit flickering when you open a comment makes me mad
15:42:43 efried bauzas If you can snap a video of that happening, send it to sdague
15:43:21 bauzas jaypipes: I officially hereby invoke your SQL skills and ask you if you know if SQLA can support an index of a tuple of multiple fields where one of them comes from a inherited mixin
15:43:38 bauzas jaypipes: context being https://review.openstack.org/#/c/507762/12
15:44:07 bauzas that's where a POC would help a specs review :)
15:44:46 dansmith bauzas: reports are that if you set render=slow it will be better about that
15:46:00 sdague I apparently have never seen this thing (or noticed it)
15:46:49 jaypipes bauzas: you can include fields from a mixin into an index, sure.
15:48:58 jaypipes bauzas: added a comment (and link to an example) to the spec
15:49:38 bauzas jaypipes: oh fsck, deleted of course
15:49:50 openstackgerrit Ed Leafe proposed openstack/nova master: Remove the Pike migration code for flavor migration https://review.openstack.org/494206
15:50:07 bauzas but yeah the tuple is wrong then, since we support soft-deletions for instance actions...
15:50:24 bauzas not sure you can really *delete* an action tho
15:52:09 bauzas dansmith: sorry, WDYM ?
15:52:52 jaypipes bauzas: the gerrit flickering annoyance.
15:53:02 efried bauzas Go into settings => diff preferences and set Render => Slow
15:53:07 dansmith bauzas: https://imgur.com/a/Oq5rw
15:53:08 dansmith bauzas: gerrit, diff settings, render -> slow
15:53:10 bauzas aaaah cool
15:53:12 jaypipes bauzas: go to settings, then diff prefs, then render => slow.
15:53:15 bauzas ta !
15:53:21 jaypipes lol, three of us :)
15:53:22 efried I win
15:53:29 dansmith what? I was totally first
15:53:37 dansmith by six seconds
15:53:39 bauzas dansmith: +1 marmelade
15:53:44 dansmith hehe
15:54:16 bauzas dansmith: you should seriously consider then a checked-in luggage :p
15:54:31 dansmith willd o
15:54:34 dansmith er, will do
15:57:49 openstackgerrit John Griffith proposed openstack/nova-specs master: Add multiattach support to Nova https://review.openstack.org/499777
16:16:08 bauzas stephenfin: honestly, if all is about code refactoring for Queens, I don't think it needs a spec *unless two points*
16:16:19 bauzas #1 we don't use a new framework
16:16:38 bauzas #2 we don't change the consumed interface we have for all our customers
16:16:57 stephenfin You mean *assuming* those things?
16:17:01 stephenfin As opposed to unless
16:17:05 bauzas in other words, if we still have a backwards-compatible behaviour
16:17:20 stephenfin The CLI won't change from a users perspective
16:17:24 bauzas stephenfin: my point is that you said there are multiple issues
16:17:26 stephenfin All that will change is return code and docs
16:17:38 stephenfin And the return code one could wait
16:17:49 bauzas I'd love to see what could be done without cliff and what other things need it
16:17:53 stephenfin We would be changing the framework, though end-users won't see this
16:18:15 stephenfin I'm not dropping the cliff bit - it's still the main reason for this :)
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 stephenfin Dump all the deprecated stuff
16:19:38 bauzas stephenfin: fix first some issues, then use cliff for only some subcommands?
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

Earlier   Later