15:00:45 <anteaya> #startmeeting third-party
15:00:46 <openstack> Meeting started Mon Sep 28 15:00:45 2015 UTC and is due to finish in 60 minutes.  The chair is anteaya. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:50 <openstack> The meeting name has been set to 'third_party'
15:00:53 <anteaya> hello
15:01:00 <asselin> o/
15:01:14 <rhedlind> hi
15:01:17 <mmedvede> hi
15:01:37 <aysyd> hi
15:01:54 <anteaya> hello everyone
15:02:07 <anteaya> does anyone have anything they would like to discuss today?
15:02:48 <wznoinsk> hi all
15:02:48 <asselin> I have some common-ci patches I'd like people to try out
15:02:57 <anteaya> do share the links/
15:03:00 <anteaya> ?
15:03:14 <anteaya> I was just thinking about your docs patch you offered up the end of last week
15:03:42 <asselin> #link third-party ci documentation https://review.openstack.org/#/c/227584/
15:04:12 <asselin> #link single-node third-party ci proposed solution: https://review.openstack.org/#/c/200330/
15:05:15 <asselin> #link example project-config-example: https://github.com/rasselin/project-config-example
15:05:39 <asselin> #link project-config-example nodepool dependency: https://review.openstack.org/#/c/189762/
15:05:56 <anteaya> is there anyway you can have all your patches in gerrit?
15:06:41 <asselin> anteaya, that's a good question. the only one that's not is the project-config-example
15:06:46 <anteaya> yes
15:06:53 <anteaya> can it be in gerrit?
15:07:16 <asselin> I would like it to be, but want to discuss that first
15:07:18 <anteaya> for instance since the puppet-openstackci module makes mention of it, would it make sense to have the sample in that module
15:07:26 <anteaya> okay, let's discuss
15:07:41 <asselin> anteaya, yes, origianlly I was going to put it in puppet-openstackci modules
15:07:44 <anteaya> if I am supporting openstack devs to review patches I want to guide them to gerrit
15:08:21 <asselin> however, that's makes it more complicated to review and use as an example
15:08:31 <asselin> so I'd like to propose it to be it's own project
15:08:32 <anteaya> can you expand on that point?
15:08:43 <anteaya> it is a sample file
15:08:51 <anteaya> to be used in a puppet module
15:08:56 <asselin> anteaya, it's convenient to have a git url that can just be used to get started
15:09:02 <anteaya> I'm foggy on the use case why it needs to be its own project
15:09:15 <asselin> and can be forked from there
15:09:16 <anteaya> I'm not following you
15:09:37 <anteaya> you want to provide users a way to fork the file
15:09:45 <asselin> fork the repo
15:09:58 <anteaya> and feel that users can't figure out how to fork a file unless it is in its own repo?
15:10:14 <asselin> anteaya, it's not a file, it's a collection of files
15:10:27 <anteaya> project-config-sample is a file?
15:10:41 <asselin> no it's is not a file
15:11:00 <asselin> please take a look and we can discuss the best place to put it: https://github.com/rasselin/project-config-example
15:11:06 <anteaya> I'm not a fan of it being its own project
15:11:29 <anteaya> to my way of thinking it belongs in the puppet-openstackci module
15:11:34 <anteaya> in its own directory
15:12:05 <asselin> why's that?
15:12:20 <anteaya> because that is the module that consumes it
15:12:39 <anteaya> the sample is only used by puppet-openstackci
15:12:55 <anteaya> and the point it for folks to have one place to get what they need
15:13:00 <asselin> it can be used by any module that takes a project-config git url
15:13:03 <anteaya> all contained in one place
15:13:35 <anteaya> did you create it for puppet-openstackci?
15:13:48 <anteaya> that was my belief of your intent
15:14:04 <asselin> I created it to help 3rd party ci operators have a starting point that's simpler than openstack-infra/project-config
15:14:22 <anteaya> for puppet-openstackci?
15:14:44 <asselin> puppet-openstackci documentation can take advantage of it
15:14:59 <asselin> to provide simpler instructions
15:15:03 <anteaya> can puppet-openstackci run without it?
15:15:53 <asselin> without the example, absolutely yes
15:15:57 <anteaya> great
15:16:08 <anteaya> let's focus on puppet-openstackci and patches in gerrit
15:16:24 <anteaya> that fits wtih the things I am willing to support
15:16:39 <anteaya> thanks for your patches
15:16:54 <asselin> so then there are 2 options: get it into gerrit as it's own project, or own folder of an existing project
15:17:04 <anteaya> so if folks are able to take some time and review asselin's gerrit patches linked above that would be great
15:17:15 <asselin> that's what I'd like to discuss today
15:17:18 <anteaya> asselin: well you are the driver here
15:17:23 <anteaya> okay thank you asselin
15:17:34 <anteaya> let's see if anyone else has anything they would like to discuss
15:17:44 <anteaya> so we can also work them into the schedule
15:18:01 <anteaya> does anyone else have items they would like to discuss today so we can fit you in?
15:18:30 <anteaya> I have an item but it can wait until the end
15:18:47 <anteaya> okay well it looks like just asselin has a topic right now
15:18:52 <anteaya> go ahead asselin
15:19:48 <asselin> ok, so we all agree patches should be in gerrit, the question is, which is the best approach for 3rd party ci operators to migrate to the common 3rd party ci solution
15:20:08 <anteaya> so if we all agree -- well that is the openstack workflow
15:20:20 <anteaya> and the workflow infra supports for openstack developers
15:20:39 <anteaya> so you agreed to follow that workflow as did all the others when you started contributing to openstack
15:20:49 <anteaya> it isn't a topic that is open for discussion
15:21:07 <asselin> so I would like to request existing operators to review the patches and follow the documentation and see which approach would be best long-term
15:21:08 <anteaya> it is a very important part of the foundation of what makes openstack openstack
15:21:18 <anteaya> a foundation that is being quickly eroded
15:21:23 <asselin> anteaya, please, let me state my request
15:21:26 <anteaya> by folks who forget what they agreed to
15:21:37 <anteaya> let's start with acknkowledging the foundation
15:21:45 <anteaya> of what makes openstack openstack
15:22:15 <asselin> anteaya, go ahead
15:22:21 <anteaya> the openstack workflow and using the tools to develop components is what makes openstack openstack
15:22:44 <anteaya> if we take that for granted we are party to what causes a loss of values
15:23:24 <anteaya> I'm surprised that folks would want to work around what is at the heart of what so many people consider something having value
15:23:50 <anteaya> rather than making efforts to improve that systems and assist others to understand why it exists and why it is important
15:24:09 <anteaya> if we forget that than we do disservice to each other
15:24:31 <anteaya> as well as all my infra team mates working so hard to ensure that folks have access to tools for development
15:25:14 <anteaya> is there anyone in the meeting willing to acknowledge the openstack workflow has value to them
15:25:29 <anteaya> and that they recongnize they have a role to play in that workflow
15:25:46 <anteaya> noone?
15:25:57 <anteaya> I had thought that was what I was doing
15:26:08 * asselin agrees
15:26:17 <patrickeast> :o hang on, hang on, i agree with what you are saying
15:26:18 <anteaya> helping folks to may have a shaky start understanding that value to come to recognize it
15:26:21 * patrickeast is catching up
15:26:22 <anteaya> asselin: thank you
15:26:28 <anteaya> patrickeast: thank you
15:26:37 <patrickeast> so this is for the config repo?
15:26:40 <patrickeast> asselin: ^
15:26:58 <asselin> patrickeast, anteaya and I are on different topics
15:26:58 <anteaya> this is for starting from a common understanding of what is important and why we are here
15:27:17 <anteaya> we seem to be taking a lot of things for granted and I don't think we can do so any longer
15:27:40 <anteaya> if we just assume we have the same values without acting like we have the same values we run at cross purposes to each other
15:27:47 <anteaya> and waste each other's time
15:28:17 <mmedvede> anteaya: agree with you in general
15:28:18 <patrickeast> ok, yea i'm with you there
15:28:25 <anteaya> patrickeast: thankyou
15:28:37 <asselin> patrickeast, yes, I'm trying to create an example
15:28:40 <anteaya> mmedvede: thank you, do you mean you disagree with me in practice?
15:29:22 <mmedvede> anteaya: :) I mean I am relatively new to say 100% agree, I am sure I am missing something somewhere
15:29:39 <anteaya> mmedvede: okay fine, I can accept that, thank you
15:30:27 <anteaya> so I think it behouves us as openstack developers to find ways to work within the openstack workflow and find ways to improve the workflow if you feel improvement is called for
15:30:45 <mmedvede> anteaya: I need to learn how to use the tooling foundation provides to do a less frictionless development. So far my experience was it takes more time once it is in OpenStack harness
15:31:11 <anteaya> mmedvede: okay that is great
15:31:17 <mmedvede> so sometimes it makes sense to prototype locally first. But I am sure there is effective way to do it
15:31:18 <anteaya> mmedvede: let's work on that
15:31:44 <anteaya> mmedvede: do you use gerrit and submit patches to gerrit and then pull them down to work on them?
15:32:01 <asselin> anteaya, if this ^^ is regarind me using github, then here's the doucmentation that state's its part of the openstack workflow: http://docs.openstack.org/infra/manual/creators.html#add-the-project-to-the-master-projects-list
15:32:05 <anteaya> many developers don't keep anything locally, they keep it all in gerrit
15:32:37 <asselin> upstream: git://github.com/awesumsauce/<projectname>.git
15:32:41 <asselin> Step #3
15:33:00 <anteaya> asselin: I still am foggy on why it needs to be its own repo
15:33:27 <asselin> anteaya, sure I'm willing to discuss that, as long as we agree my workflow is correct
15:33:45 <anteaya> and if you wanted eyes on the repo in gerrit the way to link them in a meeting is via a new project project-config patch
15:33:52 <anteaya> so taht people can review the gerrit patch
15:34:01 <anteaya> if they have comments on the repo itself
15:34:25 <anteaya> I prefer links to meetings to be to gerrit patches
15:34:37 <anteaya> so that I can support asking people to review the gerrit patches
15:35:01 <asselin> sure, so I'll create those patches first
15:35:05 <anteaya> and so they have a place to leave reviews and comments
15:35:40 <asselin> ok nothing else from me
15:35:44 <mmedvede> asselin's example project-config is in starting phase, there is no project for it yet, so hard to have links to gerrit, much easier to github
15:36:04 <mmedvede> asselin: so you are going to get project-config example embedded into openstackci module?
15:36:09 <anteaya> mmedvede: that is contraty to the tooling I am willing to support
15:36:15 <asselin> mmedvede, I will create a project-config patch that links to the github repo
15:36:17 <anteaya> if you read what I have been stating
15:36:26 <asselin> mmedvede, seems that's where I fell off the cliff
15:37:31 <anteaya> anyone have any further comments or questions on this topic?
15:37:52 <patrickeast> i guess i'm not sure i see what the problem is... but i think having it as a separate repo makes the most sense anyway, so adding it in with a project-config seems like the next step to me
15:38:06 <mmedvede> personally, I think a new project would be better to contain the example
15:38:21 <anteaya> well if we get a patch to gerrit you have a place to say so
15:38:25 <asselin> patrickeast, mmedvede thanks, glad we agree on that. I will take that approach.
15:38:32 <anteaya> anything else?
15:38:46 <patrickeast> as a consumer of it, having a repo to fork is 100x easier than trying to figure out what i need to copy paste into my own
15:39:16 <mmedvede> patrickeast: you read my mind? :)
15:39:27 <patrickeast> lol
15:40:43 <anteaya> anything more on this topic?
15:41:03 <asselin> I got my answers, thanks
15:41:10 <anteaya> asselin: great, thank you
15:41:20 <anteaya> so for the next topic
15:41:25 <anteaya> I have an item
15:41:43 <anteaya> you may or may not have seen this posted to the -dev list late friday
15:41:46 <anteaya> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/075532.html
15:41:56 <anteaya> so this is an effort of the foundation
15:41:59 <anteaya> not of infra
15:42:11 <anteaya> I fully support this effort but am not in charge of it
15:42:32 <asselin> anteaya, is that the first time you heard of it?
15:42:37 <anteaya> if you wish to become involved in the effort be sure to contact hogepodge directly
15:42:49 <anteaya> no, hogepodge came to the -qa sprint
15:43:06 <anteaya> and brought the topic up at that time since there were 4 neutron devs at the table
15:43:10 <anteaya> and it was discussed
15:43:39 <patrickeast> any idea if that means we need to change what we are doing already if we have a CI in place?
15:43:39 <anteaya> so infra will support this effort but is not driving it
15:43:43 <anteaya> right
15:43:49 <patrickeast> or is there a wiki page somewhere i can go read?
15:43:51 <anteaya> that is the question I knew you would have
15:43:56 <anteaya> and the answer is no
15:44:00 <anteaya> I don't no
15:44:13 <anteaya> it is my expectation it will look a lot like defcore
15:44:26 <anteaya> so devs use tempest in development
15:44:30 <anteaya> and continue to do so
15:44:55 <anteaya> and for the foundation's purposes they have requirements, built on development requirements but different
15:45:11 <anteaya> and hogepodge is asking for participation to create the structure
15:45:19 <anteaya> so by all means contact him and participate
15:45:39 <anteaya> I just want to ensure folks know that all current infra requirements for gerrit ci accounts remain in place
15:46:26 <anteaya> and I know you will have questions
15:46:49 <anteaya> and the only answers I can give at present are, infra requirements and project requirements remain in place
15:46:55 <anteaya> and I support the effort
15:47:29 <anteaya> anything more on this topic?
15:48:00 <anteaya> oh also for reference hogepodge brought up the topic at a neutron team meeting I think 2 weeks ago
15:48:07 <anteaya> feel free to read the neutron meeting logs
15:48:49 <anteaya> anything more on this topic/
15:48:51 <anteaya> ?
15:49:49 <anteaya> does anyone have an update on where we are with agreeing to a single third party dashboard?
15:51:05 <mmedvede> anteaya: we are going to discuss it a bit more in tomorro's working group meeting
15:51:16 <anteaya> mmedvede: any update for today?
15:51:19 <anteaya> are we close?
15:51:54 <mmedvede> anteaya: I did spend some time getting poc puppet module to deploy CI Watch, but it requires more work
15:51:58 <patrickeast> last i saw from the spec review ci-watch was what was going to be the choice... looked about as close as anything else thats been tried
15:52:04 <mmedvede> it did not go as smooth
15:52:18 <anteaya> mmedvede: I don't think that will stand in the way of getting a spec approved
15:52:33 <anteaya> yeah so getting the spec approved is the first step
15:52:41 <mmedvede> anteaya: correct. It is more about are we sure with CI Watch
15:52:51 <anteaya> you don't have to have a working puppet implementation before the spec is approved
15:53:08 <anteaya> mmedvede: well what is the option if we aren't sure about ci watch
15:53:32 <mmedvede> patrickeast: yes, we did small vote last week, but you were not there, so we wanted to discuss tomorrow to see if you agree
15:53:35 <anteaya> I felt there was agreement on this last week and am kind of suprised we have moved to uncertainty this week
15:53:51 <mmedvede> anteaya: not uncertainty
15:53:59 <patrickeast> ah yea, i'm cool with whatever
15:54:03 <anteaya> how would you characterize it then
15:54:15 <anteaya> that sounds like agreement to me
15:54:24 <patrickeast> imo none of the solutions are 100% perfect, but we need one in there so we can start iterating on them and get them better
15:54:28 <mmedvede> anteaya: wanted to make sure everybody involved, such as patrickeast, also supports it
15:54:41 <anteaya> sounds like we are there
15:54:47 <mmedvede> anteaya: yup
15:54:49 <anteaya> patrickeast: agreed, thank you
15:55:03 <anteaya> mmedvede: wonderful so do we need a new patchset on the spec then?
15:55:16 <anteaya> or can we have a link to it for the meeting logs?
15:55:49 <mmedvede> #link https://review.openstack.org/194437
15:55:53 <anteaya> thank you
15:55:59 <mmedvede> it is ready to go
15:56:20 <anteaya> great, good work folks
15:56:23 <anteaya> please review
15:56:43 <anteaya> I would like to have this added to tomorrow's infra meeting for voting
15:56:55 <anteaya> who would like to represent the spec at the meeting?
15:57:38 <mmedvede> anteaya: I am the assignee
15:57:51 <mmedvede> so can do that
15:58:01 <anteaya> mmedvede: wonderful please add it to the infra meeting agenda under specs for approval
15:58:09 <anteaya> and attend tomorrow's meeting
15:58:09 <mmedvede> ok
15:58:37 <asselin> fyi I'll be available in the 2nd half of the meeting, but I already voted on the patch so don't need to be tehre
15:58:39 <anteaya> prepare a short sentence or two on the spec so that infra meeting attendees have context for what it is even if they have never read the spec before
15:58:59 <anteaya> asselin: it would be helpful if you were there to reply to any questions taht come up about it
15:59:17 <anteaya> having it on the agenda is often the first time some people have seen the spec
15:59:22 <anteaya> so context is very important
15:59:40 <anteaya> asselin: so it is great if you are there but no worries if you aren't
15:59:45 <anteaya> thanks everyone
15:59:48 <anteaya> see you next week
15:59:51 <anteaya> #endmeeting