| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-11-29 | |||
| 21:50:35 | mordred | TheJulia, Shrews: +2 with comment on https://review.openstack.org/#/c/499774/3 - comment applies to the previous patch too (which is already +A'd) - I think it's totally fine for us to deal with in a followup | |
| 21:52:06 | mordred | TheJulia: also, I think there is a rebase oops in https://review.openstack.org/#/c/500119/3 | |
| 21:52:24 | openstackgerrit | Merged openstack-infra/shade master: Fix basepython setting in tox.ini https://review.openstack.org/523915 | |
| 21:53:16 | TheJulia | mordred: replied, and agreed, I'll rip that out in the morning. | |
| 21:53:25 | Shrews | what's funny is, that it still passed tests | |
| 21:53:44 | Shrews | s/funny/sad/ ?? | |
| 21:54:18 | TheJulia | wow... fun rebase failure :( | |
| 21:57:07 | openstackgerrit | Julia Kreger proposed openstack-infra/shade master: De-clientify baremetal create/delete https://review.openstack.org/500119 | |
| 21:57:14 | openstackgerrit | Julia Kreger proposed openstack-infra/shade master: De-client-ify baremetal machine port list https://review.openstack.org/500120 | |
| 21:57:30 | mordred | TheJulia: AHA - normalize_machines only removes novaclient noise - I was wondering how the old method worked with normalize_machines(MachienPortList()) :) | |
| 21:58:06 | TheJulia | mordred: my guess, cp -a python-novaclient python-ironicclient | |
| 22:01:17 | mordred | TheJulia: also, left a note for later in https://review.openstack.org/#/c/500119 - I don't think we should do anything about it today or tomorrow | |
| 22:01:30 | mordred | TheJulia: thank you for leaving the comment there though - it was very helpful :) | |
| 22:01:43 | openstackgerrit | Julia Kreger proposed openstack-infra/shade master: De-client-ify machine patch operations https://review.openstack.org/500121 | |
| 22:02:37 | mordred | TheJulia, Shrews: stack up to the WIP is all +2 from me. | |
| 22:02:51 | adriant | tiple services in the same connection object was odd). | |
| 22:02:51 | adriant | Out of curiosity, for the openstackSDK, if "param profile: DEPRECATED" what am I meant to use in code programatically to define what region I need to talk to? The docs for openstackSDK do not mention the profile deprecation, and as much as I dislike the profile mechanism, it made sense (although the ability/need to define a different region for mul | |
| 22:03:16 | mordred | TheJulia: THANK YOU! I think as soon as that last patch lands we should cut another release, since removing that depend will make life **WAY** easier on packagers | |
| 22:03:38 | mordred | adriant: that'sa great question - and we should clearly make a document about that | |
| 22:03:46 | mordred | adriant: one second - lemme link you to something | |
| 22:04:01 | TheJulia | mordred: awesome, I'm going to disappear shortly for at least the next few hours | |
| 22:04:22 | TheJulia | mordred: I just feel bad I'm just now getting to it.... | |
| 22:05:00 | adriant | mordred: I'm trying to switch a bunch of tools to openstackSDK, but none of them rely on clouds.yaml (it doesn't make sense to) and I need to pass in config stuff. From keystoneauth I can get my session, find, but region I've always done with profile. | |
| 22:05:05 | mordred | adriant: well, this isn't nearly as useful a link as I'd hoped, but ... | |
| 22:05:15 | mordred | http://git.openstack.org/cgit/openstack/python-openstackclient/tree/openstackclient/network/client.py#n39 | |
| 22:05:38 | adriant | mordred: that still uses profile :P | |
| 22:05:41 | mordred | adriant: yah- the answer for you is gonna be to make a CloudConfig object basically just like you've been making a profile | |
| 22:06:02 | mordred | adriant: lemme make a quick patch to something else that shows the ACTUAL answer | |
| 22:06:02 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Release note cleanup https://review.openstack.org/524004 | |
| 22:06:07 | mordred | adriant: and also a doc patch :) | |
| 22:06:53 | adriant | mordred: k, I had a feeling i'd end up having to make a config object :P | |
| 22:07:03 | mordred | adriant: out of curiosity - do you want your use to explicitly *not* support clouds.yaml - or more you don't have any clouds.yaml and don't care | |
| 22:07:28 | mordred | (example patch is different depending on which of those is true - I should probably make both examples) | |
| 22:08:02 | adriant | mordred: the thing I'm working on in question is a django site/service that has it's own config file. So clouds.yaml doesn't make sense. | |
| 22:08:12 | mordred | adriant: nod. cool - example coming | |
| 22:08:15 | adriant | same again with a different API service I've got | |
| 22:08:33 | adriant | then the rest of my tools are built on top of the openstackclient, so they natively just use clouds.yaml | |
| 22:09:19 | adriant | I find that if I'm writing any scripts for openstack, I just make them an openstackclient plugin and forget all the tiresome stuff and focus on functionality | |
| 22:09:53 | adriant | mordred: and thanks :) | |
| 22:31:31 | mordred | adriant: https://review.openstack.org/524011 Update openstacksdk construction to be forward compatible | |
| 22:32:05 | mordred | adriant: I'm going to extract that into a proper doc - but that should have all the pieces you need (and more) | |
| 22:34:02 | openstackgerrit | Merged openstack-infra/shade master: De-client-ify baremetal node_set_provision_state https://review.openstack.org/499773 | |
| 22:38:53 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Release note cleanup https://review.openstack.org/524004 | |
| 22:42:44 | adriant | mordred: ty, and love the comment | |
| 22:46:17 | mordred | adriant: :) | |
| 22:48:35 | adriant | mordred: I have to admin, that's much nicer than the profile stuff. The profile stuff was my main reason for not liking the SDK since it just seemed overcomplicated | |
| 22:48:40 | adriant | admit* | |
| 22:49:29 | adriant | like sure, you could have swift in one region, nova in another, and cinder in a third, all in the same connection object. the question though is why!? | |
| 23:05:30 | adriant | mordred: and the thing you were talking about at the summit was "get_session_client" right? So in the context of openstackSDK you can just do raw API calls if the code doesn't support the feature you. | |
| 23:06:36 | adriant | mordred: but that appears to be on the config class, rather than the connection/service class. Which means I need to keep the config class around if I need to call APIs directly, or is there a way I can get at that on the connection/service class? | |
| 23:07:49 | adriant | I was imagining it as "resp = conn.object_store._client.get("/thing") | |
| 23:09:03 | adriant | I'm sure the adapter is in there somewhere, and i can probably find it by trawling the code some more, just was curious if there was a nice way to do access it. | |
| 23:25:25 | adriant | mordred: also, a passthrough or shortcut for "OpenStackConfig(load_yaml_config=False).get_one_cloud" might not be a bad idea. Since we shouldn't assume clouds.yaml is the default. It's only the default from a cli/tools perspective, and we really should make use the SDK in services and such much easier. Or at least initialising it. | |
| 23:31:18 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Add some docs about not using Profile https://review.openstack.org/524021 | |
| 23:32:00 | mordred | adriant: sorry - was writing that ^^ | |
| 23:32:35 | mordred | adriant: SO - in the master branch currently you don't need do do a get_session_client at all - once you have a connectoin, each service's Proxy object is actually also an Adapter | |
| 23:32:46 | mordred | adriant: so you can do conn.compute.get('/foo') | |
| 23:35:11 | mordred | adriant: also, fwiw, the service proxy objects all all by service_type as per the service type registry, and there's also one for any known alias ... although still todo is to make sure old aliases like volumev2 actually construct appropriately versioned adapters | |
| 23:35:42 | mordred | adriant: AND - yes, definitely shortcuts such as what you say - there are several littered about, but we need to rationalize it all since the codebase merges | |
| 23:36:47 | mordred | adriant: so, like, in master, you can do "import openstack ; openstack.connect(**parameters_you_would_have_passed_to_get_one_cloud)" | |
| 23:37:45 | SamYaple | TheJulia: w00t! congrats on getting whiskey chicken. seems like a fair trade for that work (now you just have to hold monty to it) | |
| 23:39:23 | mordred | adriant: maybe we should make 2 factory functions - one for no-clouds.yaml and one for yes-clouds.yaml ... cause for utility scripts I gotta tell you I would never ever use not clouds.yaml and the extra typing to turn on loading the files would drive me batty | |
| 23:39:49 | mordred | adriant: *waves hands* ... fundamentally, totally agree with the things you're saying, we can work out what the shortcut things do pretty easily so we're all happy :) | |
| #openstack-sdks - 2017-11-30 | |||
| 00:03:04 | openstackgerrit | Monty Taylor proposed openstack/cliff master: Remove tox_install.sh and just pass -c in tox https://review.openstack.org/523984 | |
| 00:03:04 | openstackgerrit | Monty Taylor proposed openstack/cliff master: Move doc requirements to doc/requirements.txt https://review.openstack.org/522369 | |
| 00:03:05 | openstackgerrit | Monty Taylor proposed openstack/cliff master: DNM testing docs and releasenotes jobs https://review.openstack.org/522370 | |
| 00:40:21 | adriant | mordred: fantastic! :) | |
| 00:41:14 | adriant | mordred: and yeah, I don't think making clouds.yaml harder to use is right, just that, we should make it equally easy to use either. :) | |
| 00:42:24 | adriant | mordred: because for the longest time I always felt that the openstackSDK was tailored more towards clouds.yaml stuff rather than : "I'm an API service which needs to talk to another service." which is more my primary use case. | |
| 00:43:01 | adriant | while the python-<service>clients always felt far better to just throw a session at, and then use. | |
| 01:20:09 | TheJulia | SamYaple: Wait... is there a real whiskey chicken thing?!? | |
| 01:33:35 | openstackgerrit | Merged openstack-infra/shade master: de-client-ify baremetal get_machine https://review.openstack.org/499774 | |
| 01:44:01 | adriant | mordred: I'm going to be opening a lot of issues for the sdk over the next while as I find things that don't quite work as expected, or are missing. Should I be doing that here: https://storyboard.openstack.org/#!/project/760 ? | |
| 01:44:30 | adriant | I mean, now that shade == openstacksdk that makes sense, but just curious. | |
| 01:44:49 | adriant | the launchpad page seem ancient so I assume bugs aren't tracked there. | |
| 01:48:54 | openstackgerrit | Merged openstack-infra/shade master: Catch attrbute error for other APIs https://review.openstack.org/499775 | |
| 02:25:40 | openstackgerrit | Merged openstack/python-openstackclient master: Release note cleanup https://review.openstack.org/524004 | |
| 03:33:01 | openstackgerrit | Hengqing Hu proposed openstack/python-openstacksdk master: Add pools attribute to load balancer heath monitor https://review.openstack.org/522962 | |
| 04:57:14 | SamYaple | TheJulia: you can put whiskey in anything if you try hard enough | |
| 04:57:47 | TheJulia | SamYaple: Indeed, although I think most people will prefer a glass of some sort. | |
| 05:22:00 | openstackgerrit | Adrian Turjak proposed openstack/python-openstacksdk master: Stop osSDK mangling Swift metadata keys https://review.openstack.org/524066 | |
| 05:25:53 | adriant | mordred: potentially awkward, but even with yaml=False, calling 'get_one_cloud' without a cloud name, it will look in local OS_* envvars. Which might be good to also disable/avoid as well as yaml checking. | |
| 05:26:49 | adriant | not that it really is likely to crop up much, but still a little weird because of how I was testing stuff. I didn't realise I had set any vars, and it seemed to pick them up and yell at me for providing domain name for token auth. | |
| 05:34:32 | adriant | hmmmm... anyone here who has played with swift support in the openstackSDK? | |
| 05:34:54 | adriant | I'm trying to do HEAD on a container to see if it exists before I try creating it. | |
| 05:35:28 | adriant | but well... `x = conn.object_store.get_container_metadata('not_a_real_container')` returns a valid resource object | |
| 05:35:40 | adriant | it's not a 'real' container | |
| 05:35:58 | adriant | but it has some attrs | |
| 05:36:19 | adriant | I can't for the life of me find a value to say "this is not a real container" | |
| 05:36:30 | adriant | which is broken | |
| 05:36:33 | adriant | like, pretty broken | |
| 05:36:55 | adriant | swiftclient sucks, but at least it throws a 404 type error | |
| 05:38:42 | adriant | `x = conn.compute.get_server("not a real server")` does throw an error | |
| 05:40:33 | adriant | `x = conn.object_store.get_object_metadata("not a real container", "fake object")` also returns a not none value :/ | |
| 05:41:32 | adriant | while `x = conn.object_store.get_object("not a real container", "fake object")` returns: '<html><h1>Not Found</h1><p>The resource could not be found.</p></html>' | |
| 05:41:40 | adriant | wow, object_store in the SDK is broken | |
| 05:42:35 | adriant | I think this is a good time to call it quits for today... | |
| 08:35:01 | ldl | can I through the server id to get the server image snapshots? | |
| 10:43:46 | openstackgerrit | Édouard Thuleau proposed openstack/python-openstacksdk master: Set empty Tag list if Network Tag API extension not supported https://review.openstack.org/523834 | |
| 14:31:07 | mordred | adriant: morning! so ... | |