Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-06-05
14:29:14 efried mordred: Yes, I am thoroughly excited. Can we get a release?
14:29:48 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:56 efried cool
14:30:35 mordred nope. queue is clear - release forthcoming
14:31:29 efried sweet
14:31:37 efried let me know if you want me to do any of the paperwork, happy to.
14:32:07 mordred remote: https://review.opendev.org/663343 Release 0.30.0 of openstacksdk
14:32:30 gtema this month we have too much releases ;-)
14:34:47 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:36:29 efried mordred: Have you considered putting openstacksdk on an independent release cycle?
14:38:29 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:39 mordred I'm not sure what the original_name thing was about though
14:39:22 gtema yeah, I would also gladly move to "no normalize", but since Ansible is using it we get immediately couple of renamings
14:39:42 gtema i.e. accessIPv4 vs access_ipv4
14:39:56 gtema availability_zone vs az
14:41:09 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:34 mordred of course, maybe we just have it do both things?
14:41:47 gtema ok, thatn I will rework normalize to take everything as is in the resource and add some stuff with older names
14:42:54 gtema does it sound good? But then still this "strict" mode
14:45:36 mordred actually - what if we do this ...
14:45:49 mordred what if we rework the resource to have the same results as normalize in strict mode
14:46:07 gtema hmm
14:46:16 gtema lot of stuff goes under properties
14:46:19 mordred those are the "interface"
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"

Earlier   Later