| *** slaweq has quit IRC | 00:03 | |
| *** slaweq has joined #openstack-sdks | 00:23 | |
| *** slaweq has quit IRC | 00:33 | |
| *** slaweq has joined #openstack-sdks | 00:51 | |
| *** slaweq has quit IRC | 01:03 | |
| *** slaweq has joined #openstack-sdks | 01:21 | |
| *** slaweq has quit IRC | 01:33 | |
| *** slaweq has joined #openstack-sdks | 01:54 | |
| *** dave-mccowan has quit IRC | 02:02 | |
| *** slaweq has quit IRC | 02:03 | |
| *** slaweq has joined #openstack-sdks | 02:14 | |
| *** slaweq has quit IRC | 02:25 | |
| *** Dinesh_Bhor has quit IRC | 02:37 | |
| *** slaweq has joined #openstack-sdks | 02:41 | |
| *** slaweq has quit IRC | 02:54 | |
| *** markvoelker has joined #openstack-sdks | 02:59 | |
| *** slaweq has joined #openstack-sdks | 03:15 | |
| *** Dinesh_Bhor has joined #openstack-sdks | 03:19 | |
| openstackgerrit | Merged openstack/python-openstackclient master: Compute: Add description support for server https://review.opendev.org/568549 | 03:25 |
|---|---|---|
| *** slaweq has quit IRC | 03:26 | |
| *** markvoelker has quit IRC | 03:30 | |
| *** slaweq has joined #openstack-sdks | 03:42 | |
| *** slaweq has quit IRC | 03:55 | |
| *** ricolin has joined #openstack-sdks | 03:58 | |
| *** slaweq has joined #openstack-sdks | 04:12 | |
| *** gmann has quit IRC | 04:23 | |
| *** slaweq has quit IRC | 04:25 | |
| *** markvoelker has joined #openstack-sdks | 04:27 | |
| *** gmann has joined #openstack-sdks | 04:27 | |
| *** markvoelker has quit IRC | 05:00 | |
| *** slaweq has joined #openstack-sdks | 05:02 | |
| *** markvoelker has joined #openstack-sdks | 05:56 | |
| *** markvoelker has quit IRC | 06:28 | |
| *** dtantsur|afk is now known as dtantsur\ | 06:29 | |
| *** dtantsur\ is now known as dtantsur | 06:29 | |
| *** e0ne has joined #openstack-sdks | 06:31 | |
| *** ITD27M01_ has joined #openstack-sdks | 06:54 | |
| *** gtema has joined #openstack-sdks | 07:08 | |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use Resource layer in cloud for SecurityGroups of server https://review.opendev.org/662998 | 07:12 |
| *** e0ne has quit IRC | 07:15 | |
| *** yolanda has joined #openstack-sdks | 07:15 | |
| *** ttsiouts has joined #openstack-sdks | 07:27 | |
| *** holser_ has joined #openstack-sdks | 07:31 | |
| *** gtema has quit IRC | 07:32 | |
| *** ttsiouts has quit IRC | 07:37 | |
| *** whoami-rajat has joined #openstack-sdks | 07:45 | |
| openstackgerrit | Merged openstack/openstacksdk master: Make factory for a CloudRegion from CONF objects https://review.opendev.org/643601 | 07:50 |
| *** ralonsoh has joined #openstack-sdks | 07:51 | |
| *** jpena|off is now known as jpena | 07:56 | |
| *** ttsiouts has joined #openstack-sdks | 08:02 | |
| openstackgerrit | Merged openstack/openstacksdk master: Support Proxy-specific region_name https://review.opendev.org/662865 | 08:05 |
| openstackgerrit | Merged openstack/openstacksdk master: Get rid of unused _OpenStackCloudMixin.get_region https://review.opendev.org/663038 | 08:08 |
| *** markvoelker has joined #openstack-sdks | 08:26 | |
| *** gtema has joined #openstack-sdks | 08:36 | |
| *** openstackgerrit has quit IRC | 08:47 | |
| *** markvoelker has quit IRC | 08:59 | |
| *** e0ne has joined #openstack-sdks | 09:30 | |
| *** openstackgerrit has joined #openstack-sdks | 09:55 | |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use Resource layer for next compute methods https://review.opendev.org/663064 | 09:55 |
| *** markvoelker has joined #openstack-sdks | 09:57 | |
| *** holser_ is now known as holser|lunch | 09:57 | |
| openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Use resource layer for compute flavors https://review.opendev.org/650903 | 10:05 |
| *** ttsiouts has quit IRC | 10:15 | |
| *** ttsiouts has joined #openstack-sdks | 10:16 | |
| *** ttsiouts has quit IRC | 10:20 | |
| *** dave-mccowan has joined #openstack-sdks | 10:26 | |
| *** markvoelker has quit IRC | 10:29 | |
| *** stingrayza has quit IRC | 10:30 | |
| *** stingrayza has joined #openstack-sdks | 10:32 | |
| *** gtema has quit IRC | 10:39 | |
| *** gtema has joined #openstack-sdks | 10:40 | |
| *** ricolin has quit IRC | 10:47 | |
| *** holser|lunch is now known as holser_ | 10:49 | |
| *** ttsiouts has joined #openstack-sdks | 11:03 | |
| *** jpena is now known as jpena|lunch | 11:07 | |
| *** adriant has quit IRC | 11:12 | |
| *** ITD27M01_ has quit IRC | 11:17 | |
| gtema | mordred: what was you planning to to with server normalization? I can't really get your TODO in cloud._compute._list_servers | 11:20 |
| gtema | https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/cloud/_compute.py#L361 | 11:22 |
| *** markvoelker has joined #openstack-sdks | 11:26 | |
| *** ttsiouts has quit IRC | 11:31 | |
| *** ttsiouts has joined #openstack-sdks | 11:32 | |
| *** ttsiouts has quit IRC | 11:36 | |
| *** yolanda has quit IRC | 11:48 | |
| *** markvoelker has quit IRC | 12:00 | |
| *** jpena|lunch is now known as jpena | 12:01 | |
| *** gmann has quit IRC | 12:03 | |
| *** ricolin has joined #openstack-sdks | 12:03 | |
| *** stingrayza has quit IRC | 12:06 | |
| *** stingrayza has joined #openstack-sdks | 12:08 | |
| *** ttsiouts has joined #openstack-sdks | 12:10 | |
| *** adriant has joined #openstack-sdks | 12:34 | |
| *** adriant has quit IRC | 12:43 | |
| *** adriant has joined #openstack-sdks | 12:46 | |
| *** ttsiouts has quit IRC | 13:01 | |
| *** ttsiouts has joined #openstack-sdks | 13:01 | |
| *** ttsiouts has quit IRC | 13:05 | |
| *** ttsiouts has joined #openstack-sdks | 13:22 | |
| *** gtema has quit IRC | 13:31 | |
| *** bobh has joined #openstack-sdks | 13:47 | |
| *** bobh has quit IRC | 13:50 | |
| mordred | efried: \o/ patch landed | 14:28 |
| *** gtema has joined #openstack-sdks | 14:29 | |
| efried | mordred: Yes, I am thoroughly excited. Can we get a release? | 14:29 |
| mordred | we can - let me check the queue and see if there's anything else we should land real quick - but I think the next thing up is gtema's stack which is a whole new thing | 14:29 |
| efried | cool | 14:29 |
| mordred | nope. queue is clear - release forthcoming | 14:30 |
| efried | sweet | 14:31 |
| efried | let me know if you want me to do any of the paperwork, happy to. | 14:31 |
| mordred | remote: https://review.opendev.org/663343 Release 0.30.0 of openstacksdk | 14:32 |
| gtema | this month we have too much releases ;-) | 14:32 |
| gtema | mordred: was asking your earlier today - what is our plan to do with _normalize_server thing? This is the "only" thing remaining for the resource layer of compute | 14:34 |
| efried | mordred: Have you considered putting openstacksdk on an independent release cycle? | 14:36 |
| mordred | gtema: yeah - I'm not 100% sure what my original intent in that comment was ... but the original intent was to get the resource updated so that we don't need the normalize method anymore | 14:38 |
| mordred | I'm not sure what the original_name thing was about though | 14:38 |
| gtema | yeah, I would also gladly move to "no normalize", but since Ansible is using it we get immediately couple of renamings | 14:39 |
| gtema | i.e. accessIPv4 vs access_ipv4 | 14:39 |
| gtema | availability_zone vs az | 14:39 |
| mordred | yah. we'd need to make sure the resource objects are at least returning the names the cloud layer is currently - since that's the one things we know about are consuming and is more of an api we've committed to | 14:41 |
| mordred | of course, maybe we just have it do both things? | 14:41 |
| gtema | ok, thatn I will rework normalize to take everything as is in the resource and add some stuff with older names | 14:41 |
| gtema | does it sound good? But then still this "strict" mode | 14:42 |
| mordred | actually - what if we do this ... | 14:45 |
| mordred | what if we rework the resource to have the same results as normalize in strict mode | 14:45 |
| gtema | hmm | 14:46 |
| gtema | lot of stuff goes under properties | 14:46 |
| mordred | those are the "interface" | 14:46 |
| mordred | well - we can have the resources handle _more_ things than normalize did | 14:46 |
| gtema | but still there would be rename then in the resource layer - backward incompat | 14:47 |
| gtema | having adminPass in resource layer is not something we want | 14:48 |
| mordred | yah - lemme give a quick concrete example | 14:50 |
| mordred | and see what you think | 14:50 |
| gtema | ok | 14:50 |
| mordred | (also, it just occurred to me - maybe we should have a CreatedServer resource object which is a subclass of Server but also has adminPass - and is just returned from create_server | 14:51 |
| mordred | because that adminPass is important in that moment, but you're right- it's kind of wrong for it to be there normally | 14:51 |
| gtema | well, adminPass is just one example, hostId, config_drive vs has_config_drive, all accessIPvX | 14:53 |
| gtema | and then all the complex names like OS-EXT-SRV-ATTR:hypervisor_hostname | 14:54 |
| mordred | here's the first stab I did here: https://review.opendev.org/#/c/630912 | 14:54 |
| gtema | yeah, looks interesting. Where "Computed"-ones are calculated? | 14:57 |
| mordred | in the constructor | 14:58 |
| mordred | (get_supplemental_addresses) | 14:58 |
| mordred | but the idea being basically we do everything we can with normal resource attribute mappings - and for the things now in normalize that we just cant' do in resource attributes directly, we can always do in a constructor or something | 14:59 |
| gtema | ok, so overload it constructor also to invoke it? | 14:59 |
| mordred | (server is by far the most complicated example here) | 14:59 |
| gtema | ok, got it. Will play around | 14:59 |
| mordred | cool - I'll also review the ones you've got already | 15:00 |
| gtema | cool, thks | 15:00 |
| mordred | gtema: end goal is for the cloud layer to return the same resource objects that the non-cloud layer returns | 15:00 |
| mordred | so that they're essentially interchangable | 15:00 |
| gtema | yeah | 15:01 |
| mordred | oh - another thing (unrelated, but related to stuff you've been hacking on) | 15:01 |
| mordred | the whole "filter client side vs filter server side" - it seems there are 3 different combinations that people might want | 15:03 |
| mordred | 1) only filter client side (nodepool wants this) | 15:03 |
| mordred | 2) filter server side as much as possible then filter anything else client side (what most people want I think) | 15:03 |
| mordred | 3) only filter server side and thrown an error if someone tries to filter on something that can only be filtered client-side (some people in the past have indicated they want this) | 15:04 |
| mordred | should we have maybe more than one method so people can pick their behavior? or a standard behavior flag someone can pass? | 15:05 |
| gtema | yeah, so 3 is what we have now out-of-box | 15:05 |
| gtema | 2) is what I am implementing in this stack | 15:05 |
| mordred | yah - but the cloud layer does 1 currently | 15:05 |
| gtema | and for 1) nodepool should then simply do compute.servers() and filter results | 15:05 |
| mordred | yeah - maybe that's the best idea | 15:05 |
| gtema | yes, cloud is doing 1) now | 15:06 |
| mordred | because honestly nodepool is probably the only consumer who actually wants that behavior | 15:06 |
| gtema | yupp | 15:06 |
| mordred | Shrews: ^^ thoughts from you? | 15:06 |
| 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 |
| gtema | yes, that's also possible | 15:08 |
| mordred | I'll poke at nodepool a bit and see | 15:09 |
| gtema | basically right now if we get jsmepath - we do only filter on client side | 15:09 |
| gtema | but yes, let's see | 15:09 |
| gtema | hmm, I think "alias" is not currently working as we would like to | 15:10 |
| mordred | yeah - alias is very confusing | 15:11 |
| mordred | I *think* what alias needs is for there to be another Component defined and alias is pointing to that | 15:11 |
| gtema | right, I remember this also now | 15:12 |
| 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 |
| gtema | right | 15:12 |
| mordred | maybe we shoudl add support for the thing we want here? :) | 15:12 |
| gtema | hehehe | 15:12 |
| mordred | oh! nodepool doesn't use filtering at all | 15:13 |
| 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 |
| mordred | so it's a really specific case of client-side filtering | 15:14 |
| gtema | good | 15:14 |
| mordred | yeah- I think we can safely do (2) from above everywhere | 15:15 |
| gtema | yupp | 15:15 |
| mordred | and then we already have a flag in the cloud layer for whether get should use list or get | 15:15 |
| gtema | agreed | 15:15 |
| 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 |
| gtema | could be | 15:16 |
| mordred | I'll work on that - I don't think it should conflict with your resource layer work | 15:16 |
| gtema | hopefully :D | 15:17 |
| mordred | heheh | 15:17 |
| gtema | I do not want to rebase all those changes | 15:17 |
| gtema | and those were just for compute, the more to come | 15:17 |
| gtema | some time in the far far future in the far galaxy | 15:18 |
| mordred | yah - I don't want you to rebase all those changes either :) | 15:18 |
| gtema | right, I will simply abandon them if someone forces me :D | 15:18 |
| gtema | do we want something like 'access_alias' on the _BaseComponent? | 15:19 |
| mordred | gtema: hahaha. :) | 15:22 |
| mordred | gtema: yeah - maybe so? | 15:22 |
| mordred | gtema: question on https://review.opendev.org/#/c/662724 | 15:23 |
| Shrews | mordred: our for an errand now. Can look in a bit | 15:23 |
| gtema | yeah, and this is cool - neutron return both tenant_id and project_id | 15:23 |
| mordred | gtema: "awesome" | 15:24 |
| gtema | and they both are equal | 15:24 |
| gtema | so the change is not breaking anything | 15:24 |
| 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 |
| gtema | ok, than I would simply need to exclude it from normalization. Anyway I might then thing how to avoid it at all | 15:25 |
| gtema | thing=think | 15:26 |
| gtema | so, what with aliases? | 15:26 |
| *** yolanda has joined #openstack-sdks | 15:26 | |
| 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 |
| gtema | I do not like it either | 15:27 |
| 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 |
| gtema | I can rename alias to something more meaningful | 15:27 |
| 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:27 |
| mordred | words are hard | 15:28 |
| gtema | right | 15:28 |
| gtema | the code is better than words | 15:28 |
| mordred | oh - wait ... | 15:28 |
| 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 |
| gtema | :D | 15:29 |
| mordred | (less coding involved, still short names) | 15:29 |
| gtema | that's cool | 15:29 |
| gtema | dtantsur: ^^ | 15:29 |
| mordred | Shrews: awesome - thanks | 15:29 |
| gtema | mordred: cool, than do "aka" | 15:30 |
| gtema | and in the "to_dict"-like we would then just show both | 15:30 |
| gtema | is it problem for "strict" mode? | 15:30 |
| mordred | hrm. this is a good question | 15:31 |
| mordred | maybe we should just get rid of strict mode | 15:31 |
| gtema | I vote for that | 15:31 |
| mordred | and yes - then I think for to_dict we just show both | 15:32 |
| mordred | because honestly it doesn't hurt us to have access_ipv4 and accessIPv4 in such a dict | 15:32 |
| gtema | sure | 15:32 |
| *** ttsiouts has quit IRC | 15:32 | |
| gtema | would be however nice somehow to mark in Ansible things - please preffer this name | 15:33 |
| *** ttsiouts has joined #openstack-sdks | 15:33 | |
| gtema | so that sometime we can simply drop them and not take care of them for ever | 15:33 |
| *** ttsiouts has quit IRC | 15:38 | |
| mordred | gtema, Shrews: remote: https://review.opendev.org/663368 Explicitly set use_direct_get to Fal | 15:48 |
| mordred | there's the nodepool patch to allow us to do the update in sdk | 15:49 |
| gtema | ok, good | 15:49 |
| openstackgerrit | charlie proposed openstack/openstacksdk master: Support deleting all routes in update_router https://review.opendev.org/663369 | 15:49 |
| *** Qiming has quit IRC | 15:54 | |
| *** Qiming has joined #openstack-sdks | 15:58 | |
| *** dtantsur is now known as dtantsur|afk | 16:01 | |
| *** markvoelker has joined #openstack-sdks | 16:04 | |
| 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 |
| mordred | Shrews: MUST READ ALL WORDS | 16:38 |
| Shrews | then my vote is YES to whatever the thing is | 16:38 |
| mordred | Shrews: so - tl;dr - make default behavior in sdk (2) from the list of three things in scrollback | 16:39 |
| 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:39 |
| Shrews | ok, i'm just going to have to read the entire sb because i don't see the connection yet | 16:43 |
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Push use_direct_get support into resource layer https://review.opendev.org/663379 | 16:45 |
| 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 |
| gtema | ack | 16:46 |
| 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:47 |
| *** e0ne has quit IRC | 16:53 | |
| Shrews | "oh! nodepool doesn't use filtering at all" <--- yes, this is what was confusing me | 16:57 |
| 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 |
| Shrews | because nodepool doesn't use that directly, afaict | 16:58 |
| mordred | Shrews: well, it uses get_server | 16:58 |
| Shrews | and doesn't get_server do the is_uuid_like thing? | 16:59 |
| 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 |
| mordred | Shrews: only when use_direct_get is True | 16:59 |
| *** holser_ has quit IRC | 17:00 | |
| 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:01 |
| 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 |
| mordred | Shrews: but before we do that, we need to make nodepool explicitly set the behavior it wants | 17:02 |
| Shrews | ah ha! switching the default is the piece i was missing | 17:02 |
| gtema | mordred, Shrews, what is the use_case of nodepool? is id known or could it be name? | 17:02 |
| mordred | we know the id | 17:02 |
| gtema | then _get will immediately get it | 17:03 |
| mordred | but we dont want to make get calls because we might thousands of outstanding servers we're getting status on | 17:03 |
| gtema | and not do any listing AFAIK | 17:03 |
| Shrews | mordred: i mean, switching the default behavior seems like an API break | 17:03 |
| gtema | find will try to get and do list if not found, but not the 'get' | 17:04 |
| 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 |
| gtema | ah, you mean there. Got it | 17:04 |
| 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:04 |
| mordred | otherwise cloud operators really hate us | 17:05 |
| gtema | yupp | 17:05 |
| 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:06 |
| Shrews | mordred: where does nodepool filter servers? I don't see that anywhere | 17:07 |
| mordred | Shrews: it doesn't - it uses wait_for_server | 17:07 |
| mordred | Shrews: wait_for_server itself uses get_server | 17:08 |
| gtema | ok, leaving you on that note. CU tomorrow | 17:08 |
| mordred | have fun | 17:09 |
| gtema | thks | 17:09 |
| mordred | which does filter_list / get_entity on search_servers | 17:09 |
| Shrews | oh, for some reason i was thinking of a different form of filtering. | 17:10 |
| Shrews | well, flipping the behavior is your call as PTL. Easy enough to change for nodepool | 17:10 |
| Shrews | it would be nice behavior, i agree | 17:11 |
| Shrews | mordred: +2'd the nodepool change | 17:12 |
| mordred | \o/ | 17:13 |
| *** gtema has quit IRC | 17:13 | |
| *** jpena is now known as jpena|off | 17:13 | |
| *** ralonsoh has quit IRC | 17:28 | |
| *** e0ne has joined #openstack-sdks | 18:20 | |
| *** dulek has quit IRC | 18:37 | |
| *** ricolin has quit IRC | 18:41 | |
| *** dulek has joined #openstack-sdks | 18:45 | |
| openstackgerrit | Brian Haley proposed openstack/python-openstackclient master: Support IPv6 addresses better https://review.opendev.org/524420 | 18:54 |
| *** slaweq has quit IRC | 19:47 | |
| *** slaweq has joined #openstack-sdks | 19:47 | |
| efried | mordred: Do we not defer message format interpolation in logging in openstacksdk? | 20:13 |
| mordred | efried: well - I mean, that's the intent - that doesn't mean we always do it | 20:13 |
| efried | okay, I'll keep looking for examples. The one I happend to land on first, doesn't. | 20:14 |
| efried | self.log.debug( | 20:14 |
| efried | "Turning off SSL warnings for {full_name}" | 20:14 |
| efried | " since verify=False".format(full_name=self.full_name)) | 20:14 |
| mordred | yeah - it's entirely possible there are more places like that | 20:14 |
| efried | mordred: I am unsatisfied with the current handling of "You've got a section called [foo] but when I try to load Adapter opts from it, I get an exception." | 20:37 |
| efried | For example, I am able to trigger this code path in the following two ways: | 20:39 |
| efried | (1) Register the [foo] group, but don't register ksa adapter opts in it | 20:39 |
| efried | (2) Register [foo] and register ksa adapter opts in it, but f up the settings | 20:39 |
| efried | For (1) I think we should make the Connection refuse to talk to foo.service_type | 20:39 |
| efried | ...but otherwise that shouldn't be an exception. | 20:39 |
| mordred | agree | 20:40 |
| efried | For (2) I think we should let the exception raise. | 20:40 |
| mordred | yes - but we should be sure to provide good errors when we do | 20:40 |
| efried | Today, for both paths, we allow the Connection with default adapter settings. | 20:40 |
| efried | That seems... not good. | 20:40 |
| efried | I would be able to manage this, but hamstrung by the fact that we don't want to import oslo.config on the prod side. | 20:41 |
| efried | Options: | 20:41 |
| mordred | we can import it behind protection | 20:42 |
| efried | 1) import oslo.config in from_conf | 20:42 |
| efried | because if you're using from_conf presumably you've got it installed somewhere | 20:42 |
| efried | 2) string scrape exception class.__name__ or similar (ew) | 20:42 |
| mordred | yup! and it should be fine to import it there - or even just a try import block at top | 20:42 |
| mordred | nah - I think it's totally fine to import oslo.config for the purposes of from_conf - we just dont' want people who are using sdk for ansible playbooks to need to install oslo.config | 20:43 |
| efried | okay, I'll go with it. Thanks | 20:43 |
| efried | um, one more thing | 20:43 |
| efried | How do I prevent Connection? | 20:43 |
| efried | for a given service? | 20:43 |
| mordred | sure thing! also - we should maybe consider triggering an attempted auth or something in from_conf - since we otherwise only create the adapters on-demand (for things like OSC) - but I imagine in nova getting the error earlier rather than later would be better | 20:44 |
| *** dave-mccowan has quit IRC | 20:44 | |
| mordred | efried: that's a great question ... we have a has_{service} structure so that config can assert that we don't have a service - but it's not plumbed in to the Connection/adapter code | 20:45 |
| mordred | now that you mention it - it should be :) | 20:45 |
| mordred | I can make a patch for that | 20:45 |
| efried | mordred: My dumb approach would be to make ConnectionMeta.__new__ return None if not any(key.startswith(service_type + '_') for key in self.config) | 20:48 |
| efried | ...but only if we came from_conf | 20:48 |
| mordred | efried: so - in Connection, we have has_service which does: if not self.config.config.get('has_%s' % service_key, True): - which we use in other places | 20:49 |
| mordred | I'm thinking perhaps codify that a little bit, add a has_service on CloudRegion, then in from_conf we can add an else condition on if project_name not in conf: which sets has_{service_type} to false for that service type | 20:50 |
| efried | o, so dumb second iteration, ConnectionMeta.__new__ returns None if not has_service(service_type) ? | 20:50 |
| mordred | then in __new__ ... yeah, does that ^^ | 20:51 |
| mordred | that way it's a broadly applicable flag people can use to fully disable something if they need to for whatever reason | 20:51 |
| mordred | (although as a followup we could get fancy and return an object that throws an exception in its __getattr__) | 20:52 |
| efried | yeah, was just thinking that | 20:52 |
| mordred | because "None object has no attribute servers" is always a crappy error message | 20:52 |
| efried | yeah | 20:52 |
| efried | fancier, make the exception message describe why we disabled the service | 20:53 |
| mordred | yeah! | 20:53 |
| efried | I'm getting all woozy just thinking about it. | 20:53 |
| mordred | even fancier - make the exception install the service for you | 20:53 |
| efried | wait, that's what we have today | 20:53 |
| efried | more or less | 20:53 |
| mordred | "you tried to use barbican, which was not enabled, so I installed barbican on some vms and registered them with your keystone catalog for you" | 20:53 |
| efried | heh | 20:54 |
| mordred | wcpgw? | 20:54 |
| efried | So I think what I want is a CloudRegion._disable_service(service_type, reason=None) | 20:54 |
| mordred | yeah | 20:54 |
| mordred | totally | 20:55 |
| efried | or maybe that's in Connection. | 20:55 |
| efried | and I guess in the from_conf branch of Connection, I parse the config and call _disable_service for any service that I didn't register | 20:55 |
| efried | or are you saying adding has_${service_type}=False in the config will give me all of that? | 20:56 |
| efried | cause yeah, sure would prefer to do the work from from_conf | 20:57 |
| efried | except ExceptionsFromOsloConfig as e: | 20:59 |
| efried | log.warning("Disabling service %s because %s", st, e) | 20:59 |
| efried | opt_dict['has_' + st] = False | 20:59 |
| efried | opt_dict[st + '_disabled_reason'] = "Encountered an exception trying to process ksa configs: %s" % e | 20:59 |
| efried | mordred: can you make it so I can do that ^ and everything else will magically come together? | 21:00 |
| mordred | efried: yes. well - I'm saying adding has_{service_type}=False SHOULD give you all of that | 21:00 |
| mordred | and yes - I'll work on that patch | 21:00 |
| efried | noyce. | 21:00 |
| efried | I was going through dtantsur|afk's comments, thinking I could submit a small and simple fup patch | 21:00 |
| efried | and here we are. | 21:01 |
| efried | I'll try to go through the *rest* of the comments and see what else shakes out. | 21:01 |
| mordred | efried: unfortunately (or fortunately, depending on optimism or pessimism) dtantsur|afk is very good at leaving important comments | 21:05 |
| efried | mordred: Well, I knew we had a hole there; he just reminded me by suggesting we log something in that space. | 21:06 |
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Swap default of use_direct_get https://review.opendev.org/663429 | 21:06 |
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: WIP Plumb service disabling into Connection adapters https://review.opendev.org/663435 | 21:23 |
| mordred | efried: something like that ^^ | 21:23 |
| mordred | efried: work still needed, but I think that's mostly what would be needed for what we need in from_conf | 21:23 |
| efried | mordred: I'll have the test cases up in a sec... | 21:23 |
| mordred | sweet | 21:23 |
| mordred | efried: if we don't watch out - this whole this is going to become viable | 21:24 |
| mordred | then what will we be able to complain about? | 21:24 |
| efried | oh, I have faith | 21:24 |
| openstackgerrit | Eric Fried proposed openstack/openstacksdk master: (Broken) from_conf test paths for oslo.config exceptions https://review.opendev.org/663439 | 21:30 |
| efried | mordred: see how that grabs ya ^ | 21:31 |
| mordred | sweet | 21:31 |
| efried | I'm going to put those two in series and try to put a fix on top. | 21:33 |
| mordred | that's exciting | 21:34 |
| efried | it's scary, but somewhat liberating [1], to be throwing all these patches around without tracking bugs/stories against them | 21:35 |
| efried | [1] like I imagine skydiving to be | 21:35 |
| efried | mordred: If instead of raising right away, we just disable service for both cases (1) and (2) listed above, I can get away without importing oslo.config... | 21:38 |
| mordred | efried: oh neat. then we could just do the "raise a useful error instead of None" patch - and further improvements can be around providing better/earlier errors | 21:40 |
| efried | yuh | 21:40 |
| *** gmann has joined #openstack-sdks | 21:45 | |
| *** dave-mccowan has joined #openstack-sdks | 21:47 | |
| *** slaweq has quit IRC | 21:52 | |
| *** whoami-rajat has quit IRC | 22:00 | |
| *** adriant has quit IRC | 22:01 | |
| *** adriant has joined #openstack-sdks | 22:02 | |
| *** slaweq has joined #openstack-sdks | 22:02 | |
| openstackgerrit | Eric Fried proposed openstack/openstacksdk master: WIP Plumb service disabling into Connection adapters https://review.opendev.org/663435 | 22:03 |
| openstackgerrit | Eric Fried proposed openstack/openstacksdk master: Disable service on exception in from_conf https://review.opendev.org/663449 | 22:03 |
| efried | mordred: thar she blows. Works like a charm. | 22:03 |
| efried | mordred: I did a little refactoring of your pieces in there (which could probably be done in your patch instead of mine, but whatever) | 22:04 |
| *** slaweq has quit IRC | 22:08 | |
| *** e0ne has quit IRC | 22:13 | |
| mordred | efried: \o/ | 22:21 |
| efried | mordred: I'm working on the "better exception" thing. | 22:21 |
| efried | mordred: Not sure if you'll want different/additional testing from what I'm doing. | 22:21 |
| mordred | I'm sure what you're doing is perfect | 22:22 |
| efried | oh, I'm sure. | 22:22 |
| openstackgerrit | Eric Fried proposed openstack/openstacksdk master: Show a pretty reason when service is disabled https://review.opendev.org/663453 | 22:25 |
| efried | mordred: ^ | 22:26 |
| mordred | efried: dude, that's so cool | 22:27 |
| efried | :) | 22:27 |
| efried | mordred: Hm, if you're feeling generous, it's possible we could consider the testing in the top two patches as sufficient for your otherwise-WIP. | 22:33 |
| efried | so like, squash or reorganize and we're done? | 22:34 |
| mordred | efried: yah - honestly, I think that's probably right. you have a sec to do that squash? (maybe pick the change-id from one of your changes, since those were the "point" of the work) | 22:35 |
| efried | yeah, you want me to just squash them all into one? | 22:36 |
| mordred | yeah - why not - I think it might be easier to understand as one big one | 22:37 |
| efried | on it | 22:38 |
| efried | gosh, I thought I was going to have a really long commit message, but from the pov of a single patch, it's fairly simple :) | 22:41 |
| openstackgerrit | Eric Fried proposed openstack/openstacksdk master: Handle oslo.config exceptions in from_conf https://review.opendev.org/663439 | 22:46 |
| efried | mordred: blayum | 22:46 |
| mordred | efried: that's actually a pretty nice looking patch | 22:48 |
| efried | Yeah, it came together pretty nicely when squashed | 22:48 |
| efried | mordred: I want to make a couple of little tweaks (noted inline), but I should call it a night. Feel free to fix it up if you like. | 22:49 |
| mordred | efried: coolio. and yeah - it's about time for that for me too | 22:50 |
| *** dave-mccowan has quit IRC | 22:56 | |
| *** slaweq has joined #openstack-sdks | 23:48 | |
| *** bobh has joined #openstack-sdks | 23:56 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!