| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-11-07 | |||
| 16:14:42 | johnsom | OSC is a huge leap forward from the old clients. We have also got a lot of positive feedback about it for our project. Just saying.... | |
| 16:19:53 | johnsom | That said, yeah, the topic here is good-form for shared library method signatures. | |
| 16:21:13 | johnsom | efried FYI, it looks like the tips job on my patch with the depends-on did pass. | |
| 16:21:57 | johnsom | The others will not pass now until your osc-lib patch merges given the other changes. | |
| 16:22:12 | efried | johnsom: Okay, I hadn't looked yet this morning. IRL we would have to get it released and through u-c and required by python-openstackclient before merging. | |
| 16:22:13 | johnsom | Well, merges, releases, and upper-constraints merges | |
| 16:22:22 | efried | jinx | |
| 16:22:26 | johnsom | Yeah, all that | |
| 16:22:36 | efried | There was another osc-lib change I was looking for... | |
| 16:22:39 | johnsom | Thus my grumpy mood yesterday | |
| 16:23:43 | efried | oh, it was this: right now the generated docs from within python-openstackclient are still tagged with "This command is provided by the python-openstackclient plugin" | |
| 16:24:18 | efried | I was trying to fix that from osc-lib, but I think I found out it has to be fixed either from python-openstackclient itself or from cliff, or possibly both, I can't remember if I closed the gap all the way yet. | |
| 16:25:12 | efried | https://review.opendev.org/692465 | |
| 16:25:12 | efried | https://review.opendev.org/692464 | |
| 16:25:12 | efried | oh yeah, I ended up with this: | |
| 16:30:56 | dtroyer | efried: I gave that cliff review a +2 but you might want to remove WIP from the commit just for cleanliness sake. | |
| 16:31:06 | dtroyer | otherwise it looks good | |
| 16:31:45 | gtema | dtroyer, you are finally online at the same time as I. | |
| 16:31:53 | gtema | What about https://review.opendev.org/#/c/650374 - switch image to SDK | |
| 16:32:19 | gtema | I know it's huge, but we need to do something | |
| 16:32:57 | dtroyer | I'm still pondering on https://review.opendev.org/#/c/693267, I'm assuming it isn't done yet, update_tags_for_set() isn't touched... | |
| 16:33:57 | dtroyer | gtema: yes, it is huge and I haven't been able to get the kind of block of time to go through that yet. I also want to make sure we have decent enough functional tests to validate everything before and after (you may have that) | |
| 16:34:52 | gtema | I understand. Just want to get clear on that change to decide what/how to do next. | |
| 16:35:25 | gtema | I introduced in this change another sdk_utils, and wanted in the followup to clean it up in compute | |
| 16:36:01 | dtroyer | gtema: is that something that maybe belings in osc-lib? would plugins want it? | |
| 16:36:26 | gtema | well, this is something what any SDK based plugin might want | |
| 16:36:32 | dtroyer | we're gearing up to release osc-lib soon for the tags changes anyway | |
| 16:37:09 | gtema | should I propose adding it there then? | |
| 16:38:11 | dtroyer | if you think it is stable, sure. if it makes more sense to expand it to another API first to make sure it is 'done' then maybe wait. I'll try to take a look at that today | |
| 16:38:37 | gtema | well, it is there since network uses SDK, so yes, it is stable | |
| 16:39:16 | gtema | it's basically more or less just to kinda "show" SDK resource | |
| 16:39:33 | dtroyer | yeah, even if they don't belong in osc-lib network does have some things that should be generalized for osc itself | |
| 16:55:26 | efried | dtroyer: none of the update_tags_for_* methods are touched. How would they be? | |
| 16:56:01 | efried | dtroyer: I think the cliff WIP might have been because I wanted to add some kind of testing. | |
| 16:56:30 | dtroyer | efried: doh, right on update_*() | |
| 16:56:46 | efried | phew, cause I couldn't imagine how that would work :P | |
| 16:57:20 | dtroyer | cliff is used outside OpenStack so we're a bit more cautious about changes there, I don't see this one as an issue, but yeah, tests++ | |
| 16:57:41 | efried | dtroyer: also wanted to make sure stephenfin had a crack at the concept before I invested too much time in it. | |
| 16:58:02 | efried | dtroyer: btw, the other approach was to override Command etc. to provide a dummy App from within python-openstackclient | |
| 16:58:09 | efried | because that's what cliff is bouncing off of when it generates that line. | |
| 16:58:39 | efried | I tried doing that from within osc-lib but then the package is... osc-lib, and you get the message anyway :( | |
| 16:59:17 | dtroyer | yeah, there is a small set of things like that that can't move into osc-lib | |
| 16:59:19 | efried | also, the App superclass is *really* not designed to be "docs build" oriented, so that would be a serious hack. | |
| 17:00:00 | efried | so as long as stephenfin / other cliff maintainers are okay with "polluting" the config space with another option, this solution is reasonably simple and clean. | |
| 17:00:28 | efried | I'll go back and add tests if I get some time, but I'm not in a rush as I don't expect stephenfin to look until next week at the very earliest. | |
| 17:00:31 | elmiko | later all, have a good weekend o/ | |
| 17:00:35 | efried | o/ elmiko | |
| 17:02:01 | cdent | elmiko: | |
| 17:02:09 | cdent | hi | |
| 17:02:11 | cdent | that is all | |
| 17:02:44 | elmiko | hey cdent! =) | |
| 17:02:45 | gtema_ | looks like "That's all Folks" | |
| 17:13:08 | dtroyer | gtema_: so I'm just making time now, as that isn't as large as I remembered and I didn't realize you only did v2… | |
| 17:13:44 | dtroyer | the deal with image create from stdin isn a significant change and at a bare minimum needs to be release-noted. There are a few placed it would break scripts I've written | |
| 17:13:45 | gtema_ | yeah, this is exactly the next point - what do we want to do with v1 (drop or port it in followup) | |
| 17:14:17 | dtroyer | I don't want to drop v1, we'll need to convert it too eventuallly, I _REALLY_ want to get rid of glancelcient and it's weird deps | |
| 17:14:49 | gtema_ | for the moment create from stdin is supported, but not efficient | |
| 17:15:28 | gtema_ | ok, then I can work on v1 in a followup. I had nowhere a real v1 to test it works and didn't want change to explode | |
| 17:16:32 | dtroyer | yeah, that was supposed to be tested with other ancient APIs in that devstack-like mitaka cloud I was working on when starlingx destroyed my (work) life… | |
| 17:16:52 | gtema_ | what I find funny - in real usage OSC becomes faster in lots of cases, but osc tests are tiny bit longer | |
| 17:17:24 | gtema_ | the func-ones I mean | |
| 17:43:58 | gtema_ | dtroyer: thanks. wrt pagination: currently if limit is set in osc it return only single page. "paginate" flag in SDK used to fetch everything to the end | |
| #openstack-sdks - 2019-11-08 | |||
| 06:40:39 | openstackgerrit | Brin Zhang proposed openstack/python-openstackclient master: Microversion 2.79: Add delete_on_termination to volume-attach API https://review.opendev.org/673725 | |
| 15:54:43 | openstackgerrit | Matt Riedemann proposed openstack/python-openstackclient master: Provide stderr in exception when check_parser fails https://review.opendev.org/682939 | |
| #openstack-sdks - 2019-11-11 | |||
| 03:47:48 | openstackgerrit | Merged openstack/openstacksdk master: Increase test timeout for 2 tests in TestImageProxy class https://review.opendev.org/692323 | |
| 07:43:33 | danil | hello folks. Please help me. Is there a way to get nova client through openstacksdk? I mean that I can not just use novaclient library due to dependencies. Thanks | |
| 09:46:23 | danil | hello folks. Please help me. Is there a way to get nova client through openstacksdk? I mean that I can not just use novaclient library due to dependencies. Thanks | |
| 10:08:00 | dtantsur | danil: something like openstack.connect(...).compute? | |
| 10:08:09 | dtantsur | it won't be a client identical to novaclient, of course | |
| 10:14:17 | danil | dtantsur, thanks . The main method I want to find is something like "interface_attach" in novaclient. This method adds a virtio device to nova instance | |
| 10:15:52 | dtantsur | danil: check https://docs.openstack.org/openstacksdk/latest/user/connection.html maybe it has the call you need? | |
| 10:53:53 | cdent | dtantsur: were you in shanghai? if so, how was it? | |
| 11:02:47 | dtantsur | cdent: I wasn't, in the middle of a move here | |
| 11:02:59 | cdent | ✔ | |
| 11:03:04 | cdent | I hope that all goes well | |
| 11:03:50 | danil | dtantsur, yes. looks like it should be there, in openstack.connect(...).compute . I found a method "create_server_interface" in Proxy class | |
| 11:04:15 | dtantsur | cdent: me too :) an infinite stream of small problems | |
| 11:04:37 | cdent | ooph | |
| 11:05:39 | gtema_ | hehe, what you know about small problems. My API monitoring platform got blocked by our internal Firewalls/AntiDDoS/whatsoever and nobody can figure out what and why is blocking. | |
| 11:07:27 | dtantsur | :D | |
| 11:07:48 | dtantsur | not sure if it's as inconvenient as sitting without a kitchen though (and now with a door bell stuck in "mute" position, wtf) | |
| 11:09:24 | gtema_ | he, I was doing this when moved to Germany, so I know perfectly what you mean | |
| 11:10:42 | gtema_ | mordred: still in china? are you allowed to leave or you stay there forever? | |
| 11:11:06 | mordred | gtema_: here til friday. I won't know if they'll let me leave until then :) | |
| 11:11:22 | gtema_ | oki | |
| 11:22:24 | mordred | gtema_: your colleague Nils did a great talk on using sdk btw | |
| 11:22:58 | gtema_ | thanks. He wrote me you talked to each other. Hope we will be able to improve the docs correspondigly | |
| 11:23:57 | mordred | ++ | |
| 18:26:24 | mnaser | is there an official page instead of this wiki page? https://wiki.openstack.org/wiki/OpenStackClients | |
| 18:26:48 | mnaser | maybe https://docs.openstack.org/train/language-bindings.html ? | |
| #openstack-sdks - 2019-11-12 | |||
| 00:31:01 | mordred | mnaser: yeah - I think that's what we've got | |
| 06:35:23 | openstackgerrit | Bin Lu proposed openstack/python-openstackclient master: add optional argument metric to set metric for routes https://review.opendev.org/637658 | |
| 06:48:48 | openstackgerrit | Bin Lu proposed openstack/python-openstackclient master: add optional argument metric to set metric for routes https://review.opendev.org/637658 | |
| 13:13:13 | Blinkiz | How can I connect to cloud and become role:admin and system_scope:all which is needed if am running with [oslo_policy]/enforce_scope=true? | |
| 13:13:17 | Blinkiz | https://storyboard.openstack.org/#!/story/2006839 | |
| 13:42:58 | frickler | Blinkiz: there was some discussion about this here a couple of days ago. IIUC the conclusion was that better support for that was needed in the sdk, but you should be able to set up a dedicated clouds.yaml entry with the required parameters | |
| 13:46:11 | Blinkiz | frickler: hello frickler, thanks for answering. How would that clouds.yaml look like? Am guessing the examples here do not apply because they all defining domain. https://docs.openstack.org/openstacksdk/latest/user/guides/connect_from_config.html | |
| 13:46:38 | Blinkiz | define | |
| 13:52:48 | frickler | Blinkiz: seems you just add "system_scope: all" to the auth section and drop all domain parameters | |
| 13:55:14 | Blinkiz | frickler: Okay. Can you please help me find where this is defined in source code for openstacksdk? Am trying to get deeper knowledge how it works so it would help | |