Wednesday, 2019-06-05

*** slaweq has quit IRC00:03
*** slaweq has joined #openstack-sdks00:23
*** slaweq has quit IRC00:33
*** slaweq has joined #openstack-sdks00:51
*** slaweq has quit IRC01:03
*** slaweq has joined #openstack-sdks01:21
*** slaweq has quit IRC01:33
*** slaweq has joined #openstack-sdks01:54
*** dave-mccowan has quit IRC02:02
*** slaweq has quit IRC02:03
*** slaweq has joined #openstack-sdks02:14
*** slaweq has quit IRC02:25
*** Dinesh_Bhor has quit IRC02:37
*** slaweq has joined #openstack-sdks02:41
*** slaweq has quit IRC02:54
*** markvoelker has joined #openstack-sdks02:59
*** slaweq has joined #openstack-sdks03:15
*** Dinesh_Bhor has joined #openstack-sdks03:19
openstackgerritMerged openstack/python-openstackclient master: Compute: Add description support for server
*** slaweq has quit IRC03:26
*** markvoelker has quit IRC03:30
*** slaweq has joined #openstack-sdks03:42
*** slaweq has quit IRC03:55
*** ricolin has joined #openstack-sdks03:58
*** slaweq has joined #openstack-sdks04:12
*** gmann has quit IRC04:23
*** slaweq has quit IRC04:25
*** markvoelker has joined #openstack-sdks04:27
*** gmann has joined #openstack-sdks04:27
*** markvoelker has quit IRC05:00
*** slaweq has joined #openstack-sdks05:02
*** markvoelker has joined #openstack-sdks05:56
*** markvoelker has quit IRC06:28
*** dtantsur|afk is now known as dtantsur\06:29
*** dtantsur\ is now known as dtantsur06:29
*** e0ne has joined #openstack-sdks06:31
*** ITD27M01_ has joined #openstack-sdks06:54
*** gtema has joined #openstack-sdks07:08
openstackgerritArtem Goncharov proposed openstack/openstacksdk master: Use Resource layer in cloud for SecurityGroups of server
*** e0ne has quit IRC07:15
*** yolanda has joined #openstack-sdks07:15
*** ttsiouts has joined #openstack-sdks07:27
*** holser_ has joined #openstack-sdks07:31
*** gtema has quit IRC07:32
*** ttsiouts has quit IRC07:37
*** whoami-rajat has joined #openstack-sdks07:45
openstackgerritMerged openstack/openstacksdk master: Make factory for a CloudRegion from CONF objects
*** ralonsoh has joined #openstack-sdks07:51
*** jpena|off is now known as jpena07:56
*** ttsiouts has joined #openstack-sdks08:02
openstackgerritMerged openstack/openstacksdk master: Support Proxy-specific region_name
openstackgerritMerged openstack/openstacksdk master: Get rid of unused _OpenStackCloudMixin.get_region
*** markvoelker has joined #openstack-sdks08:26
*** gtema has joined #openstack-sdks08:36
*** openstackgerrit has quit IRC08:47
*** markvoelker has quit IRC08:59
*** e0ne has joined #openstack-sdks09:30
*** openstackgerrit has joined #openstack-sdks09:55
openstackgerritArtem Goncharov proposed openstack/openstacksdk master: Use Resource layer for next compute methods
*** markvoelker has joined #openstack-sdks09:57
*** holser_ is now known as holser|lunch09:57
openstackgerritArtem Goncharov proposed openstack/openstacksdk master: Use resource layer for compute flavors
*** ttsiouts has quit IRC10:15
*** ttsiouts has joined #openstack-sdks10:16
*** ttsiouts has quit IRC10:20
*** dave-mccowan has joined #openstack-sdks10:26
*** markvoelker has quit IRC10:29
*** stingrayza has quit IRC10:30
*** stingrayza has joined #openstack-sdks10:32
*** gtema has quit IRC10:39
*** gtema has joined #openstack-sdks10:40
*** ricolin has quit IRC10:47
*** holser|lunch is now known as holser_10:49
*** ttsiouts has joined #openstack-sdks11:03
*** jpena is now known as jpena|lunch11:07
*** adriant has quit IRC11:12
*** ITD27M01_ has quit IRC11:17
gtemamordred: what was you planning to to with server normalization? I can't really get your TODO in cloud._compute._list_servers11:20
*** markvoelker has joined #openstack-sdks11:26
*** ttsiouts has quit IRC11:31
*** ttsiouts has joined #openstack-sdks11:32
*** ttsiouts has quit IRC11:36
*** yolanda has quit IRC11:48
*** markvoelker has quit IRC12:00
*** jpena|lunch is now known as jpena12:01
*** gmann has quit IRC12:03
*** ricolin has joined #openstack-sdks12:03
*** stingrayza has quit IRC12:06
*** stingrayza has joined #openstack-sdks12:08
*** ttsiouts has joined #openstack-sdks12:10
*** adriant has joined #openstack-sdks12:34
*** adriant has quit IRC12:43
*** adriant has joined #openstack-sdks12:46
*** ttsiouts has quit IRC13:01
*** ttsiouts has joined #openstack-sdks13:01
*** ttsiouts has quit IRC13:05
*** ttsiouts has joined #openstack-sdks13:22
*** gtema has quit IRC13:31
*** bobh has joined #openstack-sdks13:47
*** bobh has quit IRC13:50
mordredefried: \o/ patch landed14:28
*** gtema has joined #openstack-sdks14:29
efriedmordred: Yes, I am thoroughly excited. Can we get a release?14:29
mordredwe 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 thing14:29
mordrednope. queue is clear - release forthcoming14:30
efriedlet me know if you want me to do any of the paperwork, happy to.14:31
mordredremote: Release 0.30.0 of openstacksdk14:32
gtemathis month we have too much releases ;-)14:32
gtemamordred: 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 compute14:34
efriedmordred: Have you considered putting openstacksdk on an independent release cycle?14:36
mordredgtema: 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 anymore14:38
mordredI'm not sure what the original_name thing was about though14:38
gtemayeah, I would also gladly move to "no normalize", but since Ansible is using it we get immediately couple of renamings14:39
gtemai.e. accessIPv4 vs access_ipv414:39
gtemaavailability_zone vs az14:39
mordredyah. 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 to14:41
mordredof course, maybe we just have it do both things?14:41
gtemaok, thatn I will rework normalize to take everything as is in the resource and add some stuff with older names14:41
gtemadoes it sound good? But then still this "strict" mode14:42
mordredactually - what if we do this ...14:45
mordredwhat if we rework the resource to have the same results as normalize in strict mode14:45
gtemalot of stuff goes under properties14:46
mordredthose are the "interface"14:46
mordredwell - we can have the resources handle _more_ things than normalize did14:46
gtemabut still there would be rename then in the resource layer - backward incompat14:47
gtemahaving adminPass in resource layer is not something we want14:48
mordredyah - lemme give a quick concrete example14:50
mordredand see what you think14: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_server14:51
mordredbecause that adminPass is important in that moment, but you're right- it's kind of wrong for it to be there normally14:51
gtemawell, adminPass is just one example, hostId, config_drive vs has_config_drive, all accessIPvX14:53
gtemaand then all the complex names like OS-EXT-SRV-ATTR:hypervisor_hostname14:54
mordredhere's the first stab I did here:
gtemayeah, looks interesting. Where "Computed"-ones are calculated?14:57
mordredin the constructor14:58
mordredbut 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 something14:59
gtemaok, so overload it constructor also to invoke it?14:59
mordred(server is by far the most complicated example here)14:59
gtemaok, got it. Will play around14:59
mordredcool - I'll also review the ones you've got already15:00
gtemacool, thks15:00
mordredgtema: end goal is for the cloud layer to return the same resource objects that the non-cloud layer returns15:00
mordredso that they're essentially interchangable15:00
mordredoh - another thing (unrelated, but related to stuff you've been hacking on)15:01
mordredthe whole "filter client side vs filter server side" - it seems there are 3 different combinations that people might want15:03
mordred1) only filter client side (nodepool wants this)15:03
mordred2) filter server side as much as possible then filter anything else client side (what most people want I think)15:03
mordred3) 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
mordredshould we have maybe more than one method so people can pick their behavior? or a standard behavior flag someone can pass?15:05
gtemayeah, so 3 is what we have now out-of-box15:05
gtema2) is what I am implementing in this stack15:05
mordredyah - but the cloud layer does 1 currently15:05
gtemaand for 1) nodepool should then simply do compute.servers() and filter results15:05
mordredyeah - maybe that's the best idea15:05
gtemayes, cloud is doing 1) now15:06
mordredbecause honestly nodepool is probably the only consumer who actually wants that behavior15:06
mordredShrews: ^^ thoughts from you?15:06
mordredgtema: 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 not15:08
gtemayes, that's also possible15:08
mordredI'll poke at nodepool a bit and see15:09
gtemabasically right now if we get jsmepath - we do only filter on client side15:09
gtemabut yes, let's see15:09
gtemahmm, I think "alias" is not currently working as we would like to15:10
mordredyeah - alias is very confusing15:11
mordredI *think* what alias needs is for there to be another Component defined and alias is pointing to that15:11
gtemaright, I remember this also now15:12
mordredwhich 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 sucks15:12
mordredmaybe we shoudl add support for the thing we want here? :)15:12
mordredoh! nodepool doesn't use filtering at all15:13
mordredthe main thing nodepool does is get_server and wait_for_server - it just does _those_ by using list and filtering on name_or_id15:14
mordredso it's a really specific case of client-side filtering15:14
mordredyeah- I think we can safely do (2) from above everywhere15:15
mordredand then we already have a flag in the cloud layer for whether get should use list or get15:15
mordredmaybe 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
gtemacould be15:16
mordredI'll work on that - I don't think it should conflict with your resource layer work15:16
gtemahopefully :D15:17
gtemaI do not want to rebase all those changes15:17
gtemaand those were just for compute, the more to come15:17
gtemasome time in the far far future in the far galaxy15:18
mordredyah - I don't want you to rebase all those changes either :)15:18
gtemaright, I will simply abandon them if someone forces me :D15:18
gtemado we want something like 'access_alias' on the _BaseComponent?15:19
mordredgtema: hahaha. :)15:22
mordredgtema: yeah - maybe so?15:22
mordredgtema: question on
Shrewsmordred: our for an errand now. Can look in a bit15:23
gtemayeah, and this is cool - neutron return both tenant_id and project_id15:23
mordredgtema: "awesome"15:24
gtemaand they both are equal15:24
gtemaso the change is not breaking anything15:24
mordrednod. I kinda want to say "let's just hide tenant_id" - but I guess that doesn't actually make life better for users15:25
gtemaok, than I would simply need to exclude it from normalization. Anyway I might then thing how to avoid it at all15:25
gtemaso, what with aliases?15:26
*** yolanda has joined #openstack-sdks15:26
mordredgtema: 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 speaking15:27
gtemaI do not like it either15:27
mordredwith aliases, yeah - I think something like access_alias sounds great - I'm sad the word "alias" is already taken to mean this15:27
gtemaI can rename alias to something more meaningful15:27
mordredalthough 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
mordredwords are hard15:28
gtemathe code is better than words15:28
mordredoh - wait ...15:28
mordredwhat if you just add a new thing to BaseResource - but call it "aka" for also-known-as instead of "access_alias"15:29
mordred(less coding involved, still short names)15:29
gtemathat's cool15:29
gtemadtantsur: ^^15:29
mordredShrews: awesome - thanks15:29
gtemamordred: cool, than do "aka"15:30
gtemaand in the "to_dict"-like we would then just show both15:30
gtemais it problem for "strict" mode?15:30
mordredhrm. this is a good question15:31
mordredmaybe we should just get rid of strict mode15:31
gtemaI vote for that15:31
mordredand yes - then I think for to_dict we just show both15:32
mordredbecause honestly it doesn't hurt us to have access_ipv4 and accessIPv4 in such a dict15:32
*** ttsiouts has quit IRC15:32
gtemawould be however nice somehow to mark in Ansible things - please preffer this name15:33
*** ttsiouts has joined #openstack-sdks15:33
gtemaso that sometime we can simply drop them and not take care of them for ever15:33
*** ttsiouts has quit IRC15:38
mordredgtema, Shrews: remote: Explicitly set use_direct_get to Fal15:48
mordredthere's the nodepool patch to allow us to do the update in sdk15:49
gtemaok, good15:49
openstackgerritcharlie proposed openstack/openstacksdk master: Support deleting all routes in update_router
*** Qiming has quit IRC15:54
*** Qiming has joined #openstack-sdks15:58
*** dtantsur is now known as dtantsur|afk16:01
*** markvoelker has joined #openstack-sdks16:04
Shrewsmordred: ok, at a proper computer again. you got a tl;dr version for me? that's quite a bit of scrollback16:38
mordredShrews: MUST READ ALL WORDS16:38
Shrewsthen my vote is YES to whatever the thing is16:38
mordredShrews: so - tl;dr - make default behavior in sdk (2) from the list of three things in scrollback16:39
mordredShrews: and have nodepool pass use_direct_get=False in its Connection constructor - since it's important that it have the different behavior16:39
Shrewsok, i'm just going to have to read the entire sb because i don't see the connection yet16:43
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Push use_direct_get support into resource layer
mordredShrews, gtema: ^^ something like that (I'm 100% sure that isn't going to fully work - but that's the general idea)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 IRC16:53
Shrews"oh! nodepool doesn't use filtering at all"   <---   yes, this is what was confusing me16:57
Shrewsmordred: 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_get16:58
Shrewsbecause nodepool doesn't use that directly, afaict16:58
mordredShrews: well, it uses get_server16:58
Shrewsand doesn't get_server do the is_uuid_like thing?16:59
mordredwhich 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 default16:59
mordredShrews: only when use_direct_get is True16:59
*** holser_ has quit IRC17:00
Shrewsmordred: 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
mordredShrews: 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 grumpy17:02
mordredShrews: but before we do that, we need to make nodepool explicitly set the behavior it wants17:02
Shrewsah ha! switching the default is the piece i was missing17:02
gtemamordred, Shrews, what is the use_case of nodepool? is id known or could it be name?17:02
mordredwe know the id17:02
gtemathen _get will immediately get it17:03
mordredbut we dont want to make get calls because we might thousands of outstanding servers we're getting status on17:03
gtemaand not do any listing AFAIK17:03
Shrewsmordred: i mean, switching the default behavior seems like an API break17:03
gtemafind will try to get and do list if not found, but not the 'get'17:04
mordredgtema: 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 nodepool17:04
gtemaah, you mean there. Got it17:04
mordredbecause 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 thread17:04
mordredotherwise cloud operators really hate us17:05
mordredShrews: 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 behavior17:06
Shrewsmordred: where does nodepool filter servers? I don't see that anywhere17:07
mordredShrews: it doesn't - it uses wait_for_server17:07
mordredShrews: wait_for_server itself uses get_server17:08
gtemaok, leaving you on that note. CU tomorrow17:08
mordredhave fun17:09
mordredwhich does filter_list / get_entity on search_servers17:09
Shrewsoh, for some reason i was thinking of a different form of filtering.17:10
Shrewswell, flipping the behavior is your call as PTL. Easy enough to change for nodepool17:10
Shrewsit would be nice behavior, i agree17:11
Shrewsmordred: +2'd the nodepool change17:12
*** gtema has quit IRC17:13
*** jpena is now known as jpena|off17:13
*** ralonsoh has quit IRC17:28
*** e0ne has joined #openstack-sdks18:20
*** dulek has quit IRC18:37
*** ricolin has quit IRC18:41
*** dulek has joined #openstack-sdks18:45
openstackgerritBrian Haley proposed openstack/python-openstackclient master: Support IPv6 addresses better
*** slaweq has quit IRC19:47
*** slaweq has joined #openstack-sdks19:47
efriedmordred: Do we not defer message format interpolation in logging in openstacksdk?20:13
mordredefried: well - I mean, that's the intent - that doesn't mean we always do it20:13
efriedokay, 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
mordredyeah - it's entirely possible there are more places like that20:14
efriedmordred: 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
efriedFor 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 it20:39
efried(2) Register [foo] and register ksa adapter opts in it, but f up the settings20:39
efriedFor (1) I think we should make the Connection refuse to talk to foo.service_type20:39
efried...but otherwise that shouldn't be an exception.20:39
efriedFor (2) I think we should let the exception raise.20:40
mordredyes - but we should be sure to provide good errors when we do20:40
efriedToday, for both paths, we allow the Connection with default adapter settings.20:40
efriedThat seems... not good.20:40
efriedI 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
mordredwe can import it behind protection20:42
efried1) import oslo.config in from_conf20:42
efriedbecause if you're using from_conf presumably you've got it installed somewhere20:42
efried2) string scrape exception class.__name__ or similar (ew)20:42
mordredyup! and it should be fine to import it there - or even just a try import block at top20:42
mordrednah - 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.config20:43
efriedokay, I'll go with it. Thanks20:43
efriedum, one more thing20:43
efriedHow do I prevent Connection?20:43
efriedfor a given service?20:43
mordredsure 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 better20:44
*** dave-mccowan has quit IRC20:44
mordredefried: 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 code20:45
mordrednow that you mention it - it should be :)20:45
mordredI can make a patch for that20:45
efriedmordred: 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_conf20:48
mordredefried: 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 places20:49
mordredI'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 type20:50
efriedo, so dumb second iteration, ConnectionMeta.__new__ returns None if not has_service(service_type) ?20:50
mordredthen in __new__ ... yeah, does that ^^20:51
mordredthat way it's a broadly applicable flag people can use to fully disable something if they need to for whatever reason20:51
mordred(although as a followup we could get fancy and return an object that throws an exception in its __getattr__)20:52
efriedyeah, was just thinking that20:52
mordredbecause "None object has no attribute servers" is always a crappy error message20:52
efriedfancier, make the exception message describe why we disabled the service20:53
efriedI'm getting all woozy just thinking about it.20:53
mordredeven fancier - make the exception install the service for you20:53
efriedwait, that's what we have today20:53
efriedmore or less20: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
efriedSo I think what I want is a CloudRegion._disable_service(service_type, reason=None)20:54
efriedor maybe that's in Connection.20:55
efriedand I guess in the from_conf branch of Connection, I parse the config and call _disable_service for any service that I didn't register20:55
efriedor are you saying adding has_${service_type}=False in the config will give me all of that?20:56
efriedcause yeah, sure would prefer to do the work from from_conf20:57
efriedexcept ExceptionsFromOsloConfig as e:20:59
efried    log.warning("Disabling service %s because %s", st, e)20:59
efried    opt_dict['has_' + st] = False20:59
efried    opt_dict[st + '_disabled_reason'] = "Encountered an exception trying to process ksa configs: %s" % e20:59
efriedmordred: can you make it so I can do that ^ and everything else will magically come together?21:00
mordredefried: yes. well - I'm saying adding has_{service_type}=False SHOULD give you all of that21:00
mordredand yes - I'll work on that patch21:00
efriedI was going through dtantsur|afk's comments, thinking I could submit a small and simple fup patch21:00
efriedand here we are.21:01
efriedI'll try to go through the *rest* of the comments and see what else shakes out.21:01
mordredefried: unfortunately (or fortunately, depending on optimism or pessimism) dtantsur|afk is very good at leaving important comments21:05
efriedmordred: Well, I knew we had a hole there; he just reminded me by suggesting we log something in that space.21:06
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Swap default of use_direct_get
openstackgerritMonty Taylor proposed openstack/openstacksdk master: WIP Plumb service disabling into Connection adapters
mordredefried: something like that ^^21:23
mordredefried: work still needed, but I think that's mostly what would be needed for what we need in from_conf21:23
efriedmordred: I'll have the test cases up in a sec...21:23
mordredefried: if we don't watch out - this whole this is going to become viable21:24
mordredthen what will we be able to complain about?21:24
efriedoh, I have faith21:24
openstackgerritEric Fried proposed openstack/openstacksdk master: (Broken) from_conf test paths for oslo.config exceptions
efriedmordred: see how that grabs ya ^21:31
efriedI'm going to put those two in series and try to put a fix on top.21:33
mordredthat's exciting21:34
efriedit's scary, but somewhat liberating [1], to be throwing all these patches around without tracking bugs/stories against them21:35
efried[1] like I imagine skydiving to be21:35
efriedmordred: 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
mordredefried: 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 errors21:40
*** gmann has joined #openstack-sdks21:45
*** dave-mccowan has joined #openstack-sdks21:47
*** slaweq has quit IRC21:52
*** whoami-rajat has quit IRC22:00
*** adriant has quit IRC22:01
*** adriant has joined #openstack-sdks22:02
*** slaweq has joined #openstack-sdks22:02
openstackgerritEric Fried proposed openstack/openstacksdk master: WIP Plumb service disabling into Connection adapters
openstackgerritEric Fried proposed openstack/openstacksdk master: Disable service on exception in from_conf
efriedmordred: thar she blows. Works like a charm.22:03
efriedmordred: 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 IRC22:08
*** e0ne has quit IRC22:13
mordredefried: \o/22:21
efriedmordred: I'm working on the "better exception" thing.22:21
efriedmordred: Not sure if you'll want different/additional testing from what I'm doing.22:21
mordredI'm sure what you're doing is perfect22:22
efriedoh, I'm sure.22:22
openstackgerritEric Fried proposed openstack/openstacksdk master: Show a pretty reason when service is disabled
efriedmordred: ^22:26
mordredefried: dude, that's so cool22:27
efriedmordred: 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
efriedso like, squash or reorganize and we're done?22:34
mordredefried: 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
efriedyeah, you want me to just squash them all into one?22:36
mordredyeah - why not - I think it might be easier to understand as one big one22:37
efriedon it22:38
efriedgosh, 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
openstackgerritEric Fried proposed openstack/openstacksdk master: Handle oslo.config exceptions in from_conf
efriedmordred: blayum22:46
mordredefried: that's actually a pretty nice looking patch22:48
efriedYeah, it came together pretty nicely when squashed22:48
efriedmordred: 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
mordredefried: coolio. and yeah - it's about time for that for me too22:50
*** dave-mccowan has quit IRC22:56
*** slaweq has joined #openstack-sdks23:48
*** bobh has joined #openstack-sdks23:56

Generated by 2.15.3 by Marius Gedminas - find it at!