| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-05 | |||
| 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 | |
| 19:13:56 | tssurya | that wfm as well | |
| 19:14:05 | mriedem | would be helpful if we weren't talking about CLI UX wrt REST API semantics | |
| 19:15:20 | mriedem | would we ignore down cells if we're paging? let's say i've got 3 cells, A, B and C. my marker is in A, B is down, but C is up, so i get some instances from A, skip B and get the rest of the page from C with a new marker in C? | |
| 19:15:47 | dansmith | if you're doing no sort or filter, you could show B instances too | |
| 19:15:52 | dansmith | if you are, then you have to skip | |
| 19:17:18 | mriedem | ok posted some edge case stuff in the spec | |
| 19:17:46 | tssurya | mriedem: thanks, will have a look | |
| 19:17:49 | mriedem | also, i'm annoyed that i feel the need to qualify "edge case" lately as "not computers at the edge of a network, but rare scenarios" | |
| 19:18:04 | dansmith | heh | |
| 19:18:04 | tssurya | so we are going for a new API response ? | |
| 19:18:14 | melwitt | MFIN EDGE | |
| 19:18:16 | mriedem | tssurya: doesn't sound like it | |
| 19:18:49 | tssurya | and since we were on the topic of markers, I have this bug https://bugs.launchpad.net/nova/+bug/1773945 | |
| 19:18:50 | openstack | Launchpad bug 1773945 in OpenStack Compute (nova) "nova client servers.list crashes with bad marker" [Undecided,New] - Assigned to Surya Seetharaman (tssurya) | |
| 19:18:55 | tssurya | couldn't figure out what the issue is | |
| 19:19:10 | tssurya | if any of you have ideas | |
| 19:19:54 | mriedem | i saw something really weird the other day with markers | |
| 19:19:57 | mriedem | with osc | |
| 19:20:03 | mriedem | which uses nova python API bindings | |
| 19:20:26 | tssurya | oh | |
| 19:20:56 | mriedem | i was creating some instances when rabbitmq dropped | |
| 19:21:19 | mriedem | and i think it might have been what takashi said in the bug report, "if the record of the marker VM instance exists in the cell | |
| 19:21:19 | mriedem | but the 'cell_mapping' in the InstanceMapping of the marker VM instance is null (None), | |
| 19:21:19 | mriedem | the issue occurs." | |
| 19:21:54 | tssurya | but this would happen only during schedule time right ? | |
| 19:22:04 | tssurya | I thought takashi was right too at first | |
| 19:22:07 | mriedem | rabbit died during scheduling | |
| 19:22:26 | tssurya | ah :D | |
| 19:22:39 | mriedem | the weird thing is when i was debugging the CLI, it was passing a marker | |
| 19:22:46 | mriedem | and i don't know where that marker was coming from | |
| 19:22:58 | dansmith | tssurya: is that bug not just that the marker gets deleted during the paging? | |
| 19:23:21 | dansmith | oh, no, we do read_deleted=yes it | |
| 19:23:29 | tssurya | yea | |
| 19:24:04 | dansmith | so maybe we should check if the marker has a null cell mapping and log that case/ | |
| 19:24:10 | dansmith | either way, not much we can do there | |
| 19:24:29 | tssurya | dansmith: yep I agree, | |
| 19:24:53 | tssurya | I just never thought there would be case without any BuildRequest and NULL InstanceMapping | |
| 19:25:09 | dansmith | or, we just scan every cell! (no not really) | |
| 19:27:06 | tssurya | dansmith: I also wanted to ask another thing about have a new option --cell-name to nova service-list ; how you would feel about this, but we could also do this in tomorrow's cells meeting if you are busy now | |
| 19:27:29 | dansmith | tssurya: I don't want that, no | |
| 19:27:46 | dansmith | tssurya: put them in an aggregate and have a way to list via aggregate or something | |
| 19:28:01 | tssurya | right I thought so :), just tried my luck :D | |
| 19:28:04 | dansmith | or use nova-manage | |
| 19:28:33 | tssurya | yep, thanks! | |
| 19:29:47 | dansmith | gdi, why does zuul hate me? | |
| 19:30:09 | mriedem | tssurya: so this should only be called if the client passes in a marker https://github.com/openstack/nova/blob/f902e0d5d87fb05207e4a7aca73d185775d43df2/nova/compute/instance_list.py#L56-L73 | |
| 19:30:27 | mriedem | which when i ran openstack --debug service list, i saw it was passing a marker, but i wasn't | |
| 19:30:33 | tssurya | mriedem: yes | |