Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-06-05
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
17:01:20 Shrews mordred: sorry, brain is not working i guess. so why do we need to set use_direct_get=False in nodepool if that's the default?
17:02:02 mordred Shrews: ah - because we want to swap the default in sdk because for most people filtering a list locally is much less efficient and they get grumpy
17:02:12 mordred Shrews: but before we do that, we need to make nodepool explicitly set the behavior it wants
17:02:31 Shrews ah ha! switching the default is the piece i was missing
17:02:35 gtema mordred, Shrews, what is the use_case of nodepool? is id known or could it be name?
17:02:46 mordred we know the id
17:03:01 gtema then _get will immediately get it
17:03:07 mordred but we dont want to make get calls because we might thousands of outstanding servers we're getting status on
17:03:13 gtema and not do any listing AFAIK
17:03:16 Shrews mordred: i mean, switching the default behavior seems like an API break
17:04:10 gtema find will try to get and do list if not found, but not the 'get'
17:04:13 mordred gtema: in the resource layer, as things are currently written, that is right. but in the cloud layer, get_server will filter the list - which is what we want in nodepool
17:04:28 gtema ah, you mean there. Got it
17:04:55 mordred because in nodepool what we want is to do one list call shared by all thousand threads that are trying to launch a server in paralell, and then filter that list in each thread
17:05:09 mordred otherwise cloud operators really hate us
17:05:12 gtema yupp
17:06:03 mordred Shrews: yes - I think it is - but I think it's a behavior change that would more closely match expectations of casual users. I'd be willing to bet money that nobody _other_ than nodepool is relying on the filtered-list behavior
17:07:31 Shrews mordred: where does nodepool filter servers? I don't see that anywhere
17:07:47 mordred Shrews: it doesn't - it uses wait_for_server
17:08:44 mordred Shrews: wait_for_server itself uses get_server
17:08:59 gtema ok, leaving you on that note. CU tomorrow
17:09:04 mordred have fun
17:09:09 gtema thks
17:09:12 mordred which does filter_list / get_entity on search_servers
17:10:26 Shrews oh, for some reason i was thinking of a different form of filtering.
17:10:58 Shrews well, flipping the behavior is your call as PTL. Easy enough to change for nodepool
17:11:40 Shrews it would be nice behavior, i agree
17:12:54 Shrews mordred: +2'd the nodepool change
17:13:26 mordred \o/
18:54:56 openstackgerrit Brian Haley proposed openstack/python-openstackclient master: Support IPv6 addresses better https://review.opendev.org/524420
20:13:23 efried mordred: Do we not defer message format interpolation in logging in openstacksdk?
20:13:47 mordred efried: well - I mean, that's the intent - that doesn't mean we always do it
20:14:08 efried okay, I'll keep looking for examples. The one I happend to land on first, doesn't.
20:14:21 efried " since verify=False".format(full_name=self.full_name))
20:14:21 efried "Turning off SSL warnings for {full_name}"
20:14:21 efried self.log.debug(

Earlier   Later