Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-06-05
15:05:06 gtema yeah, so 3 is what we have now out-of-box
15:05:15 gtema 2) is what I am implementing in this stack
15:05:33 mordred yah - but the cloud layer does 1 currently
15:05:40 gtema and for 1) nodepool should then simply do compute.servers() and filter results
15:05:53 mordred yeah - maybe that's the best idea
15:06:03 gtema yes, cloud is doing 1) now
15:06:15 mordred because honestly nodepool is probably the only consumer who actually wants that behavior
15:06:23 gtema yupp
15:06:38 mordred Shrews: ^^ thoughts from you?
15:08:24 mordred gtema: we could probably provide a helper method in sdk for "please list and then filter client side" that has its own name that we could have nodepool use, but that most people would not
15:08:46 gtema yes, that's also possible
15:09:06 mordred I'll poke at nodepool a bit and see
15:09:13 gtema basically right now if we get jsmepath - we do only filter on client side
15:09:37 gtema but yes, let's see
15:10:40 gtema hmm, I think "alias" is not currently working as we would like to
15:11:22 mordred yeah - alias is very confusing
15:11:41 mordred I *think* what alias needs is for there to be another Component defined and alias is pointing to that
15:12:00 gtema right, I remember this also now
15:12:14 mordred which is great when there are two server-side things it could be - but when you just want to provide a second name for a single component it kind of sucks
15:12:27 gtema right
15:12:46 mordred maybe we shoudl add support for the thing we want here? :)
15:12:54 gtema hehehe
15:13:08 mordred oh! nodepool doesn't use filtering at all
15:14:05 mordred the main thing nodepool does is get_server and wait_for_server - it just does _those_ by using list and filtering on name_or_id
15:14:17 mordred so it's a really specific case of client-side filtering
15:14:33 gtema good
15:15:19 mordred yeah- I think we can safely do (2) from above everywhere
15:15:30 gtema yupp
15:15:35 mordred and then we already have a flag in the cloud layer for whether get should use list or get
15:15:59 gtema agreed
15:16:02 mordred maybe we just keep, push support for it into the base resource class, and flip the default (making sure we have nodepool setting it first)
15:16:34 gtema could be
15:16:51 mordred I'll work on that - I don't think it should conflict with your resource layer work
15:17:02 gtema hopefully :D
15:17:05 mordred heheh
15:17:10 gtema I do not want to rebase all those changes
15:17:40 gtema and those were just for compute, the more to come
15:18:00 gtema some time in the far far future in the far galaxy
15:18:28 mordred yah - I don't want you to rebase all those changes either :)
15:18:58 gtema right, I will simply abandon them if someone forces me :D
15:19:46 gtema do we want something like 'access_alias' on the _BaseComponent?
15:22:47 mordred gtema: hahaha. :)
15:22:56 mordred gtema: yeah - maybe so?
15:23:06 mordred gtema: question on https://review.opendev.org/#/c/662724
15:23:37 Shrews mordred: our for an errand now. Can look in a bit
15:23:40 gtema yeah, and this is cool - neutron return both tenant_id and project_id
15:24:00 mordred gtema: "awesome"
15:24:20 gtema and they both are equal
15:24:35 gtema so the change is not breaking anything
15:25:11 mordred nod. I kinda want to say "let's just hide tenant_id" - but I guess that doesn't actually make life better for users
15:25:47 gtema ok, than I would simply need to exclude it from normalization. Anyway I might then thing how to avoid it at all
15:26:02 gtema thing=think
15:26:32 gtema so, what with aliases?
15:27:05 mordred gtema: nah - I mean, ignore me here. I think exposing both tenant_id and project_id is fine if neutron is doing that ... it's only my anti-tenant purism speaking
15:27:26 gtema I do not like it either
15:27:28 mordred with aliases, yeah - I think something like access_alias sounds great - I'm sad the word "alias" is already taken to mean this
15:27:53 gtema I can rename alias to something more meaningful
15:27:55 mordred although there's nothing stopping us from renaming the current alias thing to something else and using the word alias to mean the new thing :)
15:28:07 mordred words are hard
15:28:12 gtema right
15:28:23 gtema the code is better than words
15:28:31 mordred oh - wait ...
15:29:04 mordred what if you just add a new thing to BaseResource - but call it "aka" for also-known-as instead of "access_alias"
15:29:15 gtema :D
15:29:16 mordred (less coding involved, still short names)
15:29:18 gtema that's cool
15:29:36 gtema dtantsur: ^^
15:29:42 mordred Shrews: awesome - thanks
15:30:11 gtema mordred: cool, than do "aka"
15:30:36 gtema and in the "to_dict"-like we would then just show both
15:30:46 gtema is it problem for "strict" mode?
15:31:05 mordred hrm. this is a good question
15:31:25 mordred maybe we should just get rid of strict mode
15:31:36 gtema I vote for that
15:32:02 mordred and yes - then I think for to_dict we just show both
15:32:30 mordred because honestly it doesn't hurt us to have access_ipv4 and accessIPv4 in such a dict
15:32:38 gtema sure
15:33:13 gtema would be however nice somehow to mark in Ansible things - please preffer this name
15:33:52 gtema so that sometime we can simply drop them and not take care of them for ever
15:48:51 mordred gtema, Shrews: remote: https://review.opendev.org/663368 Explicitly set use_direct_get to Fal
15:49:03 mordred there's the nodepool patch to allow us to do the update in sdk
15:49:18 gtema ok, good
15:49:35 openstackgerrit charlie proposed openstack/openstacksdk master: Support deleting all routes in update_router https://review.opendev.org/663369
16:38:02 Shrews mordred: ok, at a proper computer again. you got a tl;dr version for me? that's quite a bit of scrollback
16:38:27 mordred Shrews: MUST READ ALL WORDS
16:38:51 Shrews then my vote is YES to whatever the thing is
16:39:23 mordred Shrews: so - tl;dr - make default behavior in sdk (2) from the list of three things in scrollback
16:39:51 mordred Shrews: and have nodepool pass use_direct_get=False in its Connection constructor - since it's important that it have the different behavior
16:43:32 Shrews ok, i'm just going to have to read the entire sb because i don't see the connection yet
16:45:41 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Push use_direct_get support into resource layer https://review.opendev.org/663379
16:46:32 mordred Shrews, gtema: ^^ something like that (I'm 100% sure that isn't going to fully work - but that's the general idea)
16:46:52 gtema ack
16:47:40 mordred (I think we'll need to flip the default in the same patch - otherwise we're going to start listing in places we weren't - and that's goign to involve a BUNCH of requests_mock changes)
16:57:12 Shrews "oh! nodepool doesn't use filtering at all" <--- yes, this is what was confusing me
16:58:18 Shrews mordred: so if the question is "which of those 3 options sounds best?", then i'm fine with 2. I still don't see any relationship to nodepool and use_direct_get
16:58:36 Shrews because nodepool doesn't use that directly, afaict
16:58:44 mordred Shrews: well, it uses get_server
16:59:13 Shrews and doesn't get_server do the is_uuid_like thing?
16:59:25 mordred which in current behavior does the full list and then filters client-side to find the server by id because use_direct_get is False by default
16:59:36 mordred Shrews: only when use_direct_get is True

Earlier   Later