Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-10-16
13:41:32 mordred Shrews: yeah - or at least to be able to see if there are any problem children
13:42:04 mordred Shrews: also, from poking at this, in theory we could add dstat and stackviz to the unittests base job and wire it up such that we always produce the report for all stestr-based jobs
13:42:14 mordred but that, of course, is out of scope of this patch :)
13:43:38 Shrews k k
14:06:01 openstackgerrit Monty Taylor proposed openstack-infra/shade master: Decouple OpenStackCloud from Connection https://review.openstack.org/610981
14:06:06 mordred Shrews: ^^ there ya go
14:12:29 samueldmq what's the typical error code when quota is not enough?
14:13:26 mordred Shrews, dtantsur, samueldmq: was thinking, as you can likely see, that clarkb was right and that making shade.OpenStackCloud subclass from openstack.Connection may have been a mistake. Instead, just freezing shade at its current point in time so that shade users can happily not get messed with
14:13:35 mordred samueldmq: oh golly - no clue :)
14:14:13 samueldmq mordred: :(
14:14:20 dtantsur mordred: I think the baremetal shade parts need a lot of love, so dunno about freezing them..
14:14:32 samueldmq nova servers says the precondition is to have enough quota, but doesn't specify the error code
14:14:42 mordred samueldmq: http://git.openstack.org/cgit/openstack-infra/nodepool/tree/nodepool/driver/openstack/handler.py#n256
14:15:07 samueldmq mordred: :-)
14:15:24 mordred samueldmq: we should maybe figure out how to throw a better execption in sdk :)
14:15:36 samueldmq *maybe*
14:16:03 mordred dtantsur: well, we should definitely fix them in sdk ... then we can suggest to people that they just migrate from shade to sdk if they want to use baremetal?
14:16:15 samueldmq that's very realiable, until someone decides to use SDK in Portuguese
14:16:53 mordred samueldmq: silly them
14:17:51 samueldmq :)
14:18:06 samueldmq SDK is fun.
14:18:26 dtantsur mordred: I'm fine with that, but that's quite a change in the direction :)
14:19:04 mordred dtantsur: oh - wait - I have potentially produced confusing words
14:19:17 mordred dtantsur: I meant the shade library itself, not the shade parts of the openstacksdk library
14:19:41 dtantsur AAAAAH
14:19:52 mordred dtantsur: it was actually the baremetal work you've been doing that made me think this - I like all the cleanups, and I think needing to keep in mind the older shade library while you do them is ... not super useful
14:20:07 dtantsur right, yeah..
14:21:35 mordred dtantsur: https://review.openstack.org/610981 might be clearer :)
14:22:07 dtantsur gotcha, makes sense
14:38:09 openstackgerrit Merged openstack/openstacksdk master: Use network proxy in openstack.cloud https://review.openstack.org/604645
14:38:10 openstackgerrit Merged openstack/openstacksdk master: Remove all the deprecated stuff https://review.openstack.org/605508
14:38:11 openstackgerrit Merged openstack/openstacksdk master: Start shifting cloud object-store methods to proxy https://review.openstack.org/608317
14:38:12 openstackgerrit Merged openstack/openstacksdk master: Make it clear that OpenStackCloud is a mixin https://review.openstack.org/608318
14:38:13 openstackgerrit Merged openstack/openstacksdk master: Revert the Proxy metaclass https://review.openstack.org/609747
14:38:15 openstackgerrit Merged openstack/openstacksdk master: Wire in retries for all baremetal actions https://review.openstack.org/603427
14:38:23 dtantsur \o/
14:44:03 mordred zomg
14:46:50 mordred dtantsur: don't kill me ... but in https://review.openstack.org/#/c/610024/2/openstack/cloud/openstackcloud.py - I don't think you even need the _to_munch() call
14:47:29 dtantsur maybe? I have hard time following the fast pace of changes here :)
14:47:35 mordred dtantsur: I know :)
14:47:37 dtantsur is Resource a dict now?
14:47:40 mordred yup
14:48:17 mordred so hopefully we'll get to a place where we can use the Resource objects interchanably no matter whether someone used the shade layer or the sdk layer
14:52:52 dtantsur AssertionError: Keys {'uuid', 'node_uuid'} are in Munch({'address': '00:01:02:03:04:05', 'node_uuid': '7172e42c-394f-4693-8e33-24d4cebf6813', 'uuid': '935433196bc54ac7b236732ef681bd37'}) but not in openstack.baremetal.v1.port.PortDetail(address=00:01:02:03:04:05, node_uuid=7172e42c-394f-4693-8e33-24d4cebf6813, uuid=935433196bc54ac7b236732ef681bd37)"
14:53:06 dtantsur I wonder if uuid->id conversion screws me up in this test
14:53:08 dtantsur mordred: ^^^
14:55:08 mordred dtantsur: hrm. which test?
14:55:32 dtantsur mordred: openstack.tests.unit.cloud.test_baremetal_ports.TestBaremetalPort.test_list_nics (try removing to_munch from my patch)
14:56:57 mordred trying
14:56:59 dtantsur yeah, I highly suspect id vs uuid can be a problem. we can fix it in the test, but then it's a breaking change (?)\
15:05:56 mordred dtantsur: how distasteful do you find this: http://paste.openstack.org/show/732253 ?
15:06:58 dtantsur mordred: aren't we breaking our unification promise with s/id/uuid/ ?
15:07:06 mordred actually, http://paste.openstack.org/show/732254 is better
15:07:31 mordred dtantsur: amazingly enough that code sill produces port_detail.id
15:07:55 dtantsur so, we're going to have both id and uuid on a resource?
15:08:07 mordred maybe? mostly just thinking out loud right now :)
15:09:08 dtantsur I'll need to think about it for some time. what if we merge the to_munch variant for now, given that we already have this to_munch here and there?
15:09:25 dtantsur and I'll take some deeper thought on the id vs uuid situation
15:09:48 mordred dtantsur: sure - although, I think the test break is showing that we're winding up returning munch's with uuid in them instead of id?
15:10:39 dtantsur mordred: which is what we have been doing so far, no?
15:10:41 mordred dtantsur: http://paste.openstack.org/show/732255 is a bit more explicit and also works with the test
15:10:50 dtantsur given that normalize_machine has never done s/uuid/id/
15:11:12 dtantsur what I'm trying to say: baremetal functions in the shade and SDK parts already differ in this regard
15:12:19 mordred yah - totally, although I'd say that not normalizing uuid to id was an oversight ... and one of the reasons decoupling the released shade library from the new shade portions of the sdk might be a good idea here ... shade was always also supposed to use id instead of uuid for things
15:12:47 mordred if we return both uuid and id, then we should be able to move people towards just using id without breaking anyone who might be using it curently ... at the cost of a less clean interface
15:13:38 mordred BUT - the number of consumersof openstacksdk shade layer so far should be fairly small, so maybe we do both in this next point release with an insta-deprecate on the uuid properties?
15:13:51 mordred probably all of these options are wrong :)
15:14:03 mordred I clearly have not consumed enough coffee yet
15:14:23 dtantsur that's why I'd prefer a time out to think about it :)
15:14:27 mordred :)
15:15:49 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Return both uuid and id for baremetal port https://review.openstack.org/611009
15:16:07 mordred dtantsur, Shrews: ^^ I pushed up my change as a followup so that we can look at it and ponder and argue properly
15:20:45 dtantsur mordred: instant comment: we need the same of all bm resources
15:23:17 mordred dtantsur: oh - totally - whatever we decide here should apply across the board
15:23:56 dtantsur mordred: is it possible to hide "uuid" from the resource and only make it visible when using dict stuff?
15:24:05 dtantsur kind of thinking aloud
15:24:07 mordred dtantsur: it's python - anything is possible :)
15:24:10 dtantsur heh
15:24:17 dtantsur reasonable is a different question
15:24:38 mordred dtantsur: not sure - would have to poke - I thinkn work already goes in to aligning object and dict access though
15:24:53 dtantsur yeah, stupid idea probably...
15:25:10 mordred me to
15:25:12 mordred me too
15:25:20 dtantsur I'm thinking about ugly cases like creating a node with different id and uuid :D
15:27:55 mordred >>> p = openstack.baremetal.v1.port.PortDetail(id='123', uuid='345')
15:28:03 mordred >>> p._to_munch()
15:28:05 mordred Munch({'node_uuid': None, 'extra': None, 'pxe_enabled': None, 'id': '345', 'name': None, 'internal_info': None, 'links': None, 'local_link_connection': None, 'updated_at': None, 'created_at': None, 'portgroup_uuid': None, 'address': None, 'physical_network': None, 'location': None, 'uuid': '345'})
15:28:09 mordred yeah. that's not what we want :)
15:30:18 dtantsur yeah, I wonder what happens if you try to create such port..
15:30:51 dtantsur well, ports do not allow to specify uuid on creation, but nodes do (consistency!)
15:36:58 openstackgerrit Merged openstack/os-api-ref master: tests: Support Sphinx 1.8+ https://review.openstack.org/607984
15:48:00 openstackgerrit weizj proposed openstack/os-service-types master: Update the hacking to latst https://review.openstack.org/611054
15:49:50 openstackgerrit Merged openstack/openstacksdk master: Move wait_for_baremetal_node_lock to the baremetal proxy https://review.openstack.org/610946
15:52:27 dtantsur mordred: re https://review.openstack.org/610024 are you okay with it for now?
15:52:36 openstackgerrit Merged openstack/openstacksdk master: Remove duplicate code https://review.openstack.org/610404
15:54:23 mordred dtantsur: yeah - I thnk it's fine for today - it's not an additional issue from what today is
15:54:36 mordred dtantsur: I think we should solve the other question before we 1.0
15:55:22 dtantsur totally
15:56:29 dtantsur my personal minimum plan is to get rid of every single hardcoded microversion=1.6 by the release
15:57:56 mordred dtantsur: yah - I agree re: 1.0 ... I think this next point release will be close enough to 1.0 that we can start working on using it more within osc (discovery and resources-as-dicts were the last two things I was worried about getting in before we started doing that)

Earlier   Later