| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-07-20 | |||
| 15:11:24 | mordred | corvus: 0.17.0 of sdk has been released which has those new methods we added | |
| 15:11:40 | corvus | mordred: sweet, i'll try 'em out soon | |
| 15:11:47 | dtantsur | ack, I'll propose it | |
| 15:12:52 | mordred | dtantsur: (I don't know if stable/rocky has been cut yet - I think maybe that's today?) | |
| 15:13:23 | dtantsur | mordred: the person releasing openstacksdk should propose that to releases repo | |
| 15:14:33 | dtantsur | mordred: on a related note, which deadline affects openstacksdk: the non-client yesterday or the client next week? | |
| 15:14:48 | dtantsur | I would expect openstacksdk to follow the same cadence as python-XXXclient stuff | |
| 15:15:19 | mordred | dtantsur: non-client | |
| 15:15:25 | dtantsur | that's weird to me | |
| 15:15:34 | mordred | dtantsur: it gets lumped in to that because there are python-*client libs thatuse it | |
| 15:15:41 | dtantsur | puts openstacksdk in a worse position wrt to catching up with features | |
| 15:15:52 | dtantsur | like, API additions can land till next week. | |
| 15:16:00 | dtantsur | but openstacksdk has no chances of exposing them | |
| 15:16:10 | mordred | yeah - I think it's maybe something we should talk about next cycle as we start to use sdk directly for more and more of the projects | |
| 15:16:35 | mordred | dtantsur: good point | |
| 15:16:46 | dtantsur | also for non-client you was supposed to create stable/rocky yesterday with 0.17 :) | |
| 15:16:53 | dtantsur | * for non-client deadline | |
| 15:21:32 | mordred | oh. piddle. | |
| 15:21:40 | mordred | I'm not used to these stable branch things ... | |
| 15:25:23 | openstackgerrit | Merged openstack/openstacksdk master: baremetal: correct the default timeout in Node.set_provision_state https://review.openstack.org/584331 | |
| 15:27:21 | dtantsur | mordred: if you don't know, this is how it looks https://review.openstack.org/#/c/584021/3/deliverables/rocky/sushy.yaml | |
| 15:33:25 | mordred | dtantsur: yeah - I just sent one up | |
| 15:33:29 | mordred | and thanks! | |
| 15:33:34 | dtroyer | osc-lib has the same issue as sdk wrt non-client freeze, I agree it is probably time to re-think that and move them to client-lib category | |
| 15:33:40 | dtroyer | for stein | |
| 15:42:03 | mordred | ++ | |
| 15:42:48 | mordred | dtroyer: speaking of - we're maybe 2 patches away from 1.0 - so I think targetting that for stein should be *totally* doable | |
| 15:42:53 | mordred | (for sdk) | |
| 15:43:33 | mordred | dtroyer: in fact, I'm hoping I can get those written during freeze-time ... so hopefully we can cut 1.0 very early in the stein cycle | |
| 15:43:41 | dtroyer | \o/ \O/ \o/ | |
| 15:44:13 | mordred | dtroyer: wehave a few more weeks before osc itself is froze, yeah? | |
| 15:46:20 | dtroyer | next week I think, we've considered it a client lib due to other project dependencies | |
| 15:46:41 | dtroyer | so moving osc-lib and sdk would lump them all together but I think that is OK | |
| 15:47:24 | dtroyer | I was hoping to have more of the backlog in OSC merged but I'm planning to cut the to-be-stable release tuesday | |
| 15:48:15 | mordred | dtroyer: kk. I've got a fairly simple command I wanted to add - I'll try to get that done today | |
| 15:49:14 | dtroyer | mordred: sounds good | |
| 15:50:44 | corvus | mordred: is there a way to get the requests.Session() that keystoneclient/openstacksdk use? | |
| 15:51:07 | mordred | corvus: yes | |
| 15:51:43 | mordred | corvus: conn.config.get_session() | |
| 15:53:13 | corvus | mordred: perfect, thanks! | |
| 15:53:49 | corvus | (i wanted to set the max poolsize for the connection pool, since i'm multithreaded; this will allow more connection reuse) | |
| 15:53:50 | mordred | corvus: out of curiosity - are you wanting to use it to make a rest call against one of the openstack endpoints? | |
| 15:54:02 | mordred | ah! | |
| 15:54:04 | corvus | sess.mount('https://', adapter) | |
| 15:54:04 | corvus | adapter = requests.adapters.HTTPAdapter(pool_maxsize=100) | |
| 15:54:04 | corvus | sess = cloud.config.get_session() | |
| 15:54:23 | mordred | neat. that should totally work | |
| 15:54:28 | corvus | it does! | |
| 15:54:42 | mordred | corvus: do you think that's an option we should expose in openstack.config ? | |
| 15:54:45 | corvus | no more warnings about the pool being full | |
| 15:54:48 | mordred | (not today - just in general) | |
| 15:56:00 | corvus | mordred: perhaps -- might be a nice friendly thing -- there's some subtlety about how connection pooling works for multiple hosts that i skimmed over because i'm only talking to one host. would probably need to read up a bit more on that before implementing something. | |
| 15:56:19 | mordred | corvus: ++ | |
| 15:57:07 | corvus | aiui from my quick reading, there's only one pool by default, so if you access a second host, it drops the pool for the first host. but in addition to pool_maxsize (max connections in pool), there's also pool_connections -- number of pools | |
| 15:57:36 | corvus | probably the thing to do would be to expose both of those. but like i said, i skipped some details so i'm not 100% sure | |
| 15:58:14 | mordred | yeah - especially since for openstack it's extrememly common for each service to have its own host - and for sdk to use the same session for all of them | |
| 15:58:31 | corvus | fwiw, changing the pool size did not greatly impact the total amount of time spent uploading objects to swift. but it still makes me feel better. :) | |
| 15:59:19 | mordred | corvus: we could maybe get fancy and look in the catalog, count the number of distinct hosts contained in it and use that to set a default for pool_connections | |
| 15:59:41 | corvus | mordred: may want more for the multi-cloud case... | |
| 15:59:53 | corvus | oh, this is a per-cloud session anyway | |
| 15:59:57 | mordred | corvus: multi-cloud case would ... yeah | |
| 15:59:58 | corvus | so yeah, your idea could work | |
| 16:00:10 | corvus | unless redirects are involved? | |
| 16:00:19 | corvus | (heh, just double it! :) | |
| 16:00:34 | mordred | well, if they are involved, we can still expose the setting :) | |
| 17:56:32 | PagliaccisCloud | hey guys i'm trying to fix a typo in the help menu on python-openstackclient. to create a bug, do i make a new story on storyboard? | |
| 18:25:25 | dtroyer | PagliaccisCloud: yes | |
| 18:33:49 | PagliaccisCloud | cool, thanks dtroyer. sending to gerrit now | |
| 18:37:46 | openstackgerrit | Treva Nichole Williams proposed openstack/python-openstackclient master: Fix typo in "floating ip set" properties https://review.openstack.org/584484 | |
| 21:23:24 | openstackgerrit | Toure Dunnon proposed openstack-infra/shade master: python-shade expose MTU setting. https://review.openstack.org/578861 | |
| #openstack-sdks - 2018-07-21 | |||
| 02:06:33 | corvus | for dealing with connection info in yaml... | |
| 02:06:33 | corvus | mordred, Shrews: for the zuul swift thing, i'd like to define a secret in zuul where the data is exactly the contents of a cloud from clouds.yaml. is it possible to hand that dictionary directly to something in openstacksdk or os-client-config and get a connection object? it seems like i ought to be able to avoid writing out a clouds.yaml for this case, and i don't want to invent another format | |
| 02:08:14 | corvus | (if not, i'll probably just write it to a secure tempfile and set OS_CLIENT_CONFIG) | |
| 02:29:07 | openstackgerrit | James E. Blair proposed openstack/openstacksdk master: Docs: Include CloudRegion class https://review.openstack.org/584552 | |
| 02:29:21 | openstackgerrit | James E. Blair proposed openstack/openstacksdk master: Docs: Fix references in connection page https://review.openstack.org/584553 | |
| 02:29:34 | openstackgerrit | James E. Blair proposed openstack/openstacksdk master: Docs: Remove duplicate content in connection page https://review.openstack.org/584554 | |
| 13:15:48 | mordred | corvus: yes - you can use it to create a CloudRegion object | |
| 13:20:20 | mordred | corvus: or, rather, you can do it directly with Connection ... openstack.connection.Connection(**config_dict) | |
| 13:23:52 | openstackgerrit | Merged openstack/openstacksdk master: Docs: Include CloudRegion class https://review.openstack.org/584552 | |
| 13:23:53 | openstackgerrit | Merged openstack/openstacksdk master: Docs: Remove duplicate content in connection page https://review.openstack.org/584554 | |
| #openstack-sdks - 2018-07-23 | |||
| 09:11:22 | openstackgerrit | Josephine Seifert proposed openstack/python-openstackclient master: [WIP] osc-included image signing (using openstacksdk) https://review.openstack.org/580086 | |
| 13:41:32 | openstackgerrit | Merged openstack/os-service-types master: Add release note link in README https://review.openstack.org/578439 | |
| 13:50:35 | Luzi | hi osc and sdk: looking through the latest patches I have seen, that since Jul 19 every time zuul checks "osc-functional-devstack" it fails | |
| 13:50:49 | Luzi | with the same failure in every patch | |
| 13:52:14 | Luzi | any idea, why this is happening? it is the "test_volume_snapshot" that fails with "Invalid input for field/attribute size. Value: None. None is not of type 'integer', 'string' (HTTP 400)" | |
| 13:59:47 | Luzi | this is the earliest patch, that has this error: https://review.openstack.org/#/c/582334/ | |
| 14:04:17 | Luzi | mordred, dtroyer this might be interesting for you - this might be a bigger bug somewhere | |
| 14:08:31 | pasm | hi guys, I found and fixed a bug in osc-lib (https://github.com/psmiraglia/osc-lib) | |
| 14:08:51 | pasm | how to submit a PR? | |
| 14:09:02 | dtroyer | Luzi: we have had sporadic problems with volume tests over the years, this feels like a real bug somewhere. It is possible that cinderclient has a change in it that we need to account for, or isn't backward-compatible. I'll make some time to look at it after lunch… | |
| 14:09:15 | pasm | (hope this is the right place to ask) | |
| 14:09:33 | Luzi | dtroyer: thank you :) | |
| 14:09:36 | dtroyer | pasm: it is! | |
| 14:09:40 | pasm | :-) | |
| 14:09:47 | dtroyer | and that looks oddly familiar... | |
| 14:10:50 | dtroyer | pasm: I think it was laready fined here: https://review.openstack.org/#/c/581886/ | |
| 14:11:47 | pasm | dtroyer: it is incopmlete | |
| 14:11:52 | dtroyer | and that was released last week as 1.11.0 | |
| 14:11:55 | dtroyer | ah, ok | |
| 14:11:59 | dtroyer | grrr... | |