Earlier  
Posted Nick Remark
#openstack-sdks - 2017-12-01
16:50:32 amotoki mordred: honestly i am not sure cliffdemo is worth published to pypi
16:50:55 amotoki mordred: the current cliffdemo in PyPI is really old
16:51:04 mordred amotoki: it's already published there- that's how it was being installed before your patch
16:53:18 amotoki mordred: yes. it works with cliffdemo in PyPI, but cliffdemo itself is mainly for demo purpose (+ test for the sphinx directive)
16:53:38 mordred amotoki: totally. however, there is already precedent - openstack-release-test is in global-requirements for a similar reason
16:53:48 amotoki mordred: i am not sure what is the right solution. I would like to hear opinion of dhellmann
16:54:16 mordred amotoki: agree. definitely want his opinion :)
16:57:00 mordred amotoki, dhellmann: for sake of argument, here's a g-r patch adding it: https://review.openstack.org/524678 Add cliffdemo
17:22:24 openstackgerrit Merged openstack/cliff master: Use in-tree cliffdemo app for docs build https://review.openstack.org/515016
17:32:22 mordred dtroyer: https://review.openstack.org/#/c/522977 https://review.openstack.org/#/c/522978 https://review.openstack.org/#/c/522979 and https://review.openstack.org/#/c/522980 are cherry-picks of occ patches
17:32:44 mordred dtroyer: and https://review.openstack.org/#/c/523483/6 is a non-cherry-pick that touches that section of the code
18:10:16 openstackgerrit Merged openstack/python-openstacksdk master: Add pools attribute to load balancer heath monitor https://review.openstack.org/522962
18:22:46 openstackgerrit Doug Hellmann proposed openstack/cliff master: do not require installing demo app to build docs https://review.openstack.org/524695
18:32:32 thingee dtroyer, mordred with https://review.openstack.org/#/c/523834/3 and https://review.openstack.org/#/c/516701/7/openstackclient/network/common.py extensions being proposed in osc and python-openstacksdk, perhaps we can have some common extension checking code for the existing cases, but stop accept new cases?
18:38:12 openstackgerrit Monty Taylor proposed openstack/cliff master: Move doc requirements to doc/requirements.txt https://review.openstack.org/522369
18:38:13 openstackgerrit Monty Taylor proposed openstack/cliff master: Replace legacy tips jobs with shiny new versions https://review.openstack.org/524643
18:38:13 openstackgerrit Monty Taylor proposed openstack/cliff master: Remove tox_install.sh and just pass -c in tox https://review.openstack.org/523984
18:38:14 openstackgerrit Monty Taylor proposed openstack/cliff master: DNM testing docs and releasenotes jobs https://review.openstack.org/522370
18:38:22 mordred dhellmann: ^^ reparented on your patch
18:38:40 dhellmann mordred : looking
19:06:25 mordred stevemar: responded to https://review.openstack.org/#/c/524670 - I can update it to move the branch exclusion down into the project tepmlate if you prefer
19:37:54 openstackgerrit Monty Taylor proposed openstack/cliff master: DNM testing docs and releasenotes jobs https://review.openstack.org/522370
19:47:19 mordred dhellmann: zomg. ^^ passes!!!
19:56:42 dhellmann mordred : woot!
19:56:58 mordred dhellmann, dtroyer: cliff runs legacy-tempest-dsvm-neutron-src ... I think (once it's solid) that osc-functional-devstack-tips would be a good replacement for that - since hte point would be to make sure that patches to cliff don't break devstack by breaking osc, right?
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

Earlier   Later