| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-09-30 | |||
| 21:14:59 | rm_work | ok well i did actually find out that i was wrong | |
| 21:15:04 | rm_work | it didn't work on admin_cloud either | |
| 21:15:08 | rm_work | so that makes more sense | |
| 21:15:28 | rm_work | and means it's not an issue with copying something, so much as just not being able to set the version correctly | |
| 21:15:56 | rm_work | which PROBABLY means that I just need to have some other arg set in the config when I pass it to the connection | |
| 21:16:06 | efried | wanna show me your connection init? | |
| 21:16:25 | rm_work | finding it | |
| 21:17:14 | rm_work | it's done via `connection.Connection(config=config.get_one(argparse=options))` | |
| 21:17:56 | rm_work | `config` is an os_client_config.config.OpenStackConfig object | |
| 21:18:13 | rm_work | so, probably "options" needs to have an identity-version set | |
| 21:19:25 | efried | Gotta run for ~20 mins, will check back... | |
| 21:31:43 | rm_work | yeah ok so basically there needs to be a way to specify "--os-identity-api-version" in the argparser that's passed in to the config that's then passed to the SDK | |
| 21:32:07 | rm_work | which wasn't happening (that isn't apparently part of the os_client_config arguments or the auth-module options :/ | |
| 21:32:30 | rm_work | which ... seems like maybe a bug there but for now i'll just add that arg explicitly in the app and that does it | |
| 21:32:51 | rm_work | (allows me to even pass that to the application in question) | |
| 21:33:48 | rm_work | appreciate the prodding, trying to replicate some stuff to paste it to you was exactly what i needed :D | |
| 21:41:23 | Shrews | rm_work: you can set identity api version in your clouds.yaml file, or an environment variable | |
| 21:42:28 | Shrews | there's a small blurb about that in the last paragraph of https://docs.openstack.org/openstacksdk/latest/user/config/configuration.html#site-specific-file-locations | |
| 21:48:55 | efried | rm_work: also noting that os-client-config is deprecated :) | |
| 21:49:19 | efried | or at least superseded | |
| 21:52:07 | dtroyer | yes, o-c-c has been absorbed into the SDK directly. It is now just a wrapper so it should be a good example of how to use SDK directly | |
| 21:53:04 | rm_work | Shrews: yeah but I have to account for the ability for people to not use clouds.yaml | |
| 21:53:08 | rm_work | which is where this came up | |
| 21:53:26 | rm_work | hmmm ok so I should stop importing it | |
| 21:53:32 | rm_work | i'm updating ospurge | |
| 21:54:18 | rm_work | dtroyer: is there an example/doc somewhere about how to replace usage of os_client_config ? | |
| 21:58:13 | dtroyer | that is what I meant about looking at o-c-c itself, it now does exactly that, translate to the SDK bits. Much of it is unchanged just in new module namespaces, but some did and I don't recall what that was offhand | |
| 22:01:11 | rm_work | ah k | |
| 22:04:39 | rm_work | ok yeah so i got rid of the os_client_config import | |
| 22:04:48 | rm_work | replaced it with an import of openstack.config.loader | |
| 22:05:06 | rm_work | and replaced `os_client_config.OpenStackConfig()` with `loader.OpenStackConfig()` | |
| 22:05:10 | rm_work | and it just... works | |
| 23:10:09 | efried | \o/ | |
| 23:32:12 | openstackgerrit | Steve Baker proposed openstack/openstacksdk master: Support vendor data in configdrive building https://review.opendev.org/683842 | |
| #openstack-sdks - 2019-10-01 | |||
| 06:47:56 | bverschueren_ | if someone could have a look at https://review.opendev.org/#/c/682909/ ? thx | |
| 08:38:02 | mordred | rm_work: yay! | |
| 08:41:02 | cdent | I first read that as "rm work ; yay!" which would be pretty yay. | |
| 08:48:01 | dtantsur | rm -rf | |
| 08:51:28 | mordred | ++ | |
| 08:51:51 | mordred | cdent: does the system continue working overall with that? like - if I just rm work, do I still get paychecks? | |
| 08:52:35 | cdent | mordred: in my pretty little mind it does | |
| 08:53:53 | mordred | cdent: I like the workings of that mind | |
| 08:54:16 | cdent | it's a very generous mind | |
| 08:54:22 | dtantsur | just copy paycheck somewhere before rm -rf | |
| 08:54:46 | mordred | dtantsur: ++ | |
| 08:54:53 | cdent | it's a fifo that you can read from as needed | |
| 08:56:00 | mordred | dtantsur: wow. vendor_data2.json | |
| 08:56:04 | mordred | dtantsur: because that's a filename | |
| 08:56:11 | dtantsur | haha | |
| 08:57:30 | mordred | heaven forbid we put any sort of versioning into the file content itself. | |
| 09:12:55 | openstackgerrit | Monty Taylor proposed openstack/keystoneauth master: Fetch discovery documents with auth when needed https://review.opendev.org/685042 | |
| 09:13:17 | mordred | efried, kmalloc, cmurphy: ^^ that's a simpler version and I think should be backportable | |
| 10:58:42 | openstackgerrit | Merged openstack/openstacksdk master: Support vendor data in configdrive building https://review.opendev.org/683842 | |
| 11:06:27 | openstackgerrit | Merged openstack/openstacksdk master: Add a non-voting ironic-inspector job https://review.opendev.org/684729 | |
| 15:15:07 | mordred | efried: you'll be happy to know that the 401 fix for keystoneauth, in additional to uncovering a different issue with swift (easy to fix) also uncovered the fact that, since we weren't ACTUALLY doing version discovery for nova before, we were falling back to 2.1 in sdk in all cases (which was actually our intention - we wanted to opt-in to newer behavior as we supported it) - but we were falling back | |
| 15:15:09 | mordred | to it accidentally- so with discovery fixed, sdk is getting newest rather than oldest microversion by default - and the change to flavor broke sdk | |
| 15:15:11 | mordred | efried: yay for testing | |
| 15:19:33 | mordred | gtema: didn't we have code in sdk that was supposed to cause sdk to skip trying to do version discovery for swift? | |
| 15:19:56 | gtema | yes - skip_discovery in proxy | |
| 15:20:00 | mordred | like - I feel like we had it - then I forgot about it and wrote it again | |
| 15:20:22 | mordred | gtema: then why is https://07f03003afd3ca1f2387-1738d3a5d5585f54500f5c8600ed53a6.ssl.cf1.rackcdn.com/685042/4/check/openstacksdk-functional-devstack-tips/64dae12/testr_results.html.gz | |
| 15:20:31 | mordred | openstack.tests.functional.object_store.v1.test_account.TestAccount | |
| 15:20:39 | mordred | doing version discovery gets? | |
| 15:21:03 | gtema | that's a different story :D | |
| 15:21:15 | mordred | (I know why they're broken - that's the ksa patch - but upon reflection, why are we doing them in the first place?) | |
| 15:21:54 | gtema | perhaps something else in your patches? lemme try in my cloud fast | |
| 15:22:03 | mordred | gtema: oh! | |
| 15:22:07 | mordred | gtema: it's the test itself | |
| 15:22:35 | mordred | gtema: the functional base test has a "require_service" method which we have a todo to replace | |
| 15:22:47 | mordred | which is doing an explicit get_endpoint_data | |
| 15:22:56 | gtema | aah, ok. In real life discovery is not done for swift | |
| 15:23:00 | mordred | yeah | |
| 15:23:28 | mordred | so - I think ksa should throw a better error in the case that someone tries this - but I also think we should fix these tests | |
| 15:23:33 | mordred | this is a fun rabbit hole | |
| 15:25:26 | gtema | agree. But I like the approach of passing auth to endpoint if we got exception | |
| 15:25:32 | mordred | ++ | |
| 15:25:34 | gtema | I have it in my cloud everywhere | |
| 15:26:10 | gtema | and this is exactly what I was pointing in the API-SIG rework about version discovery | |
| 15:26:24 | gtema | those clear requirements were lost | |
| 15:32:03 | efried | mordred: Is sdk *supposed* to be getting the newest rather than the oldest microversion by default? (by design) | |
| 15:32:15 | mordred | nope | |
| 15:32:34 | efried | okay, reread your first message, got it. | |
| 15:32:44 | mordred | so - you know - bugs all around :) | |
| 15:32:49 | efried | Though I would imagine specific operations would explicitly use newer microversions under the covers. | |
| 15:32:55 | mordred | yes - absolutely! | |
| 15:33:02 | mordred | and for those it should absolutely use them | |
| 15:33:37 | efried | but, like, something where /foo changes payload formats with different microversions, and we have a foos() method, I guess we would need you to tell us which shape you wanted the response to take. | |
| 15:33:42 | mordred | we just might need to take additional action sdk-side to keep the sdk api consistent, so we want to opt-in to microversion changes (which is one of the reasons I've become an ardent supporter of microversions) | |
| 15:33:52 | efried | unless we obscure all of that by objectifying the response | |
| 15:34:06 | efried | but there again, some fields might be present/absent depending | |
| 15:34:32 | mordred | yah- in the normal shade and sdk layer, we obscure by objectifying. if you want the REST layer and know what you're doing, requesting like 2.latest should be fine | |
| 15:35:02 | efried | presumably the microversion kwarg passes through request() seamlessly still? | |
| 15:35:07 | mordred | yup | |
| 15:35:19 | efried | yeah, it must, because we're using it for placement from nova | |
| 15:35:34 | mordred | fields being different, specifically flavor, is what caused the tests to catch that the ksa 401 fix had unbroken a discovery thing that was accidentally keeping sdk working properly :) | |
| 15:35:40 | efried | ...unless we're getting the latest, which would also be working without us knowing... | |
| 15:36:04 | efried | yeesh, so we have to fix ksa and then blacklist the fix from sdk until we fix sdk? | |
| 15:36:19 | mordred | no - we can fix sdk before we fix ksa | |
| 15:36:21 | efried | I had a mentor early in my career who called this RBB | |
| 15:36:25 | efried | Revoked Bug Benefit | |