Earlier  
Posted Nick Remark
#openstack-sdks - 2018-08-16
14:39:23 rabel mordred: so it will always exist, but in the future it will only be calling openstacksdk ?
14:39:41 dtroyer gtema: pip is the fun part and why capping in cliff isn't enough, it needs to be capped everywhere it is called out in order to guarantee pip does the right thing.
14:39:59 mordred rabel: yes
14:40:12 rabel ok, thanks you two
14:40:20 mordred rabel: the idea is to maintain shade's api contract with its users so that the dev re-org doesn't break anyone
14:40:21 dtroyer making the cap in global-requirements is probably the right thing but that is no longer enforced automatically, we'll have to make that change in osc and osc-lib, etc
14:41:35 gtema dtroyer: change in cliff is not passing checks, so I assume it is required it modify upper_constants in "requirements"
14:43:03 dtroyer gtema: this has shifted recently and I don't have it all in my head anymore, possibly yes. I haven't looked at those cliff jobs yet, if they are the functional test it still may be to requirements in osc-lib or osc
14:43:59 gtema dtroyer: no, it's one the one hand job "requirements-check", which complains on requirements conflict, and then osc-tox-unit-tips
14:44:22 gtema s/osc-tox-unit-tips/cliff-tox-py27-neutronclient-tip/
15:32:13 openstackgerrit Merged openstack-infra/shade master: Fix format in release notes https://review.openstack.org/592507
15:32:24 mordred rabel: ^^ thanks!
15:40:26 edleafe cdent: Can you or dtantsur|afk run the API-SIG meeting? I'm pretty distracted by my all-day meeting stuff
15:42:42 cdent aye
17:07:28 edleafe cdent_: Ready for your review: https://etherpad.openstack.org/p/api-sig-newsletter
17:11:03 cdent_ edleafe: add the review in [12] to the pending review section? otherwise ok
17:11:59 edleafe cdent_: ah, good catch. Skipped updating that section.
17:13:54 edleafe Fixed. Good to go?
17:14:37 cdent_ yup, ship it
17:17:17 edleafe done
18:52:17 harlowja anyone seen anything like http://paste.openstack.org/raw/728226/ with shade recently?
18:53:30 mordred harlowja: no- but that doesn't look good
18:53:43 harlowja ya, that popped out of our latest kolla-ansible daily run
18:54:31 harlowja https://imgur.com/a/146tl8f pew pew pew, lol
18:54:47 harlowja `File \"/usr/lib/python2.7/site-packages/shade/********cloud.py` is weird, lol
18:54:55 harlowja secret cloud, lol
18:55:45 mordred SO SECRETS
18:57:16 harlowja ya
18:57:51 harlowja `_normalize.py` seems to have left the building in 1.29
19:05:38 harlowja ya, hmmm, http://paste.openstack.org/show/728227/ can reproduce with 1.28.0
19:06:39 Shrews harlowja: i blame Nargles
19:07:16 harlowja http://paste.openstack.org/show/728228/ (from using openstack cli which handles it)
19:19:41 openstackgerrit Joshua Harlow proposed openstack/openstacksdk master: On at least pike clouds metadata can be a json blob https://review.openstack.org/592658
19:40:13 openstackgerrit Joshua Harlow proposed openstack/openstacksdk master: Glance v2 allows people to overwrite metadata key https://review.openstack.org/592658
20:38:44 mnaser mordred: guilhermesp and i figured out the root cause of that policy issue, turns out sending `enable_snat` is only allowed if you're an admin by neutron policy
20:39:08 mnaser so i think guilhermesp will be opening a github issue soon for this and probably push up a fix for os_router
20:39:20 mordred mnaser: awesome
20:39:40 mordred is it a bug in os_router and not in openstacksdk's 'create_router' method?
20:39:53 mnaser (because the default value in ansible's os_router for enable_snat set to True then that value is always sent)
20:40:19 mordred AH
20:40:20 mordred yeah
20:40:21 mnaser mordred: https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/openstack/os_router.py#L374
20:40:26 guilhermesp this is the bad guy mordred https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/cloud/openstack/os_router.py#L310
20:40:30 mnaser ^
20:40:47 guilhermesp oh sorry, the bad guy was the link that mnaser sent
20:40:51 mnaser nah its both
20:41:11 mnaser its the default and and the combination that it's always sent
20:41:11 mordred yeah. I grok what you are saying
#openstack-sdks - 2018-08-17
06:35:45 openstackgerrit melissaml proposed openstack/openstacksdk master: Remove the duplicated word https://review.openstack.org/592875
12:09:43 openstackgerrit Merged openstack/openstacksdk master: Remove the duplicated word https://review.openstack.org/592875
13:25:01 openstackgerrit Chen proposed openstack/python-openstackclient master: WIP: make host command api-version-aware https://review.openstack.org/593049
16:00:29 openstackgerrit Gage Hugo proposed openstack/keystoneauth master: Add nosec to usage of SHA1 https://review.openstack.org/593094
17:39:08 openstackgerrit Gage Hugo proposed openstack/keystoneauth master: Change log hashing to SHA256 https://review.openstack.org/593094
22:10:35 openstackgerrit Merged openstack/keystoneauth master: Change log hashing to SHA256 https://review.openstack.org/593094
#openstack-sdks - 2018-08-18
07:00:05 openstackgerrit Merged openstack/keystoneauth master: add release notes to readme.rst https://review.openstack.org/591943
#openstack-sdks - 2018-08-20
09:44:37 dtantsur morning folks, can I get some reviews on https://review.openstack.org/590770 and https://review.openstack.org/591324 please?
11:28:56 openstackgerrit Deepak Mourya proposed openstack/python-openstackclient master: now we can add description for role creation in OSC https://review.openstack.org/484355
14:11:22 mordred dtantsur: done
14:12:06 mordred dtroyer: if you get bored this morning ... https://review.openstack.org/#/c/581276 and https://review.openstack.org/#/c/589465
14:15:47 tosky especially 589465
14:15:51 tosky I was going to ping about that
14:15:52 tosky :)
14:42:14 tosky mordred: oh, I didn't notice that openstackclient is branchless (while python-openstackclient is branches), so I guess I can use https://review.openstack.org/#/c/588336/ to test it I guess
14:45:34 mordred tosky: yah - should be able to
14:46:12 tosky oki, checking
15:06:38 tosky uhm, something failed
15:07:03 tosky there is a conflict with a version of keystoneclient which seems to come from master (>=3.17.0)
15:08:13 tosky http://logs.openstack.org/36/588336/3/check/openstackclient-check-plugins/7e19a94/ stable/queens
15:08:30 tosky http://logs.openstack.org/15/588515/3/check/openstackclient-check-plugins/7d684b6/job-output.txt.gz#_2018-08-20_14_52_32_608991 stable/pike
15:08:33 tosky mordred: ^
15:13:57 mordred tosky: hrm. k. will poke at it in a little bit
15:18:38 tosky thanks
15:28:50 openstackgerrit Merged openstack/openstacksdk master: baremetal: add support for VIF attach/detach API https://review.openstack.org/591324
15:29:34 dtantsur TheJulia: time to celebrate ^^^ :)
15:35:47 openstackgerrit Merged openstack/openstacksdk master: Correct update operations for baremetal https://review.openstack.org/590770
15:35:48 openstackgerrit Merged openstack/openstacksdk master: Use the base Resource's JSON patch support in Image https://review.openstack.org/591314
16:04:28 dtantsur mordred: a chain of baremetal backports when you have a minute: https://review.openstack.org/593685
16:05:53 mordred dtantsur: all lgtm
17:16:17 openstackgerrit Doug Hellmann proposed openstack/service-types-authority master: import zuul job settings from project-config https://review.openstack.org/593705
17:36:48 edleafe mordred: there has been some talk of your head exploding (https://etherpad.openstack.org/p/placement-extract-stein, L97). So I'm wondering: is there any concern with "placement" being both the project name *and* the service-type? Is there any reason to create a separate project name?
17:37:15 mordred edleafe: not from me
17:37:22 mordred edleafe: project names are completey meaningless
17:37:46 mordred edleafe: the only thing I care about is that services have unique and consistent service types
17:38:44 edleafe mordred: ok, thanks. I remembered something in the distant past (ceilometer time frame) that we didn't want to ever preclude competition or alternates
17:39:06 mordred well, I have never shared that opinion myself
17:39:08 mordred BUT
17:39:26 mordred Idon't think it matters to much - anything consuming the API should mostly ignore the service_name
17:40:03 mordred unless a cloud has more than one service deployed with the same service_type and thus it's impossible to find the right service _without_ a sevice_name
17:40:29 mordred that said - from a service-types-authority perspective, evenin that case it'snot guaranteed that the project_name will be used as the service_name
17:40:37 edleafe Agreed. The scenario I remembered was a deployment wants to use a different tool that better fit their needs
17:40:59 mordred totes. ceph vs swift for object-store is a good example :)
17:41:36 edleafe yeah. If swift were named 'object-store', it would make it difficult to consider an alternative
17:41:41 mordred edleafe: now - where I *do* think we're making a mistake but it would be too much of a PITA to fix so I've kept my mouth shut ...
17:42:02 mordred is that in nova.conf we have configuration settings for various services using their project name instead of their service-type
17:42:28 mordred (this is also what keystoneauth is producing to inject into oslo.config because it's what nova was already doing when we added the feature)
17:42:44 edleafe oh, yeah - that's terrible. But there are historical $reasons, and we were dumber back then :)
17:42:48 mordred yup
20:00:30 openstackgerrit Merged openstack/openstackclient master: Switch to stestr https://review.openstack.org/581276
20:00:31 openstackgerrit Merged openstack/openstackclient master: Update openstackclient-check-plugins to honor constraints https://review.openstack.org/589465
20:52:00 mnaser mordred: https://github.com/ansible/ansible/pull/44418 if you're around and it makes sense to you :)

Earlier   Later