Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-06-05
14:46:32 mordred well - we can have the resources handle _more_ things than normalize did
14:47:14 gtema but still there would be rename then in the resource layer - backward incompat
14:48:17 gtema having adminPass in resource layer is not something we want
14:50:19 mordred yah - lemme give a quick concrete example
14:50:23 mordred and see what you think
14:50:28 gtema ok
14:51:16 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:46 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:53:45 gtema well, adminPass is just one example, hostId, config_drive vs has_config_drive, all accessIPvX
14:54:25 gtema and then all the complex names like OS-EXT-SRV-ATTR:hypervisor_hostname
14:54:31 mordred here's the first stab I did here: https://review.opendev.org/#/c/630912
14:57:47 gtema yeah, looks interesting. Where "Computed"-ones are calculated?
14:58:17 mordred in the constructor
14:58:43 mordred (get_supplemental_addresses)
14:59:24 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:27 gtema ok, so overload it constructor also to invoke it?
14:59:31 mordred (server is by far the most complicated example here)
14:59:59 gtema ok, got it. Will play around
15:00:22 mordred cool - I'll also review the ones you've got already
15:00:32 gtema cool, thks
15:00:43 mordred gtema: end goal is for the cloud layer to return the same resource objects that the non-cloud layer returns
15:00:54 mordred so that they're essentially interchangable
15:01:15 gtema yeah
15:01:20 mordred oh - another thing (unrelated, but related to stuff you've been hacking on)
15:03:17 mordred the whole "filter client side vs filter server side" - it seems there are 3 different combinations that people might want
15:03:33 mordred 1) only filter client side (nodepool wants this)
15:03:58 mordred 2) filter server side as much as possible then filter anything else client side (what most people want I think)
15:04:40 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:05:05 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: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?

Earlier   Later