| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-05 | |||
| 16:29:46 | melwitt | efried: yeah, no specific dashboard. just whatever you normally like to use for specs | |
| 16:35:54 | openstackgerrit | Merged openstack/nova master: Fix bug for hypervisors https://review.openstack.org/572063 | |
| 16:36:01 | openstackgerrit | Merged openstack/nova master: Fix bug to doc https://review.openstack.org/572268 | |
| 16:40:59 | mriedem | dansmith: i know i say this every 3 days, but i think stephenfin's numa aware vswitches spec is ready to go https://review.openstack.org/#/c/541290/ | |
| 16:41:56 | efried | We should really have a spec review day so we can merge that thing. | |
| 16:42:21 | dansmith | mriedem: can I skip this one and wait three days until it's ready again? | |
| 16:42:30 | mriedem | no | |
| 16:45:27 | dansmith | damn | |
| 16:48:02 | dansmith | I feel like the proof is in the code anyway and I'm out of steam on the spec | |
| 16:48:08 | dansmith | so, damn the torpedoes | |
| 16:49:02 | mriedem | yeah i already went through the code series this morning and made notes on the patches about what needs to change | |
| 16:49:04 | mriedem | at a high level | |
| 16:52:55 | openstackgerrit | Merged openstack/nova stable/queens: Allow cinderv2 endpoints within the request context catalog https://review.openstack.org/572213 | |
| 16:56:54 | openstackgerrit | Merged openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290 | |
| 17:10:24 | efried | bhagyashri_s: Greate work on https://review.openstack.org/#/c/560459/ -- just a couple of minor things and I think it's ready to go. I'm going to have to let other cores (probably bauzas and jaypipes) approve it, since I contributed to the fix. | |
| 17:31:13 | openstackgerrit | Chris Friesen proposed openstack/nova-specs master: Add support for emulated virtual TPM https://review.openstack.org/571111 | |
| 17:45:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: mention that you can't re-parent a resource provider https://review.openstack.org/572501 | |
| 18:18:04 | openstackgerrit | Dan Smith proposed openstack/nova master: Change consecutive build failure limit to a weigher https://review.openstack.org/572195 | |
| 18:55:50 | mriedem | dansmith: melwitt: tssurya: on the handling a down cell spec, https://review.openstack.org/#/c/557369/ - i'm thinking that if the user is filtering or paging while listing instances, we need to ignore down cells | |
| 18:55:57 | mriedem | because we can't provide accurate results in that case | |
| 18:56:23 | mriedem | not that we're providing much in the way of results with just a flat 'nova list', but at least it's a dump of all instances (under the default limit) with minimal fields specified | |
| 18:56:56 | dansmith | you mean sorting? | |
| 18:56:56 | melwitt | yeah, either that or do the minimal shell of an instance thing for those in down cells | |
| 18:57:02 | tssurya | mriedem: yes makes sense, | |
| 18:57:08 | mriedem | dansmith: no, filtering | |
| 18:57:19 | dansmith | if they're sorting we can't really show the shells, | |
| 18:57:20 | dansmith | since we don't know what the sort key value is | |
| 18:57:21 | mriedem | sorting kind of goes out the window as well | |
| 18:57:21 | dansmith | same for filtering I guess | |
| 18:57:40 | mriedem | melwitt: the minimal shell is the problem when filtering | |
| 18:57:46 | tssurya | if its the default sorting, I think it uses created_at, | |
| 18:57:55 | mriedem | if i'm doing 'nova list --status PAUSED', don't show me 4 PAUSED instances and 100 UNKNOWN instances | |
| 18:57:55 | melwitt | oh | |
| 18:58:00 | melwitt | yeah | |
| 18:58:02 | dansmith | right | |
| 18:58:15 | mriedem | if i do: nova list --all-tenants | |
| 18:58:19 | mriedem | then sure, give me the dump | |
| 18:59:00 | mriedem | tssurya: yes by default we sort by created_at in desc order https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py#L143 | |
| 18:59:07 | mriedem | which we can achieve with the instance mappings records | |
| 18:59:15 | tssurya | mriedem: yes | |
| 18:59:38 | mriedem | if i'm sorting by status and i have UNKNOWN minimals, then i guess those just get sorted too | |
| 18:59:43 | tssurya | so let's just support simple and plain nova list and if any additional arguments are specified, we give 500 ? | |
| 19:00:04 | tssurya | so that its consistent | |
| 19:00:19 | mriedem | no, i'm saying if there are filter parameters, we do what we can with the cells that respond, but ignore the ones that dont | |
| 19:00:47 | mriedem | i honestly don't know how this is going to be used in all cases, or what's really needed | |
| 19:01:03 | tssurya | right, | |
| 19:01:13 | mriedem | like, does the caller need some indication that there are down cells? if so, would returning a new header help with that? | |
| 19:01:18 | mriedem | but a non-admin user shouldn't know there are down cells | |
| 19:01:46 | dansmith | I think the most important thing is to avoid a 500 when there's a down cell, | |
| 19:01:52 | dansmith | the more info we can return the better, | |
| 19:02:16 | dansmith | but even if we skip everything in a down cell, that's incremental progress, then returning shells when they wouldn't be otherwise filtered out is progress on top of that, etc | |
| 19:02:46 | mriedem | agree, and i think the first part of that could be done as a bug fix and backported | |
| 19:02:55 | dansmith | yep | |
| 19:03:01 | tssurya | users shouldn't know anything about cells, however in order to avoid 500, if like mriedem said about filters, -> i.e to still process output from up cells, it would be inconsistent right ? | |
| 19:03:07 | tssurya | I mean not the right results | |
| 19:03:40 | mriedem | if i'm a user and i get instances back with just a bunch of UNKNOWN values, i'm goign to know my instance is in a down cell | |
| 19:03:55 | tssurya | yes this is if its plain nova list, | |
| 19:04:16 | tssurya | if we do this with nova list --status PAUSED then ? | |
| 19:04:43 | tssurya | like you said above, if we display results only from up cells and ignore down ones, it means we are missing stuff | |
| 19:04:55 | tssurya | we will not be showing any UNKNOWNS there right ? | |
| 19:04:57 | mriedem | i don't know of a better way to say "don't know" w/o just not including those results | |
| 19:05:01 | dansmith | if an instance is in a down cell, its state is UNKNOWN, | |
| 19:05:13 | dansmith | so if you asked for PAUSED, then UNKNOWN is not matching the filter | |
| 19:05:54 | tssurya | okay not status I mean other filters | |
| 19:06:01 | tssurya | like --marker | |
| 19:06:26 | dansmith | if you get a marker to an instance that is in a cell that goes down between pages, then you have to fail | |
| 19:06:31 | tssurya | I guess what I am trying to say is at some point we can't avoid a 500 ? | |
| 19:06:52 | tssurya | okay, yes | |
| 19:06:53 | dansmith | if you know an instance provided as a marker is in a down cell, then a 500 is appropriate | |
| 19:07:18 | dansmith | that might be the only case though.. are there others you think warrant a 500? | |
| 19:07:22 | mriedem | i don't know if we'd 400 on that today or not | |
| 19:07:30 | mriedem | usually we'd get marker not found and return a 400 | |
| 19:07:37 | dansmith | right, but that would be wrong here | |
| 19:07:44 | dansmith | because we know it exists, we just can't get to it | |
| 19:08:14 | tssurya | --availability-zone, like matt was saying in the spec ? | |
| 19:08:19 | dansmith | that would be similar to 503 Proxy Error | |
| 19:08:46 | dansmith | if you're just filtering by az, then you return shells for the things in there right? | |
| 19:08:58 | mgagne | mriedem: currently trying to deploy queens, ++ for policy deprecation warnings. grrrreatly appreciated. | |
| 19:09:35 | tssurya | dansmith: I honestly don't know at this point | |
| 19:09:46 | mriedem | mgagne: thank johnthetubaguy and gmann for those | |
| 19:10:33 | tssurya | dansmith: I will try to go through all the nova list args and see | |
| 19:10:50 | dansmith | tssurya: I think you probably will just have to consider the appropriate behavior for each | |
| 19:10:52 | mgagne | johnthetubaguy, gmann: I greatly appreciate the work you have done with policy deprecation warnings. it's of great help when upgrading ++ | |
| 19:11:02 | dansmith | for most, shell instances or omission is the best idea I think, | |
| 19:11:05 | mriedem | i assume that filtering on az would be the same as status - we can't know, so ignore those results in a down cell | |
| 19:11:07 | dansmith | 500 for marker | |
| 19:11:15 | tssurya | dansmith: ack, | |
| 19:11:31 | dansmith | mriedem: oh right, duh, I forgot we couldn't know the instances in there | |
| 19:11:41 | dansmith | mriedem: we know hosts and instances in hosts, so we could work it out I guess | |
| 19:12:04 | mriedem | i don't think we know instances in hosts from the api | |
| 19:12:10 | dansmith | er, no | |
| 19:12:13 | dansmith | right | |
| 19:12:46 | dansmith | I was thinking instance->cell->host->az, but that's not fine-grained enough | |
| 19:12:52 | dansmith | obvi | |
| 19:12:55 | tssurya | mriedem: right so we print one shell for the down cell and print the results from the rest | |
| 19:13:06 | tssurya | this way users can know that the result is not fully right | |
| 19:13:17 | dansmith | hmm? | |
| 19:13:23 | dansmith | one shell per down cell? | |
| 19:13:39 | dansmith | I think you just have to leave out all shells for instances you can't tell are in an az | |
| 19:13:51 | tssurya | dansmith: oh okay | |