Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-26
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 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: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: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 melwitt tssurya: you mean disallowing?
18:28:38 tssurya melwitt: however if we are going to use placement, then this changes things i guess
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 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: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: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 request filter functionality to scheduler https://review.openstack.org/544730
18:52:11 openstackgerrit Dan Smith proposed openstack/nova master: Add aggregates list to Destination object https://review.openstack.org/544729
18:52:12 openstackgerrit Dan Smith proposed openstack/nova master: Make get_allocation_candidates() honor aggregate restrictions https://review.openstack.org/547990
18:52:12 openstackgerrit Dan Smith proposed openstack/nova master: Add an index on aggregate_metadata.value https://review.openstack.org/555851
18:52:13 openstackgerrit Dan Smith proposed openstack/nova master: Add AggregateList.get_by_metadata() query method https://review.openstack.org/544728
18:52:13 openstackgerrit Dan Smith proposed openstack/nova master: Add require_tenant_aggregate request filter https://review.openstack.org/545002
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] File "/usr/lib/python2.7/site-packages/nova/image/glance.py", line 126, in get_api_servers
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/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] "interfaces: %s" % interfaces)
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
19:42:40 efried mriedem, jaypipes, dansmith, sean-k-mooney cdent edleafe ^
19:57:06 openstackgerrit Eric Fried proposed openstack/nova master: Get rid of 406 paths in report client https://review.openstack.org/556633
19:57:17 efried mriedem, jaypipes, dansmith, sean-k-mooney cdent edleafe and ^

Earlier   Later