| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-11-29 | |||
| 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 ... | |
| 14:31:35 | mordred | adriant: good point re: yaml=False - I think what we want is a "make me one of these and only use the kwargs I'm passing, not other stuff | |
| 14:37:03 | mordred | adriant: for the other thing, good to know - I know the shade layer for swift objects is good and also support for the 'use head to check if it exists' use case | |
| 14:38:00 | mordred | adriant: as we work through rationalizing the shade and sdk layers, we'll make sure to fix that SDK brokenness you just reported (thanks for that btw) | |
| 14:38:56 | mordred | adriant: hopefully we'll at least have a $something you can use related to the new-world-order soonish | |
| 14:42:08 | mordred | dhellmann: morning mr. "I know literally every python module that exists" ... I think I remember there being some sort of module that would let you execute example code from docs as part of tests ... do you know if that's a thing or if I'm just dreaming it? | |
| 14:44:41 | cmurphy | mordred: i've heard of that, i think it's this https://docs.python.org/2/library/doctest.html | |
| 14:45:55 | mordred | cmurphy: ah! yes - that's what I was thinking of, thanks! | |
| 14:46:20 | mordred | cmurphy: I wrote some example docs yesterday, but it turns out the examples I wrote don't work ... made me think testing examples in docs would be a good idea | |
| 14:47:13 | mordred | although that module isn't *quite* what I was thinking - maybe I could either add support for the usage pattern I was considering, or use it as inspiration to write a thing | |
| 14:48:27 | mordred | basically very similar to https://docs.python.org/2/library/doctest.html#simple-usage-checking-examples-in-a-text-file - but finding .. code-block: python sections in rst files, and not requiring them to be interactive sessions | |
| 14:49:06 | mordred | it's also possible that in this particular case it needs to be specific to shade/sdk codebase, as I probably want a requests_mock thing set up ... | |
| 14:53:24 | mordred | rcarrillocruz, Shrews, jlk: https://github.com/ansible/ansible/pull/20974 has been updated (the rebase on that SUCKED) | |
| 15:02:07 | Shrews | mordred: seems to have failed tests still | |
| 15:24:26 | mordred | yah - I'll fix that next | |
| 15:24:38 | mordred | Shrews: sake of argument, what do you think about this: https://gist.github.com/ce8b1c90cf972bfc104e3eb38ae74762 as an alternative approach? | |
| 15:34:59 | Shrews | mordred: hmm, i sort of like that | |
| 15:35:51 | mordred | Shrews: cool, me too ... jlk, rcarrillocruz, SamYaple: ^^ what about y'all ? | |
| 15:36:16 | rcarrillocruz | think latter is cleaner | |
| 15:52:45 | thingee | mordred: where are these roles defined again? https://review.openstack.org/#/c/523993 | |
| 15:53:23 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: DNM: Test -tips variations https://review.openstack.org/523938 | |
| 15:54:10 | cdent | api-sig meeting in #openstack-meeting-3 in a few minutes | |
| 15:59:12 | mordred | thingee: in that case, tox-siblings is/was defined in openstack-infra/zuul-jobs | |
| 15:59:21 | thingee | was? | |
| 15:59:46 | mordred | thingee: yah - the patch above is part of a sequence that removes the tox-siblings role - we combined its functionality into the main tox role | |
| 15:59:56 | thingee | got it | |
| 16:00:00 | thingee | right | |
| 16:00:12 | mordred | thingee: but we needed to remove use of it first - that patch chain is a fun DAG of depends-on changes :) | |
| 16:00:29 | mordred | I sohuld have left needed-by comments on everything to make it easier to follow :) | |
| 16:00:42 | mordred | thingee: here's teh final patch: https://review.openstack.org/#/c/523996 | |
| 16:01:15 | mordred | thingee: that depends on all of the changes to remove the use of the role, which all in turn depends-on the change to move the functionality from tox-siblings into tox | |
| 16:02:15 | SamYaple | mordred: yea seems ok. im not too fussy as long as its consistent | |
| 16:03:38 | thingee | mordred: I can't even find ensure-tox role being defined | |
| 16:06:05 | mordred | thingee: http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/ensure-tox | |
| 16:06:28 | mordred | thingee: we have a todo-list item to have zuul generate a global documentation of all the jobs and roles | |
| 16:06:41 | thingee | mordred: ah ha, that's why I didn't find it. | |
| 16:07:31 | mordred | thingee: we have them for each jobs/roles repo: https://docs.openstack.org/infra/zuul-jobs/ ... but since zuul knows about ALL of the jobs and roles, we figurehaving something like zuul.openstack.org/docs that has an index of all the jobs and roles, links to where they're defined, and their documentation would be *very* helpful | |
| 16:08:18 | thingee | mordred: are you just looking for an auto generate approach? | |
| 16:08:37 | mordred | thingee: we've also talked about adding support for some explicit 'import' statements in .zuul.yaml files - along with namespacing - so you could say "import git.openstack.org/openstack-infra/zuul-jobs as zuul_jobs and then refer to things like zuul-jobs.tox-pep8 ... *handwave* | |
| 16:09:19 | mordred | thingee: kind of - there are two sides to the coin - one is an index of jobs - that's already very close to being done in the new web dashboard ... | |
| 16:10:18 | mordred | thingee: the second part is generating the docs - we're using sphinx in a post job right now, but if we want zuul to just have an always up to date dynamic listing of the docs, we might not want to delegate that to sphinx and may instead want to just read the rst ourselves? that part is still undefined | |
| 16:11:11 | mordred | thingee: fwiw, https://review.openstack.org/#/q/topic:zuul-web+(status:open+OR+status:merged) is the series tristanC has been working on related to adding a web dashboard | |
| 16:12:56 | thingee | mordred: ok, I went through your series for removal in other project's pre.yaml files. | |
| 16:13:00 | thingee | only +1 | |
| 16:13:02 | thingee | s :) | |
| 16:16:17 | mordred | thingee: woot! thanks | |
| 16:31:49 | rcarrillocruz | mordred: so, talking to evrardjp at summit that, well, our os_* modules lacking integration tests was less than ideal. I was thinking of adding tests on our ansible zuul, but if we are going to test them at openstack-infra, can I just start writing them? | |
| 16:32:05 | rcarrillocruz | my understanding is that we already get webhooks from ansible/ansible | |
| 16:32:12 | rcarrillocruz | so we could potentially just start ? | |
| 16:32:34 | mordred | rcarrillocruz: yes- the plan is to start running the shade-ansible-functional-devstack jobs on them | |
| 16:33:07 | rcarrillocruz | is that on hold till zuul v3, or just pending | |
| 16:33:09 | mordred | rcarrillocruz: we are getting the webhooks already, but we're waiting just a little longer - we're still having a few scale issues with the gh app and missing events | |