Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-11-30
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
16:33:18 rcarrillocruz if pending, i'm happy to get the ball running
16:33:21 rcarrillocruz AH
16:33:25 rcarrillocruz the rate limiting i assume?
16:33:52 mordred rcarrillocruz: it's unclear - we need to dig in a little and see
16:34:03 rcarrillocruz k, when that's sorted i'm happy to help on that, just ping me
16:34:17 mordred rcarrillocruz: we should *probably* get this finished nad merged too: https://review.openstack.org/#/c/504267/
16:34:20 rcarrillocruz also, OSA folks seem interested on testing against ansible devel
16:35:03 rcarrillocruz and they bundle a few modules due to lack of os_* functionality
16:35:11 rcarrillocruz which i'm hoping to tackle soon
16:35:23 mordred rcarrillocruz: yah - I think we'll get several takers for doing cross-testing once it's there ... but I mostly want to make sure the gh/webhook stuff is stable enough so that github integration doesn't give people an impression that zuul is flaky - since for several of them it'll be their first impression
16:35:25 rcarrillocruz like, they have os_magnum_container
16:35:34 mordred ah - fun
16:35:45 rcarrillocruz and some keystone stuff, cos for some reason upstream lacks some stuff
16:35:54 mordred rcarrillocruz: jeez - we're going to have to figure out a good name for that- os_magnum_container isn't it ...
16:36:01 rcarrillocruz lol
16:36:15 rcarrillocruz yeah, iirc 'container' was taken by swift :S
16:37:03 mordred rcarrillocruz: oh - the keystone stuff ... we ran in to problems trying to figure out how to deal with the v2/v3 differences in the ansible module - and I think at this point we should just maybe have an os_keystone_endpoint module that is v3 only ... nobody should be setting up new v2 endpoints
16:37:06 mordred rcarrillocruz: yup
16:37:50 mordred rcarrillocruz: so we need an answer for that for shade and for ansible
16:37:59 mordred rcarrillocruz: the only magnum function we have in shade currently is cluster_template
16:38:26 rcarrillocruz yeah, i think that's my fault
16:38:33 rcarrillocruz i started putting magnum stuff on shade
16:38:43 rcarrillocruz then ELOSTJOB
16:38:49 rcarrillocruz and you renamed it to cluster_template
16:38:50 rcarrillocruz meaning
16:39:03 rcarrillocruz is a halfway work, i never completed putting magnum on it
16:39:43 rcarrillocruz i committed to evrardjp to look at their stuff, put missing stuff on shade
16:39:50 rcarrillocruz and mark https://github.com/ansible/ansible/issues/24197 as complete
16:40:19 mordred ++
16:40:32 mordred well- we have magnum enabled jobs at least, so that part is done :)
16:48:46 dhellmann dtroyer : I have some ideas for improving cliff performance. I'm going to ask for a volunteer on the ML, but wanted to run the notes past you first in case you've already started thinking along the same lines. https://etherpad.openstack.org/p/mFsAgTZggf
16:51:47 dtroyer dhellmann: cool, I'll have a look after lunch
16:54:43 dhellmann dtroyer : thanks
16:59:24 dtroyer mordred: as a follow-up to https://review.openstack.org/#/c/523520/ (shade->OSSDK rename) I proposed https://review.openstack.org/524249 to put o-c-c next to shade
17:01:30 openstackgerrit Doug Hellmann proposed openstack/cliff master: add support for legacy command name translation https://review.openstack.org/522380
17:07:26 cdent edleafe, elmiko, dtantsur|afk : https://etherpad.openstack.org/p/api-sig-newsletter
17:13:25 edleafe looking...
17:15:37 edleafe ok, just a few small changes.
17:16:09 cdent yeah, good, thanks edleafe
17:17:09 cdent away
17:17:17 cdent as in, thar she blows
17:17:41 cdent dtantsur|afk: you should see your +2 (if I’ve done it right)
17:23:27 openstackgerrit Merged openstack-infra/shade master: Avoid tox_install.sh for constraints support https://review.openstack.org/508061
17:30:08 openstackgerrit Merged openstack/python-openstacksdk master: Remove use of tox-siblings role https://review.openstack.org/523993
17:45:55 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: DNM: Test -tips variations https://review.openstack.org/523938
17:47:48 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: DNM: Test -tips variations https://review.openstack.org/523938
17:48:52 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: DNM: Test -tips variations https://review.openstack.org/523938
18:05:35 thingee with the merging of shade and python-openstacksdk, are extensions still going to be supported https://review.openstack.org/#/c/523834/ - shade normalized things is why I'm asking
18:29:22 mordred thingee: we support some openstack extensions in shade already, so I thnk so - the main thing froma shade pov is in whether or not the extension in question can be exposed/presented in a way that makes sense or degrades in a reasonable way
18:30:34 mordred thingee: like, if an extension adds a field to a resource, then we can always add that field to our returned data model and just fill in None if the cloud doens't have the extension ... or if the same info is given by different extensions slightly differently and we can rationalize it - then we can try to do that
18:31:06 mordred thingee: but some extensions are things that don't make much sense in a general context - like something that exposed vendor-specific attributes - and those are ones we'd never add to the data model
18:32:45 mordred thingee: long-winded way of saying "it depends/case-by-case" for the shade layer ... the sdk object layer is somewhat similar to shade's data model, but it's also closer to exposing the details of the cloud in question - so I could see an argument for some variation to be exposed, along with discovery flags, at thatlayer
18:34:06 mordred thingee: in the case of https://review.openstack.org/#/c/523834/ - that particular case seems reasonable for the responses - tags are a neutron feature that a deployer may or may not have enabled, so defaulting them to [] seems maybe reasonable?
18:34:16 thingee yeah got it, thanks
18:34:28 thingee and yes I agree it's reasonable
18:34:33 mordred otoh - I'm not sure what the experience is going to be for a user that tries to add a tag to a resource on a cloud that doesn't support it - and I'm not sure that patch addresses that
18:35:02 mordred (it's also possible that's already handled in the existing code, I need to go look)
18:54:39 thingee mordred: pretty sure that's just going give a 404 http://git.openstack.org/cgit/openstack/python-openstacksdk/tree/openstack/network/v2/tag.py#n27
18:55:50 thingee just being a keystone session request.
18:59:09 thingee mordred: I'll check around for other instances, but this should probably have the _has_neutron_extension('tags') check and raise like the other place shade does it

Earlier   Later