| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-07-03 | |||
| 12:50:47 | priteau | Thanks mordred | |
| 13:31:47 | cdent | dtroyer: if you have a moment to gaze on an osc-placement naming discussion, that would be helpful: https://review.opendev.org/666542 | |
| 13:31:49 | cdent | also: hi | |
| 13:41:59 | dtroyer | cdent: oh that looks like a fun one, thanks ;) | |
| 13:42:13 | cdent | dtroyer: I'm all about fun for you | |
| 13:42:44 | cdent | I suspect placement's nature as "mostly admin" gives it a bit off leeway | |
| 13:43:09 | dtroyer | (just thinking out loud here) I am not much of a fan of complex queries build from CLI options, if you need a complex query, build a DSL for that? | |
| 13:43:21 | dtroyer | in OSC so far we have mostly gotten away with that | |
| 13:46:28 | dtroyer | using the options to detect/attempt specific API microversions in itself is fine with me, sometimes it can be obvious, but that in: magic doesn't sit well with me. I don't like options with values that contain keywords but that turned out to be unavoidable in some places, so there is a bit of precedent for how those should look | |
| 13:49:05 | dtroyer | so if I read that right the review is basically a straight port of the REST API semantics to the cli options? | |
| 14:13:55 | mordred | CLI arguments like "--member-of in:<uuid1>:<uuid>" give me hives | |
| 14:14:55 | mordred | passing complex need-to-be-parsed data structures is hard to deal with on the CLI (although makes sense in the REST API itself) - and invariably gets really brittle (see anything related to block_device_mapping) | |
| 14:15:14 | mordred | (which I think is me saying I agree with dtroyer :) ) | |
| 14:17:11 | mordred | I'd rather see multiple options - like --member-of <uuid1> --member-of <uuid2> to make the && case like mentioned, but then maybe like --member-in <uuid> --member-in <uuid2> to construct member_of="in:uuid1:uuid2" ... but that's just off the top of my head, and I'm not sure how weird that woudl be to actually use | |
| 14:17:50 | mordred | or, heck - a --member-in <uuid1>,<uuid2> would bother me less than the in: prefix | |
| 14:18:28 | mordred | maybe I should say some of that in the review ... | |
| 14:19:05 | cdent | dtroyer: sorry, stepped away. the suggestion from gibi is to do a straight port of the new microversin | |
| 14:19:16 | cdent | and for the most part that's what's been doing in several places, but...not always | |
| 14:19:22 | cdent | thus leading to the current confusion | |
| 14:31:42 | dtroyer | cdent: in meeting now, part way writing a reply in the review. In short, the implicit AND/OR operators are confusing and I don't think OSC has a clear precedent there. Multiple —property options are effectively an AND in create/set commands for example… | |
| 14:32:34 | cdent | yes, that confusion is why I think explicitly copying the query structure (which is at least somewhat documented and familiar to people who will even care to use that specific microversion) | |
| 14:33:06 | cdent | I suspect we are overthinking this because we are trying to incrementally support microversions, rather than simply support use cases | |
| 14:33:29 | cdent | we can already filter resource providers by aggregate membership | |
| 14:33:41 | cdent | and the need to do complex booleans, I would think, is rather rare | |
| 14:33:57 | cdent | so I'd almost be inclined to say "we don't do what 1.24 supports" | |
| 14:34:43 | cdent | dtroyer: this keeps happening with osc-placement but I'm hard pressed to believe that it is actually necessary | |
| 14:35:13 | cdent | people who want advanced filtering functionality should perhaps be able to pass a raw filter query, exactly as it would be formed in the URL | |
| 14:35:36 | cdent | and there should also be simple things (as there already are) | |
| 14:45:48 | dtroyer | cdent: we outlined a basic method for passing in structured data for doing things like bulk create operations at PTG, using that (once it is written) for queries seems logical… | |
| 16:03:44 | openstackgerrit | Sergey Vilgelm proposed openstack/keystoneauth master: OIDC supports public clients https://review.opendev.org/668951 | |
| 17:47:10 | openstackgerrit | Merged openstack/os-service-types master: Sync Sphinx requirement https://review.opendev.org/666384 | |
| #openstack-sdks - 2019-07-05 | |||
| 07:27:43 | ITD27M01 | Hi Guys. Who can help me with cache feature in OpenStack SDK? I did not understand how it works. If cache enabled in "clouds.yaml", then the list_servers always return an empty collection. | |
| 07:28:52 | gtema | ITD27M01 I recommend not to really use cache at the moment. We are thinking how to "fix" it. Basically currently you need to have also "memcached" running to be able to use it | |
| 07:29:01 | gtema | of cource file based works as well | |
| 07:29:17 | gtema | but it only works from the cloud layer, and not proxy/resource | |
| 07:30:51 | ITD27M01 | gtema: I tried different classes - memory, memcached and pylibmc but the behavior is the same. | |
| 07:31:51 | gtema | hmm, it works for me. But I prefer not to use it at all. From my POV as of now it make sense only for flavors | |
| 07:31:53 | ITD27M01 | gtema: connection.list_servers is a cloud layer ? | |
| 07:31:59 | gtema | yes, it is | |
| 07:33:38 | gtema | can you please share somehow your clouds.yaml cache section? | |
| 07:34:02 | openstackgerrit | zhangqing proposed openstack/python-openstackclient master: Fix cliff formattable columns in volume type https://review.opendev.org/669280 | |
| 07:34:52 | ITD27M01 | gtema: Yes, few seconds please. | |
| 07:36:17 | ITD27M01 | gtema: https://gist.github.com/ITD27M01/2705328e31d77770f02e85eeca55651d | |
| 07:36:31 | ITD27M01 | gtema: the first example with memory cache | |
| 07:38:48 | gtema_ | you miss the further configuration. Gimme a sec to share | |
| 07:39:36 | ITD27M01 | gtema: the second one with pylibmc https://gist.github.com/ITD27M01/68ecbfb77707b3ee3cf794e31e7dc1b6 | |
| 07:40:07 | gtema_ | yes, the second one is correct | |
| 07:40:15 | gtema_ | is your memcached running? | |
| 07:40:59 | ITD27M01 | gtema: last one with memcached https://gist.github.com/ITD27M01/6752eecd9ab4633beba4226d8a28e807 | |
| 07:41:18 | ITD27M01 | LISTEN 0 128 0.0.0.0:11211 0.0.0.0:* | |
| 07:41:18 | ITD27M01 | (venv) [root@srv8-byappi ~]# ss -nlt | grep 11211 | |
| 07:41:41 | gtema_ | pylibmc still requires memcached to be running. It's basically the same memcached backend | |
| 07:42:16 | gtema_ | I played around only with pylibmc and file backend, not the others | |
| 07:42:31 | gtema_ | can you please try the pylibmc and give a proper port for memcached? | |
| 07:45:02 | ITD27M01 | gtema: Updated https://gist.github.com/ITD27M01/68ecbfb77707b3ee3cf794e31e7dc1b6 | |
| 07:45:09 | ITD27M01 | gtema: Is this correct? | |
| 07:45:24 | gtema_ | yes, whould be | |
| 07:47:09 | ITD27M01 | gtema: Still empty output in list_servers :( | |
| 07:47:39 | gtema_ | and without caching it works? Just to be sure | |
| 07:48:19 | ITD27M01 | gtema: Without caching and with expiration.servers: 0 it works | |
| 07:48:33 | ITD27M01 | gtema: connection.list_servers(detailed=False, bare=True, filters=filters) it is the list_servers call | |
| 07:49:56 | gtema_ | hm. I am not sure there are proper logging for the caching, but can you try with debug mode? Also, is SDK able to connect to memcached? (I was always using the default port, so not specifying it at all) | |
| 07:53:02 | gtema_ | and the last question, which version of SDK are you using? | |
| 07:54:22 | ITD27M01 | gtema: openstacksdk==0.31.1, the memcached server on the local machine I will try to debug | |
| 07:54:41 | gtema_ | ok, I will be afk for next hour | |
| 08:14:28 | ITD27M01 | gtema: Debug with cache _disabled_ https://gist.github.com/ITD27M01/57b4fc69c13e6a166fe4af149848f3f9 | |
| 08:15:29 | ITD27M01 | gtema: Debug with enabled cache: https://gist.github.com/ITD27M01/cea8b04c0b836c0cef5fda21564efd04 | |
| 08:20:59 | gtema | ITD27M01: would you mind trying to add into the config expiration for the flavor (on the same level as server:3600) - flavor: -1 | |
| 08:21:22 | gtema | I do not see the default for the flavor expiration, and this is the only thing which differs | |
| 08:24:09 | ITD27M01 | gtema: The same log, last line is a call to servers/detail and that's it. | |
| 08:24:53 | ITD27M01 | flavor: -1 | |
| 08:24:53 | ITD27M01 | server: 5 | |
| 08:24:53 | ITD27M01 | expiration: | |
| 09:10:43 | openstackgerrit | zhangqing proposed openstack/python-openstackclient master: Use cliff formattable columns in compute commands https://review.opendev.org/669304 | |
| 09:39:24 | openstackgerrit | zhangqing proposed openstack/python-openstackclient master: Use cliff formattable columns in compute commands https://review.opendev.org/669304 | |
| 09:40:20 | ITD27M01 | gtema: Cache works fine in openstacksdk-0.17.2 (lowest version I need). I will check where the caching stops to work. | |
| 09:59:38 | ITD27M01 | gtema: Cache does not work starting openstacksdk-0.20.0 | |
| 10:00:43 | gtema_ | ok | |
| 10:02:26 | ITD27M01 | gtema: What are my prospects now? | |
| 10:03:16 | gtema_ | do not know yet, for me it was working with latest version | |
| 10:03:28 | gtema_ | sorry, am busy now. Will try to look bit later | |
| 10:06:02 | ITD27M01 | gtema: Ok, thank you | |
| 11:15:49 | openstackgerrit | Vishakha Agarwal proposed openstack/openstacksdk master: [WIP] Add application credential CRUD support https://review.opendev.org/669331 | |
| 11:28:30 | openstackgerrit | Vishakha Agarwal proposed openstack/openstacksdk master: [WIP] Add application credential CRUD support https://review.opendev.org/669331 | |
| 15:46:09 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/openstacksdk master: Increase randomness in ZONE creation https://review.opendev.org/669377 | |
| 16:27:21 | openstackgerrit | Merged openstack/shade master: Mailing lists change openstack-dev to openstack-discuss https://review.opendev.org/668438 | |
| 17:43:31 | openstackgerrit | Merged openstack/openstacksdk master: Fix invalid assert state https://review.opendev.org/668794 | |
| 17:43:32 | openstackgerrit | Merged openstack/openstacksdk master: Allow deeper levels of nesting for pdf builds https://review.opendev.org/667114 | |
| 18:17:16 | openstackgerrit | Corey Bryant proposed openstack/cliff master: Add Python 3 Train unit tests https://review.opendev.org/669445 | |
| 18:18:41 | openstackgerrit | Corey Bryant proposed openstack/openstackclient master: Add Python 3 Train unit tests https://review.opendev.org/637739 | |
| 18:20:00 | openstackgerrit | Corey Bryant proposed openstack/osc-lib master: Add Python 3 Train unit tests https://review.opendev.org/669446 | |
| 18:33:44 | openstackgerrit | Corey Bryant proposed openstack/python-openstackclient master: Add Python 3 Train unit tests https://review.opendev.org/669447 | |
| 18:34:51 | openstackgerrit | Corey Bryant proposed openstack/openstacksdk master: Add Python 3 Train unit tests https://review.opendev.org/669449 | |
| 18:35:40 | openstackgerrit | Corey Bryant proposed openstack/os-client-config master: Add Python 3 Train unit tests https://review.opendev.org/669450 | |
| 18:36:10 | openstackgerrit | Corey Bryant proposed openstack/os-service-types master: Add Python 3 Train unit tests https://review.opendev.org/669451 | |
| 18:36:53 | openstackgerrit | Corey Bryant proposed openstack/shade master: Add Python 3 Train unit tests https://review.opendev.org/669452 | |
| 19:01:36 | openstackgerrit | Merged openstack/openstacksdk master: Increase randomness in ZONE creation https://review.opendev.org/669377 | |
| #openstack-sdks - 2019-07-06 | |||
| 12:11:04 | openstackgerrit | Yuval Shalev proposed openstack/openstacksdk master: Added all-projects headers to dns service. https://review.opendev.org/669547 | |
| 19:13:10 | openstackgerrit | Yuval Shalev proposed openstack/openstacksdk master: Added all-projects headers option to dns proxy. https://review.opendev.org/669547 | |
| #openstack-sdks - 2019-07-08 | |||
| 06:52:27 | openstackgerrit | Boxiang Zhu proposed openstack/python-openstackclient master: Add host and hypervisor_hostname to create servers https://review.opendev.org/669609 | |