18:00:49 <krtaylor> #startmeeting third-party
18:00:49 <openstack> Meeting started Mon Sep 22 18:00:49 2014 UTC and is due to finish in 60 minutes.  The chair is krtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:52 <openstack> The meeting name has been set to 'third_party'
18:01:33 <krtaylor> hello everyone, hope you are here for another great third-party meeting
18:01:41 <krtaylor> anyone ?
18:01:45 <asselin> hi
18:01:57 <krtaylor> hello asselin
18:02:09 <daya_k> hi krtaylore
18:02:18 <daya_k> sorry :) krtaylore
18:02:36 <daya_k> oops, jellyfingers today.
18:02:36 <dougwig> o/
18:02:43 <anteaya> o/
18:02:58 <luqas> o/
18:03:33 <krtaylor> good, well lets get started
18:03:44 <krtaylor> #topic Welcome & Reminder of OpenStack Mission
18:03:54 <krtaylor> #info The OpenStack Open Source Cloud Mission: to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable.
18:04:13 <krtaylor> reminder of the mission out of the way, so lets review
18:04:25 <krtaylor> #topic Review of previous week's open action items
18:04:31 <krtaylor> so that's easy, none from last week
18:04:59 <krtaylor> we have a few good topics this week
18:05:03 <krtaylor> #topic Announcements
18:05:25 <anteaya> #info Infra would support work on this feature (anteaya)
18:05:29 <krtaylor> anteaya, you had an announcement for infra features
18:05:39 <anteaya> #link https://bugs.launchpad.net/zuul/+bug/1370105
18:05:39 <krtaylor> yes, your floor anteaya
18:05:42 <anteaya> thanks
18:05:53 <uvirtbot> anteaya: Error: Could not parse data returned by Launchpad: The read operation timed out
18:06:08 <anteaya> so last week it was discovered taht third party folks would benefit from a filter in zuul that upstream doesn't need
18:06:15 <anteaya> have a look at the bug report
18:06:22 <anteaya> fungi knows the details
18:06:36 <fungi> i do?
18:06:43 <anteaya> ask him if you need more but infra would accept patches that impliments this feature
18:06:56 <anteaya> hi fungi, yes the zuul feature item for third party
18:07:05 <fungi> oh, i'm starting to remember
18:07:08 <fungi> yes
18:07:10 <anteaya> yeah, that
18:07:12 <fungi> files filter for pipelijnes
18:07:15 <fungi> pipelines
18:07:17 <anteaya> so hep here is appreaciated
18:07:21 <anteaya> any questions?
18:07:23 <fungi> hep! hep!
18:07:32 <anteaya> hurray
18:07:33 <krtaylor> hehheh
18:07:38 <anteaya> okay done
18:07:41 <fungi> yes, if someone wants to implement that feature in zuul, we're more than open to it i think
18:07:54 * krtaylor looks
18:08:15 <clarkb> we have a file filter
18:08:26 <fungi> clarkb: it's for jobs, not pipelines
18:08:29 <clarkb> requirements jobs use it but it is per job
18:08:59 <fungi> unless there's a pipelines trigger one which isn't documented and if so i didn't see it in the source either
18:10:25 <fungi> basically zuul lets you limit jobs and pipeline triggers by branch pattern, but only lets you limit jobs by file pattern
18:10:59 <fungi> so the idea would be to extend that to pipeline triggers, just like branch patterns are
18:11:56 <krtaylor> got it, sounds like a useful patch
18:12:10 <fungi> an alternative option might be for zuul to grow a toggle which tells it not to report if it runs no jobs
18:12:57 <fungi> either of those would, i think make it possible for zuul deployments to report on changes with specific files touched, but not report on other changes to the same project
18:13:29 <krtaylor> that might eliminate a lot of noise
18:14:00 <fungi> and since there seemed to be increasing willingness from projects to see third parties only report on changes touching specific files, this seems like a reasonable thing to support (suppressing reports from systems which ran no jobs on a change)
18:14:39 <krtaylor> yes, anyone interested?
18:14:58 * krtaylor imagines everyone taking a step back
18:15:45 <krtaylor> I'll take a look at it, if no one else steps up
18:15:58 <asselin> I have interest, but I can't commit to that in the near term.
18:16:29 <krtaylor> asselin, agreed, me too, maybe we can both work through it
18:16:30 <clarkb> I see. is the issue reporting when no jobs match a job based file filter?
18:16:58 <asselin> krtaylor, sure
18:18:13 <krtaylor> fungi? clarkb's question?
18:18:44 <krtaylor> IIUC, it is because there is not a file filter, so everything reports by default
18:19:46 <daya_k> if zuul does not map a change to a job today, it doesnt report anything, right? so, this is about the granularity of mapping a job to a change within a project?
18:20:20 <fungi> yep
18:20:47 <fungi> clarkb: so for those changes, zuul reports that it successfully ran no jobs, as configured
18:21:02 <clarkb> gotcha
18:21:08 <daya_k> fungi : how about the regex's. i thought those were being used today, although i havent been able to get ci-name:recheck to work properly, but thats a separate point
18:21:09 <krtaylor> yep, understood
18:22:01 <fungi> daya_k: unrelated. you just need to configure the comment-added trigger pattern for your pipeline to match the comments for which your system reacts
18:22:36 <krtaylor> daya_k, regex works, we (PowerKVM) use it, ping me in infra after the meeting, or bring that up in opendiscussion
18:22:44 <krtaylor> open discussion
18:22:55 <daya_k> krtaylor thanks,  i'll catch you later with the configured pattern, i have it but somethings missing
18:23:09 <krtaylor> ok, anything else on this feature?
18:23:34 <krtaylor> thanks fungi, clarkb, anteaya
18:23:40 <anteaya> done
18:23:56 <krtaylor> asselin, you're up next - discuss a change?
18:24:23 <asselin> sure. I uploaded a change to devstack-gate that I think is relevant to other 3rd party
18:24:47 <asselin> I would like some reviews / let you know it's there so you can use it
18:25:05 <asselin> it basically adds some more hooks to do some cleanup after a job runs
18:25:23 <asselin> https://review.openstack.org/#/c/122896/
18:25:58 <anteaya> +1
18:26:10 <anteaya> that is for the general direction and thank you for the patch
18:26:40 <anteaya> as I state in my review, I don't know enough about devstack-gate code to offer an opinion as to whether this is the best implimentation
18:26:53 <asselin> so e.g. my use case is to test our cinder driver. I cleanup the backend after each test run using the pre_clean_hook
18:27:18 <asselin> otherwise we end up with lots of stuff lingering around waiting for manual cleanup
18:27:53 <daya_k> asselin : +1, yes, i think this is great if esp if you dont have single use nodes
18:27:54 <asselin> I write the hook function directly in my jenkins job that runs the test.
18:28:23 <krtaylor> asselin, good, I'll get some of my team to take a look at the patch too
18:28:34 <asselin> bascially copied and pasted from the other hooks in the file.
18:28:39 <asselin> thanks
18:29:18 <krtaylor> asselin, anything else?
18:29:26 <asselin> that's it!
18:29:44 <krtaylor> thanks, on to Program items then
18:29:53 <krtaylor> #topic OpenStack Program items
18:29:59 <anteaya> #info Preparing for Summit (anteaya)
18:30:01 <krtaylor> anteaya, you are up first
18:30:06 <daya_k> asselin : fyi, i am doing cleanup activities in pre_test_hook today, but a separate hook is also good
18:30:08 <anteaya> #link https://etherpad.openstack.org/p/kilo-third-party-items
18:30:23 <anteaya> so some folks have added their thoughts to the etherpad, thank you
18:30:48 <anteaya> we have one item with no owner, if noone takes ownership that item will be moved off of the list
18:31:24 <anteaya> I had thought we would have more items than we do by this point, but I can't but words in other people's mouths
18:31:26 <krtaylor> I have some items too, bad krtaylor for not getting that done last week
18:31:35 <anteaya> any one with thoughts on what is written there so far?
18:32:25 <krtaylor> there are some meaty topics there, I want to see more requirement development
18:32:33 <krtaylor> I'll get that added
18:32:58 <anteaya> what do you mean by more requirement development
18:33:12 <anteaya> folks can't meet the requirements we *have*
18:33:19 <anteaya> what is the point of adding more?
18:33:23 <krtaylor> there is a need for defining cross-project requirements as well as what the individual projects have defined, and a directory
18:33:36 <krtaylor> I'll add that to the list
18:33:37 <anteaya> also please add your name to the etherpad, top right
18:33:53 <anteaya> what are cross-project requirements?
18:34:00 <krtaylor> anteaya, not so much more
18:34:15 <krtaylor> just recording what we have
18:34:17 <anteaya> thank you daya_k
18:34:28 <daya_k> thanks, i didnt see that before
18:34:30 <anteaya> our requirements are recorded
18:34:31 <krtaylor> and organizing it better so that it is easier to follow
18:34:44 <anteaya> offer patches to third-party.rst
18:34:51 <anteaya> I am clearly missing something
18:34:57 <anteaya> what is the goal here?
18:34:58 <krtaylor> so many don't even know what we are doing here, I just encountered that this morning
18:35:03 <anteaya> yes
18:35:15 <anteaya> that is not due to a shortage of requirements, believe me
18:35:19 <krtaylor> the goal is to add items to the planning document
18:35:39 <anteaya> that is due to management memoing them to set up a ci and giving them zero time to learn a dev workflow
18:36:06 <krtaylor> so we shouldnt allow that until they know about this :)
18:36:14 <anteaya> their management has given them unreasonable directives
18:36:19 <krtaylor> agreed
18:36:21 <anteaya> allow that?
18:36:34 <anteaya> how can we stop management from being unreasonable?
18:36:54 <krtaylor> getting a service id is the last step, not the first
18:37:31 <krtaylor> lets table this for a discussion on the planning document
18:37:46 <anteaya> this is a discussion on the planning document
18:38:00 <krtaylor> at a later time, then I can be more precise with my wording where time to type is not a factor
18:38:14 <anteaya> since I don't see that having an item at summit to discuss more requirements is a good use of time
18:38:33 <anteaya> and obviously there are others that think more requirements is a solution here
18:38:37 <anteaya> and I strongly disagree
18:39:18 <anteaya> more understanding from vendor companies of our developer workflow is what is needed
18:39:29 <anteaya> but I see no way that management would listen to that
18:39:40 <krtaylor> not sure why you are attacking more requirements, again, my choice of words has been retracted
18:39:46 <anteaya> and I have no way to translate that into a requirement
18:39:57 <anteaya> I am not attacking
18:40:06 <anteaya> I am curious to know what the underlying issue is
18:40:10 <anteaya> since I don't know what it is
18:40:12 <krtaylor> I think that is fixed by reordering what we have, not creating new
18:40:23 <daya_k> so, my thoughts as a consumer - the wiki page is much more high level and incomplete, jay pipes blog has a good basic tutorial, that sort of info could be pulled into the wiki
18:40:30 <krtaylor> well, when I get it entered, we can discuss it
18:41:01 <anteaya> daya_k: great, would you like to do that?
18:41:26 <daya_k> anteaya : i could take a shot at it, what timeline though
18:41:31 <krtaylor> daya_k, agreed, its not that the info doesnt exist at all
18:41:32 <anteaya> krtaylor: reording the requirements is fine, but I think it is a meeting agenda item, not a summit item
18:41:48 <anteaya> daya_k: well it has never been done, so sometime between now and eternity?
18:42:02 <daya_k> :) let me take a todo on it
18:42:04 <krtaylor> my proposal would require infra to change policy too
18:42:13 <anteaya> daya_k: I have no timeline, since if you don't do it it won't get done which is no different from what we have now
18:42:33 <anteaya> krtaylor: then I suggest you make an item on the infra agenda
18:43:03 <anteaya> krtaylor: since if this is your thinking, if the first time jeblair hears about it is summit, it doesn't have a good chance of success
18:43:06 <krtaylor> but, there are 5 or so items in my head, I have no desire to discuss them before I have put them in the planning document
18:43:16 <anteaya> krtaylor: jeblair likes items on the infra agenda
18:43:34 <ociuhandu> hello all, sorry for being so late
18:43:36 <ociuhandu> krtaylor: sorry, was out of office, just managed to get back now
18:44:07 <krtaylor> ociuhandu, great, almost there
18:44:26 <krtaylor> anteaya, what is the timeline to close out this planning etherpad
18:44:36 <anteaya> krtaylor: when it is done
18:44:55 <krtaylor> well, I would assume that would be before summit?
18:45:04 <anteaya> to be honest, based on the number of submissions right now, I don't feel like we have enough to justify a space
18:45:37 <anteaya> if we don't have items down soon, I have no reason to elbow out other folks with a more complete plan
18:45:56 <anteaya> why does everyone need a deadline in order to get anything done
18:46:04 <anteaya> what is wrong with just doing the work?
18:46:17 <anteaya> this is very frustrating
18:46:48 <anteaya> as soon as a deadline is selected the only thing I know is that noone will do anything until after it has passed and someone goes around with a reminder
18:46:59 <krtaylor> anteaya, realities of a day job
18:47:02 <anteaya> this is not an efficient way to work in open source
18:47:09 <anteaya> well it isn't a good use of my time
18:47:24 <ociuhandu> anteaya: regarding your comment on the etherpad doc: I was referring to requirements for getting the voting rights, not for having a CI
18:47:26 <anteaya> so set whatever deadline you want and either do it or don't do it
18:47:48 <anteaya> ociuhandu: http://ci.openstack.org/third_party.html#permissions-on-your-third-party-system
18:48:01 <anteaya> ociuhandu: that outlines how to get voting rights
18:48:16 <anteaya> ociuhandu: if you think that process needs more clarity do offer a patch
18:49:02 <ociuhandu> anteaya: ok, will try to put together one
18:49:18 <anteaya> ociuhandu: thank you, set the topic to third-party please
18:51:01 <krtaylor> anteaya, anything else on the summit preparations
18:53:00 <anteaya> just that there had better be something worth discussing soon on that etherpad otherwise I won't be pushing for a space for third party
18:53:01 <anteaya> that's it
18:56:06 <ociuhandu> from what I have observed, most implemented recheck-<system-name> after the last “main CI” rules update
18:56:47 <ociuhandu> while the doc says: “Some third-party CI systems may not have the resources to be able to support all rechecks meant for other systems…”
18:57:01 <krtaylor> recheck-<name> should recheck jenkins too, since everything following recheck is considered a comment to jenkins
18:57:05 <ociuhandu> that translates, for me, that I don’t have to support “recheck”
18:57:08 <krtaylor> ociuhandu, yes, but that is not the only reason
18:57:17 <ociuhandu> as long as I support “recheck-<system>”
18:57:17 <krtaylor> I can remove that
18:57:32 <ociuhandu> ok
18:57:32 <asselin> also for developers, they may have an expectation that only 1 ci system is going to get checked
18:57:40 <krtaylor> yes, that is correct, at least that is my proposal
18:58:07 <krtaylor> asselin, that goes back to jenkins recheck on recheck*
18:58:13 <ociuhandu> and 2nd, is why can’t we decide between the third-parties on a naming that will not involve regriterring Jenkins?
18:58:27 <asselin> maybe we can change it to: <third-party-ci>:check
18:58:47 <krtaylor> asselin, that is sdague 's original proposal
18:59:05 <krtaylor> asselin, namespaces for each system got voted down
18:59:06 <ociuhandu> e.g. instead of “recheck-<system-name>” to “check-<system-name>” or as asselin suggested?
18:59:19 <krtaylor> that didn't work
18:59:27 <asselin> why? I think that is most developer-friendly
18:59:42 <krtaylor> infra didnt like it
18:59:53 <krtaylor> and we are out of time
19:00:26 <krtaylor> we'll have to hit any open discussion items next week
19:00:40 <krtaylor> thanks everyone, move to -infra
19:00:51 <anteaya> thanks krtaylor
19:01:09 <krtaylor> #endmeeting