| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-16 | |||
| 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 | |
| 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') | |