| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-12-01 | |||
| 19:57:22 | dhellmann | I think that's the point of running that job, yes | |
| 19:58:32 | openstackgerrit | Merged openstack/python-openstackclient master: Add cliff and keystoneauth to tips jobs https://review.openstack.org/524639 | |
| 19:58:49 | dhellmann | it looks like we're still waiting for jobs to pass on my patch at the bottom of that stack | |
| 19:58:57 | mordred | cool. once dtroyer has the -tips job fixed I can put up a patch to switch that over, and we'll be done with legacy jobs across osc, sdk and cliff | |
| 19:59:06 | mordred | yah - the legacy devstack job is taking its sweet time | |
| 20:01:10 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Fix SDK Connection creation alternative to Profile https://review.openstack.org/523938 | |
| 20:01:11 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: Rework Network client config for new SDK Connection https://review.openstack.org/524715 | |
| 20:01:27 | mordred | dhellmann, dtroyer: also, fwiw, I put up a patch to keystoneauth to run osc, sdk and shade functional tests on keystoneauth changes - so I think we're actually getting into a really good place in terms of cross-testing these base-level pieces \o/ https://review.openstack.org/#/c/524656/ | |
| 20:01:35 | mordred | ooh. that looks like a fix from dtroyer | |
| 20:01:40 | dtroyer | fwiw, the last run of my test timed out but I think I've got it all, ^^^ are the two that get this into production shape | |
| 20:02:02 | dtroyer | so if they look good and work they can merge | |
| 20:02:35 | mordred | woot | |
| 20:02:46 | dtroyer | I'm prepping the osc-lib part of that but I want this to merge first and put a little time on the compat code path | |
| 20:03:16 | mordred | dtroyer: ++ | |
| 20:18:24 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Start using Connection in openstack.cloud https://review.openstack.org/523259 | |
| 20:18:50 | openstackgerrit | Monty Taylor proposed openstack/python-openstacksdk master: Remove get_legacy_client https://review.openstack.org/523483 | |
| 20:38:44 | mordred | dtroyer: wow. https://review.openstack.org/#/c/524670 has failed functional tests twice - but neither time has it had anything to do with the patch, and the two times were not for the same reason | |
| 21:09:41 | dtroyer | mordred: yup, it had been behaving for a bit, aggregates is one of the usual problem children. volumes had been a big one for a while, Cinder team sorted out at least some of that but I've noticed those returning again too. | |
| 21:10:01 | dtroyer | I've spent a good bit of time removing races from our tests, so that's also some of the trouble | |
| 21:13:50 | openstackgerrit | Merged openstack/python-openstacksdk master: Remove openstack-tox-pypy jobs https://review.openstack.org/524651 | |
| 21:13:51 | openstackgerrit | Merged openstack/python-openstacksdk master: Cleanup objects that we create on behalf of images https://review.openstack.org/522974 | |
| 21:13:52 | openstackgerrit | Merged openstack/python-openstacksdk master: Add method to cleanup autocreated image objects https://review.openstack.org/522975 | |
| 21:13:53 | openstackgerrit | Merged openstack/python-openstacksdk master: Complete move of baremetal machine tests https://review.openstack.org/522976 | |
| 21:18:50 | dtroyer | mordred: so what did I do wrong? the functional-tips jobs are not running since some time this morning... | |
| 21:19:12 | dtroyer | the one that timed out earlier is the last one I've seen | |
| 21:21:06 | slaweq | dtroyer: hi again | |
| 21:21:15 | slaweq | dtroyer: thx for Your comment in https://review.openstack.org/#/c/515401 | |
| 21:21:23 | slaweq | I have one more question to You about this patch | |
| 21:21:26 | dtroyer | ok | |
| 21:21:34 | slaweq | can You see my last comment on it maybe? | |
| 21:21:41 | slaweq | thx in advance | |
| 21:22:30 | dtroyer | I would not add the —details option to the show command | |
| 21:22:47 | dtroyer | show commands already return everything they receive from the API | |
| 21:23:10 | slaweq | yes, I know | |
| 21:23:22 | dtroyer | it would only be doing additional queries for things in the resource fields (looking up image names for example) that we add to show, normally | |
| 21:23:24 | slaweq | but I was asking about list command | |
| 21:23:54 | dtroyer | the comment asks about quota show, did you mean list there? | |
| 21:23:56 | slaweq | but list command currently is IMHO returning quota per tenant | |
| 21:24:17 | slaweq | sorry, maybe I don't understand something still | |
| 21:24:18 | slaweq | so | |
| 21:24:32 | dtroyer | ok I may have misread that then | |
| 21:24:46 | dtroyer | in "change its behaviour" you man list? | |
| 21:24:50 | slaweq | I understood that You want to add "--detail" flag to list command instead of show (like it is currently proposed), right? | |
| 21:24:52 | dtroyer | s/man/mean/ | |
| 21:24:59 | slaweq | yes, I mean list | |
| 21:24:59 | dtroyer | yes | |
| 21:25:38 | slaweq | so, AFAIU list command currently lists "non default" quota for all tenants | |
| 21:26:05 | slaweq | I want to add call which will return quota values for one tenant only | |
| 21:26:17 | dtroyer | ok, then I get it. and yes, sometimes we do change things about how list commands based on options. I should probably think about it a bit deeper to be sure, but we may want to add some options to do those sorts of selections, and leave the defaults to get what we have today | |
| 21:26:22 | dtroyer | does that make sense? | |
| 21:26:53 | dtroyer | normally, for one tenant, we would add —project for the filter, or something (I can't rememner exactly what) to use the tenant used for auth | |
| 21:27:32 | slaweq | so You propose to add some option (detail) to list command instead of show command | |
| 21:27:40 | dtroyer | yes | |
| 21:27:48 | slaweq | and this option will change behaviour of List command | |
| 21:27:54 | dtroyer | yes | |
| 21:27:59 | slaweq | and different data will be returned | |
| 21:28:09 | slaweq | ok, I understand now | |
| 21:28:20 | slaweq | I will try to do it this way then | |
| 21:28:20 | slaweq | thx | |
| 21:28:24 | dtroyer | by different, you mean they are still quotas, but filtered differently? | |
| 21:28:32 | slaweq | yes, still quota | |
| 21:28:42 | dtroyer | yes, that is it | |
| 21:28:49 | slaweq | but only for one tenant but with details about used/reserved/limit values | |
| 21:28:59 | dtroyer | how do you select the tenant? | |
| 21:29:02 | slaweq | instead of list of tenants and limits for each of them | |
| 21:29:30 | slaweq | probably it will be taken from context or set by project_id parameter | |
| 21:29:39 | dtroyer | ok, that should work | |
| 21:29:42 | slaweq | I will see how it's done now for "show" command | |
| 21:30:37 | dtroyer | it may make sense to re-think the entire quota command set, we can make breaking changes for osc 4.0 if this is getting too awkward | |
| 21:31:34 | slaweq | ok, I will start doing that and I will see how it will go :) | |
| 21:31:43 | slaweq | but thx a lot for Your help on that | |
| 21:31:48 | dtroyer | thank you for staying with this! | |
| 21:32:02 | slaweq | no prob | |
| 21:37:35 | mordred | dtroyer: oh, like they are not even executing ... lemme look | |
| 21:38:38 | dtroyer | I'm not sure where to look for that | |
| 21:43:29 | htaccess | question did shade used to require openstacksdk and python-openstackclient but no longer does | |
| 21:44:26 | htaccess | it looks to me that in 1.24.0 and earlier shade was pulling in openstacksdk and python-openstackclient but not longer does with 1.25.0 | |
| 21:44:48 | dtroyer | before the merge, shade did not require the SDK or OSC, it originally used the project python libs, then brought al of that internal. | |
| 21:45:06 | dtroyer | I don't have an older shade handy, is either of those listed in requirements.txt? | |
| 21:45:16 | dtroyer | they may be in test-requirements.txt to do testing | |
| 21:50:57 | htaccess | diff shade-1.25.0/requirements.txt shade-1.24.0/requirements.txt only shows six and futures version changes | |
| 21:51:26 | htaccess | are the packages in test-requirements.txt actually installed when you do a pip install? | |
| 21:52:38 | mordred | htaccess: openstacksdk and python-openstackclient have in the past come as transitive depends via python-ironicclient | |
| 21:52:49 | htaccess | mordred: that makes more sens | |
| 21:53:36 | htaccess | so its probably due to python-ironicclient not pulling them in any more | |
| 21:53:54 | mordred | yah. it looks like python-ironicclient finally removed the dep on python-openstackclient | |
| 21:54:14 | htaccess | anyway it was silly to be relying on them being pulled in ill actaully put them in my requirements.txt if they are requirments :) | |
| 21:54:17 | htaccess | thanks | |
| 21:54:21 | mordred | although we're also about to drop our depend on python-ironicclient ... so the transitive depend wouldhave cone away as of 1.26 anyway | |
| 21:54:30 | mordred | htaccess: woot! | |
| 21:54:33 | htaccess | :) | |
| 21:54:53 | mordred | htaccess: now - in the not-too-distant future shade will grow a depend on openstacksdk ... but that's unlikely before january I'd guess | |
| 21:55:18 | htaccess | ah, interesting | |
| 21:57:33 | mordred | htaccess: tl;dr - we merged the shade code in to sdk, and once we're happy with the shape of that, we'll turn shade the library into a thin backwards-compatibility shim on top of the shade-derived functionality in sdk | |
| 21:58:12 | mordred | but I want to make sure we're happy with how it's working sdk-side before we start mucking with consuming it from shade | |
| 22:01:01 | openstackgerrit | Carlos Konstanski proposed openstack/python-openstackclient master: openstack subnet create fails when tags is None https://review.openstack.org/524739 | |
| 22:01:23 | mordred | dtroyer: hrm. | |
| 22:02:02 | htaccess | ah ok, so in the future i will be able to install openstacksdk and get shade plus whats already in the sdk? | |
| 22:03:25 | mordred | htaccess: yup | |
| 22:09:38 | mordred | dtroyer: I've looped in jeblair to help me look :) | |