| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-16 | |||
| 12:53:41 | dtantsur | w00t | |
| 12:53:57 | dtantsur | meanwhile, I continue polishing the bare metal stuff in OpenStackCloud ^^^ | |
| 12:54:13 | dtantsur | mordred: do you expect another release before 1.0? I guess I'll end up with a lot of deprecations.. | |
| 12:55:18 | mordred | dtantsur: yeah - I think we need to do at least one just to see what we might have missed/broken | |
| 12:55:31 | mordred | dtantsur: the current master branch is ... large :) | |
| 12:55:40 | dtantsur | right :) | |
| 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 | |