| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-26 | |||
| 18:15:49 | efried | dansmith: But I *am* saying the fallback code elsewhere in the file (two places, I think) becomes dead and can be removed. | |
| 18:16:03 | dansmith | jaypipes: who are you agreeing with? | |
| 18:16:08 | jaypipes | dansmith: you. | |
| 18:16:16 | jaypipes | "you opt in ..." | |
| 18:16:18 | dansmith | jaypipes: okay I'm totes confused about where you sit on this then ;) | |
| 18:16:23 | efried | I was agreeing with that too. So everybody agrees. | |
| 18:16:58 | jaypipes | dansmith: I guess my butt hurts from the fence. | |
| 18:18:14 | jaypipes | dansmith: on the one hand I don't want to *always* force users to upgrade placement first when it's not necessary to. on the other hand, I see the futility of operators upgrading nova-scheduler first, placement second and having a time when some requests involving AZs suddenly start failing. | |
| 18:18:56 | jaypipes | dansmith: I was referring to sitting on the fence, there... | |
| 18:19:02 | jaypipes | in case that wasn't obvious ;) | |
| 18:19:08 | sean-k-mooney | jaypipes: well we would only be frocing them to upgrade placement first if they need a placement feature in nova | |
| 18:19:08 | dansmith | jaypipes: yeah, and I also don't think operators are at all complaining about having a clear order of services for upgrades | |
| 18:19:37 | jaypipes | dansmith: ok, then I'm cool with all of this, then. :) | |
| 18:19:46 | jaypipes | carry on. | |
| 18:19:47 | dansmith | aight | |
| 18:19:56 | jaypipes | sorry for being dense. | |
| 18:20:08 | sean-k-mooney | dansmith: well from an install tool poing of view ya most installers would perfer to always have a clear order of operations even if it wasnt strictly required. | |
| 18:20:31 | efried | jaypipes: Ugh, why is maxlength for a RP name 200? (As opposed to 255, like for trait and RC?) | |
| 18:20:43 | dansmith | sean-k-mooney: in the early days of making nova upgrade smoothly, that was the #1 request.. "just tell me which order and I'll do it." | |
| 18:21:03 | jaypipes | efried: UGH. Why would you need an rp name longer than 200 characters. UGH! | |
| 18:21:31 | efried | jaypipes: Sorry, the ugh was because inconsistent with trait/RC. | |
| 18:21:39 | sean-k-mooney | dansmith: i think that is still the case although "keep it running without any downtime magically while i upgrade" may have over taken it | |
| 18:21:48 | jaypipes | efried: no idea | |
| 18:22:19 | efried | cdent: any idea? | |
| 18:23:27 | sean-k-mooney | efried: its saves you half a KB per RP? do you have a reason to have a name over 200 | |
| 18:23:51 | cdent | well, rp name came first, so I reckon it was arbitrary decision at the time and then when custom traits and resource classes came along people expressed concern about wanting to make them super long and 255 some some random compromise. AKA: I don't think there were _reasons_ as such | |
| 18:24:06 | efried | sean-k-mooney: No. I'm writing code to sanitize RP/RC/trait names and the inconsistency is gonna make me write >1 method instead of just 1. | |
| 18:24:47 | sean-k-mooney | efried: or jsut assume make 200 for all names | |
| 18:25:29 | sean-k-mooney | there is no harm in makeing it a 255 lenght however you would need a sql schema update which likely is not worth it for this allow | |
| 18:25:43 | cdent | ? | |
| 18:25:58 | melwitt | tssurya: hey, thanks for bringing up the user_id column in instance_mappings table thing. I agree it should be a separate spec to handle the "quota when cell-down" issue. I have an old spec for it that I can resurrect. my spec will depend on yours because I also need the queued_for_delete column | |
| 18:27:05 | tssurya | melwitt: okay, :) I guess we can co-ordinate on this then, I will let you know as soon as I put up a spec for it then. | |
| 18:27:27 | melwitt | tssurya: cool, thank you :) | |
| 18:27:38 | efried | cdent: Not quite. I was reviewing 520313 which has code that will wind up sending down an RP name that will fail - https://review.openstack.org/#/c/520313/23/nova/tests/unit/virt/xenapi/test_driver.py@443. Letting the API fail in this case will be worse than suboptimal, because by the time that happens, we're outside of where virt can do anything about it. | |
| 18:27:58 | efried | cdent: This isn't the first time I've seen a need for a method to "slugify" a placement identifier, so I thought I would write it. | |
| 18:28:01 | tssurya | melwitt: the only concern I have is that at the PTG, we discussed that we would not use placement and do a solution of allowing the users to create VMs if they don't have any in the down cell | |
| 18:28:07 | cdent | efried: I was teasing | |
| 18:28:12 | cdent | gentle ribbing and all that | |
| 18:28:38 | tssurya | melwitt: however if we are going to use placement, then this changes things i guess | |
| 18:28:38 | melwitt | tssurya: you mean disallowing? | |
| 18:28:47 | efried | cdent: It's a valid concern that you should check me on constantly, even though (or perhaps especially because) you and I fundamentally disagree on whether such pre-optimizations are desirable. | |
| 18:29:02 | efried | cdent: But in this case, it's more than that. | |
| 18:29:08 | tssurya | melwitt: no, I mean allowing VM creation as long as there are no living VMs in the down cell | |
| 18:29:23 | tssurya | melwitt: since in that case the quota calculation will be correct | |
| 18:29:46 | melwitt | tssurya: yeah, that was when we had thought being able to count instances while cells are down would require adding a "type" to placement allocations. that is something that will take a lot of work to figure out | |
| 18:29:50 | sean-k-mooney | efried: maybe just take the lenght as an optional param that you defalt to 255 and the caller can set 200 or what ever if they no its less for that field | |
| 18:29:50 | cdent | Fair enough. I never really said they are not desierable, I suggested that they should wait for the road to show they are needed. | |
| 18:30:46 | tssurya | melwitt: ah okay, so then I will do a spec for queued_for_delete and we can take it from there then | |
| 18:31:33 | melwitt | tssurya: yeah. we had said that because at the time we were thinking to remove the dependency on reading cell databases, we would have to add a "type" to placement allocations and that was not going to be straightforward and needed a lot more time and design | |
| 18:32:17 | tssurya | melwitt: hmm yea now I remember, thanks! | |
| 18:32:26 | melwitt | tssurya: but when I was thinking about it later, if we have queued_for_delete (from your spec) that was the main missing piece preventing us from being able to count instances in the instance_mappings table. the other piece is user_id | |
| 18:33:21 | melwitt | the "queued_for_delete" column was controversial in the past, but now that it's not, it opens that door again | |
| 18:33:38 | tssurya | melwitt: yea I agree, I guess I will go ahead with the queued_for_delete and will leave out the user_id for a separate spec and we (you) can battle out adding the "type" with the placement guys later | |
| 18:33:50 | melwitt | user_id I think is not controversial because we already have project_id, I'm actually not sure why we didn't add user_id too | |
| 18:34:27 | tssurya | melwitt: the reason I was asking for the user_id is because I could do these two in the same spec if you want like dansmith said its one migration | |
| 18:34:48 | melwitt | tssurya: sounds good | |
| 18:35:15 | melwitt | tssurya: yeah, I agree with him that it can be one migration, just two specs where each problem being solved for down cells is described in detail separately | |
| 18:35:23 | melwitt | just so it's easier to organize | |
| 18:36:30 | tssurya | melwitt: cool, I was waiting to get your opinion too, so I will do it in two specs, one for nova-list/service-list when a cell is down, second for quotas when a cell goes down, however I won't touch any from placement | |
| 18:36:39 | tssurya | calculations since you already have a spec | |
| 18:37:45 | melwitt | tssurya: okay, won't that mean we would have three specs then? I was thinking I would just roll the "add user_id column" stuff into the spec I have https://review.openstack.org/#/c/509042 | |
| 18:38:23 | melwitt | and then also add reference to your spec where it depends on your queued_for_delete column | |
| 18:38:35 | tssurya | melwitt: oh yes that's fine with me | |
| 18:38:54 | tssurya | melwitt: so I will do one single spec with queued_for_delete, | |
| 18:39:06 | tssurya | melwitt: sounds good ? | |
| 18:39:11 | melwitt | tssurya: yep sounds good | |
| 18:39:30 | tssurya | melwitt: thank you | |
| 18:40:37 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: Localdisk https://review.openstack.org/549300 | |
| 18:52:11 | openstackgerrit | Dan Smith proposed openstack/nova master: Add aggregates list to Destination object https://review.openstack.org/544729 | |
| 18:52:11 | openstackgerrit | Dan Smith proposed openstack/nova master: Add request filter functionality to scheduler https://review.openstack.org/544730 | |
| 18:52:12 | openstackgerrit | Dan Smith proposed openstack/nova master: Add an index on aggregate_metadata.value https://review.openstack.org/555851 | |
| 18:52:12 | openstackgerrit | Dan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions https://review.openstack.org/547990 | |
| 18:52:13 | openstackgerrit | Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002 | |
| 18:52:13 | openstackgerrit | Dan Smith proposed openstack/nova master: Add AggregateList.get_by_metadata() query method https://review.openstack.org/544728 | |
| 18:52:14 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Honor availability_zone hint via placement https://review.openstack.org/546282 | |
| 19:16:00 | imacdonn | mriedem or toabctl : either of you around ? | |
| 19:19:47 | imacdonn | mriedem toabctl In case you show up while I'm at lunch:) Regarding https://github.com/openstack/nova/commit/3a3b0f09db318faf1a1ea711a73bb365cab8b233 - I think we have the same issue with the "image" service, if glance.api_servers is not configured (which is recommended) | |
| 19:21:54 | imacdonn | efried: your name is on this too :) https://github.com/openstack/nova/blob/master/nova/image/glance.py#L114-L116 | |
| 19:23:03 | mriedem | imacdonn: 'image' is already in that list https://github.com/openstack/nova/commit/3a3b0f09db318faf1a1ea711a73bb365cab8b233#diff-c83f1fae2a677ed29036e293dd0e63caR121 | |
| 19:23:09 | efried | yeah, what he said. | |
| 19:23:19 | mriedem | devstack doesn't set glance.api_servers either | |
| 19:23:47 | imacdonn | oh yeah, I'm blind | |
| 19:23:53 | imacdonn | I wonder why I'm getting this, then... | |
| 19:24:23 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] "interfaces: %s" % interfaces) | |
| 19:24:23 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] File "/usr/lib/python2.7/site-packages/nova/utils.py", line 1373, in get_endpoint | |
| 19:24:23 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] endpoint = utils.get_endpoint(ksa_adap) | |
| 19:24:23 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 126, in get_api_servers | |
| 19:24:27 | imacdonn | 2018-03-26 19:00:54.238 46339 ERROR nova.compute.manager [instance: 41164565-c7a2-4f96-9fcf-222847ecf113] EndpointNotFound: Could not find requested endpoint for any of the following interfaces: ['internal', 'public'] | |
| 19:24:41 | mriedem | i probably know why | |
| 19:24:54 | mriedem | https://review.openstack.org/#/c/554703/ | |
| 19:25:32 | imacdonn | 4 days ago, eh? that seems plausible | |
| 19:26:57 | imacdonn | will have to see if I'm doing something "the old way" ... removed the api_servers option to try to be current :) | |
| 19:27:59 | imacdonn | I guess maybe it's the code, not me ... not using versioned notifications | |
| 19:31:44 | mriedem | this isn't about versioned notifications | |
| 19:31:56 | mriedem | it's about notifications sent during periodic tasks where we don't have a token | |
| 19:32:26 | imacdonn | You comment says "there isn't much the operator can do about it outside of (1) switching entirely to versioned notifications, which not many people are using yet if at all, or ...." | |
| 19:32:27 | openstackgerrit | Eric Fried proposed openstack/nova master: Slugification utilities for placement names https://review.openstack.org/556628 | |
| 19:32:32 | efried | cdent: For nosey parkers ^ | |
| 19:39:35 | openstackgerrit | melanie witt proposed openstack/nova master: Migrate tempest-dsvm-multinode-live-migration job in-tree https://review.openstack.org/555945 | |
| 19:42:29 | openstackgerrit | Eric Fried proposed openstack/nova master: doc: Upgrade placement first https://review.openstack.org/556631 | |