| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 14:33:23 | mriedem | need another core for the bottom 2 patches in this series to move the nova-cells-v1 job in-tree and then change it to use neutron, which is the first part of removing nova-network https://review.openstack.org/#/c/549780/ | |
| 14:36:03 | stephenfin | mriedem: I'll grab em | |
| 14:44:09 | sq4ind | I think I've found why I was having issues... basically when listing cells in placement I had one out of three rabbitmq servers in the transport url, and only hosts connected to this rabbitmq server were updating their resource usage. Now I've fixed the url, I am also moving VMs from hosts and removing hosts from placement cells, and then recreating them. After that everything works as it should be | |
| 14:44:16 | sq4ind | hope that makes sense | |
| 14:46:38 | efried | sq4ind: Glad you figured it out - sorry we couldn't be more help. | |
| 14:55:40 | sq4ind | efried, no problem :D I like to dig more and more into openstack internals :D And you were very helpful: you've gave some clues where to look at it :D, thanks ! :) | |
| 15:01:21 | openstackgerrit | Eric Fried proposed openstack/nova master: Support extending attached ScaleIO volumes https://review.openstack.org/554679 | |
| 15:01:26 | mriedem | stephenfin: thanks for hitting those cells ci patches | |
| 15:03:17 | stephenfin | mriedem: np | |
| 15:06:50 | mriedem | edmondsw: we don't need both a powervm-resize and powervm-cold-migrate blueprint | |
| 15:06:55 | mriedem | if you implement resize, you have to have cold migrate | |
| 15:07:07 | mriedem | so i'm going to mark the cold migrate one as superseded | |
| 15:07:18 | edmondsw | mriedem yep | |
| 15:07:22 | mriedem | esberglu: ^ | |
| 15:07:56 | edmondsw | rebuild and evac would go in there as well | |
| 15:08:07 | edmondsw | esberglu update the description on that one? | |
| 15:08:14 | edmondsw | (resize) | |
| 15:08:19 | mriedem | eh? | |
| 15:08:23 | mriedem | those are not the same as resize | |
| 15:08:27 | mriedem | nor do they require a blueprint | |
| 15:08:32 | openstackgerrit | Chris Dent proposed openstack/nova master: Use microversion parse 0.2.1 https://review.openstack.org/550265 | |
| 15:08:34 | mriedem | if your driver can spawn and destroy, you support rebuild | |
| 15:09:44 | mriedem | https://blueprints.launchpad.net/nova/rocky should be accurate now right? | |
| 15:09:50 | mriedem | 5 powervm-* blueprints | |
| 15:10:25 | edmondsw | mriedem sorry otp | |
| 15:14:26 | openstackgerrit | Raoul Hidalgo Charman proposed openstack/nova master: Expose shutdown retry interval as config setting https://review.openstack.org/552483 | |
| 15:14:34 | mriedem | does anyone from virtuozzo still work on nova? | |
| 15:14:38 | mriedem | because their CI is borked | |
| 15:14:47 | edmondsw | mriedem yeah, looks right | |
| 15:15:07 | esberglu | edmondsw: mriedem: Will update resize | |
| 15:15:11 | edmondsw | mriedem I meant evac would come only when we support migration | |
| 15:15:19 | edmondsw | esberglu I think mriedem wants it left as-is | |
| 15:15:20 | mriedem | edmondsw: those aren't the same | |
| 15:15:22 | mriedem | or related | |
| 15:15:43 | mriedem | evac is not the same as cold migrate, | |
| 15:15:49 | mriedem | it's a rebuild of the instance on another host | |
| 15:15:55 | mriedem | using spawn and destroy | |
| 15:16:00 | edmondsw | oh, right... | |
| 15:16:29 | edmondsw | sorry, too many different uses of the same term | |
| 15:16:56 | dansmith | mriedem: should I link him or will you? | |
| 15:17:17 | dansmith | edmondsw: http://www.danplanet.com/blog/2016/03/03/evacuate-in-nova-one-command-to-confuse-us-all/ | |
| 15:17:30 | edmondsw | dansmith +1 | |
| 15:17:57 | edmondsw | I remember reading that when it was new | |
| 15:18:22 | edmondsw | esberglu ^ | |
| 15:18:28 | kashyap | dansmith: At this point it warrants to be put in the channel topic ;-) | |
| 15:18:32 | dansmith | heh | |
| 15:18:42 | kashyap | "Evacuate", please see: $short-url | |
| 15:19:08 | kashyap | dansmith: Then you can start chiding people: "Don't you read channel topic?!" | |
| 15:19:29 | dansmith | kashyap: make a bot, that will waste more time | |
| 15:20:04 | kashyap | True; it reminds me of the bot on #fedora-devel, where if someone just says: | |
| 15:20:15 | kashyap | Person: Ping | |
| 15:20:17 | kashyap | Bot: https://fedoraproject.org/wiki/No_naked_pings | |
| 15:22:14 | efried | wow | |
| 15:22:19 | efried | TIL | |
| 15:22:29 | dansmith | efried: not everyone agrees with those assertions (like myself) | |
| 15:22:33 | efried | ...that some people are just too damn touchy | |
| 15:22:36 | dansmith | hehe | |
| 15:22:38 | dansmith | yeah that | |
| 15:22:52 | eric-young | efried: thanks for the quick edit on https://review.openstack.org/554679 | |
| 15:22:56 | mriedem | can we now say that nova people aren't as bad as fedora people? | |
| 15:23:07 | efried | eric-young: Yahyoubetcha | |
| 15:23:10 | eric-young | efried: I am seeing another issue right now, and am testing to see if it's just me | |
| 15:23:11 | mriedem | when it comes to the every 6 month nova hate-a-thon? | |
| 15:23:26 | efried | eric-young: Mm, I didn't test or anything, just fixed obvious problem. | |
| 15:23:51 | mriedem | eric-young: that requires a minimum os-brick right? | |
| 15:23:53 | eric-young | efried, yeah. silly mistake but it did expose something else. | |
| 15:24:44 | kashyap | efried: Yeah, I don't mind such bare pings. But prefer "dressed up" pings | |
| 15:24:49 | mriedem | you've been riedmeann'ed | |
| 15:24:55 | mriedem | gd i can't even spell my own name | |
| 15:24:56 | mriedem | ffs | |
| 15:25:17 | kashyap | mriedem: You slipped in "mean" there; I think they call it: "Freudian" | |
| 15:28:21 | sean-k-mooney | edleafe: just on the uuids its not a uuid anymore if you acept a string with our hypentens. if we decalre the filed as an int at the api then we could accpet 3c3770f6-e1a6-4c3c-ac1d-ba2aa2f231c4 as a hex int 3c3770f6e1a64c3cac1dba2aa2f231c4 | |
| 15:28:28 | mriedem | fyi all things are going to be blocked right now https://review.openstack.org/555314 | |
| 15:28:33 | mriedem | until ^ merges | |
| 15:29:32 | dansmith | efried: so, on this aggregate thing | |
| 15:30:17 | dansmith | efried: what if we had member_of=in:foo,bar&member_of=in:baz -- which would turn into (foo OR bar) AND baz | |
| 15:30:41 | dansmith | efried: that would let me have infinite filters that AND together several "any one of these would be fine for this requirement" | |
| 15:30:51 | jaypipes | cfriesen: I'm dead set against "implicit" or "hidden" resources. | |
| 15:31:41 | dansmith | efried: logically "tenant_aggregates AND az_aggregates AND gpu_aggregates AND shared_storage_aggregates" for some fictitious request with all those restrictions | |
| 15:31:52 | eric-young | mriedem, yes, that patch requires an unreleased version of os-brick. Is there a way to instigate a release or just wait? | |
| 15:32:39 | efried | dansmith: Sure, that seems simple-but-powerful. But we still need to address the question of whether to allow a queryparam key to be repeated. We haven't so far. | |
| 15:33:00 | bauzas | jianghuaw_: mriedem: FWIW, I filed a bug with a new 'vgpu' tag | |
| 15:33:05 | efried | cdent, edleafe: In your capacity as API SIGgers, what do you think? | |
| 15:33:06 | dansmith | efried: yeah, but it's a common thing for query strings, which is why we have it as a list right? | |
| 15:33:07 | bauzas | jianghuaw_: mriedem: https://bugs.launchpad.net/nova/+bug/1758086 | |
| 15:33:08 | openstack | Launchpad bug 1758086 in OpenStack Compute (nova) "nvidia driver limits to one single GPU per guest" [Low,Triaged] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 15:33:17 | bauzas | so we could track all VGPU related bugs | |
| 15:33:24 | efried | dansmith: I agree it's a common thing for query strings in general. But we've explicitly avoided doing it in placement so far. | |
| 15:33:34 | cdent | query parameter repetition is expected and normal, which is why under the covers the library return a list of values | |
| 15:33:37 | efried | Meaning you can break the API with that. | |
| 15:33:45 | dansmith | cdent: yeah, that | |
| 15:34:10 | dansmith | this: https://pastebin.com/pbgv9vux | |
| 15:34:33 | efried | Yeah yeah, I know it's supported by HTTP and the tooling. | |
| 15:34:40 | cdent | I'm more worried by what kind of impact this would have on already very challenging for mortals to understand query code | |
| 15:35:08 | cdent | s/query/database query/ | |
| 15:35:39 | efried | dansmith: correct me if I'm wrong, but we can't avoid crossing that bridge *somehow*. | |
| 15:35:58 | dansmith | efried: well, we can by just not doing things :) | |
| 15:36:11 | dansmith | but yeah, if we want it to be more than trivially useful... | |
| 15:36:13 | efried | I mean, we don't _have_ to implement it in a monster JOIN; we can do individual queries and do the set math in python. | |
| 15:36:58 | efried | So cdent/edleafe y'all don't have a problem introducing a repeatable queryparam key, where we've avoided them in the past? | |