Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-10-16
12:55:46 mordred eandersson: \o/ THANK YOU for fixing the magnum jobs
13:06:17 Shrews mordred: approved the stack
13:07:18 mordred Shrews: \o/
13:08:44 mordred Shrews: if you're still in the mood, dtantsur has a good patch here: https://review.openstack.org/#/c/603427
13:10:31 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add stackviz processing to functional tests https://review.openstack.org/610167
13:10:42 mordred dtantsur: added comment ^
13:10:52 dtantsur thnx
13:14:29 samueldmq morning
13:14:46 samueldmq is the glance task import a v2 only thing or does it exist in v1?
13:21:27 mordred samueldmq: only v2
13:21:47 mordred samueldmq: v1 had PUT content upload- and also had import-from-url which 2 doesn't have
13:21:54 samueldmq mordred: thanks, that one is a very special case. I haven't seen that in the clouds I tested though
13:22:17 samueldmq mordred: kk but we don't do import-from-url for v1
13:23:03 samueldmq we could technically try via put directly and if it fails try the task workflow when using v2
13:23:10 mordred samueldmq: that's right - I never added it because it wasn't in v2 - so there was no way to add it consistently across both
13:23:24 samueldmq so that one didn't have to set use_task_api in the config... but as I haven't seen that anywhere... /me shrugs
13:23:38 mordred samueldmq: yes - I was thinking the same thing
13:23:51 mordred samueldmq: and have use_task_api as a config option to avoid the call to PUT
13:24:12 mordred samueldmq: rackspace and switch are the only clouds I'm aware of that make you use the task api
13:24:13 samueldmq mordred: yes, that wins if set
13:24:27 samueldmq mordred: switch no more. it's using the put api now
13:24:31 mordred samueldmq: we should test which error code we get on a task cloud when you try the put
13:24:34 mordred samueldmq: oh good!
13:24:58 mordred samueldmq: to make sure we can detect it properly
13:26:16 samueldmq mordred: ++
13:38:16 Shrews mordred: what is your plan for using the stackviz output? what problem is it solving for us?
13:39:21 mordred Shrews: looking at it to see which tests take how long ... there's also supposed to be overlaid dstat output which seems to be not working atm
13:40:17 mordred Shrews: also - it's sort of an exploration about using that stackviz stuff for non-tempest runs - and it seems like it's going great
13:40:41 Shrews so the goal is to optimize our test suite?
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

Earlier   Later