17:09:37 #startmeeting community 17:09:38 Meeting started Mon Mar 2 17:09:37 2015 UTC and is due to finish in 60 minutes. The chair is mrmartin. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:09:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:09:41 The meeting name has been set to 'community' 17:10:05 I hope it will create the logs. 17:10:10 thanks mrmartin 17:10:24 do we have an agenda? 17:10:48 yes, we need to start with a status report to understand where we're at with migration activity board to infra 17:11:10 the objective of the meeting is to set a roadmap (draft a spec) 17:11:12 #topic status report of activity.o.o migration 17:11:22 oh welcome dpose, reed, mrmartin let me introduce dpose to you 17:11:30 he's puppetizing cvsanaly :) 17:11:30 hi dpose 17:11:38 sound so strange 17:11:53 hi mrmartin 17:12:19 do we have a story for this task? 17:12:24 how is activity.o.o had been deployed actually? 17:12:35 ok, let's start from the beginning 17:12:47 we do not have a story (if you mean in storyboard) 17:12:54 so we can open one there I guess 17:13:12 then, the current deployment 17:13:14 I think if you don't have those assets, we need to setup everything, infra projects, storyboard, etc. 17:13:33 ok 17:13:47 well, the project is now under openstack-infra/activity-board 17:13:51 and this is under gerrit and git 17:13:57 but we're not using storyboard 17:14:04 # link https://storyboard.openstack.org/#!/project/709 17:14:06 this could be a good opportunity to start using this 17:14:19 great, thanks :) 17:14:22 #info we have the project Activity Board on infra 17:14:48 (oh sorry for not using meetbot tags, I still have to learn u_u) 17:14:51 no we don't 17:15:23 yes we do... I'm so confused, been pinged from too many places already and it's only 9am here :) 17:15:24 #info we have the project Activity Board on Storyboard instead 17:16:00 so I think we should use this meeting to lay down a roadmap, draft a spec 17:16:14 that sounds good 17:16:16 ok, so we have a storyboard account, a git repo and some gerrit integration 17:16:29 I can detail if you want how we currently deploy activity board 17:16:37 please. 17:16:38 and then we may prepare that plan 17:16:46 ok, briefly 17:17:05 there are 3 main legs: retrieval process, metrics and analytics side, and visualization 17:17:28 the first step is python-based and goes through all of the data sources (irc, git, mailing lists, storyboard, etc) and retrieve all of the info 17:17:36 that stores all of the information in MySQL databases 17:17:46 is it some scheduled process? 17:17:54 each 24 hours this is run 17:17:58 using cron 17:18:00 ok. 17:18:08 (indeed the whole process) 17:18:20 the second part basically goes through all of the databases and start producing JSON files 17:18:45 then, those JSON files are visualized by the platform, and this is what you see in activvity.o.o 17:18:59 this is a basic a simple approach to the whole platform 17:19:20 as we were discussing during FOSDEM, a good starting point would be to start migrating the first part: the retrieval tools 17:19:39 so far, there's nothing created under the openstack infrastructure, but the visualization 17:20:08 mrmartin, shall I go a bit deeper into the first part: the retrieval tools? 17:20:17 yes 17:20:20 ok 17:20:30 https://github.com/openstack-infra/system-config/blob/master/manifests/site.pp 17:20:32 #info draft spec for this process https://etherpad.openstack.org/p/activity-infratization-spec 17:20:46 I'm checking this meanwhile, but I cannot found any servers related to activity.o.o 17:20:47 this is based on Metrics Grimoire https://github.com/MetricsGrimoire 17:20:48 geez, it took me 5 mins to find the template spec 17:21:04 and there's a tool for each data source 17:21:13 for instance, cvsanaly is focused on git activity 17:21:19 mrmartin, the current server was created manually 17:21:25 ok. 17:21:26 Mailing List Stats is focused on mailing lists 17:21:32 it's not a puppet server 17:21:44 Bicho is focused on Gerrit and Launchpad 17:21:49 (and lately storyboard) 17:21:51 etc 17:22:07 and those tools are installed by cloning the repo plus some standard libraries 17:22:21 do you have some packaging for python apps, like pip or deb ? 17:22:25 then, there's a list of options for each tool, like the URL of the service 17:22:33 mrmartin, I'm afraid we do not have that 17:22:55 but we may start producing those if that's easier for you 17:23:22 so for example, you are using an app for Mailing list stats, do you deploy multiple apps with different configurations 17:23:27 in the initial puppet recipe that was prepared by dpose, we cloned the repo and installed from sources (just for information) 17:23:40 or you have single app, and use a monolitic config? 17:24:16 mrmartin, afair this is all monolitic config 17:24:22 ok. 17:25:08 do you have a git repo for the puppet dpose is working on? 17:25:12 and well, as a first approach, it may be interesting to move the retrieval process under openstack 17:25:31 mrmartin, not yet, we can publish that for sure 17:25:45 some place under infra? 17:25:51 or maybe personal github account 17:26:12 ok, because it is a question, whether you like to maintain the puppet module, or move it under infra? 17:26:42 the infra's advantage that we can use the same toolset, as we are using for all other projects, including code review etc. 17:26:44 probably to move that under infra 17:26:59 I think that's the idea, reed ? 17:27:09 so anyone is more than welcome to participate :) 17:27:09 and then here, we need to do our fight with infra with let in this puppet 17:27:41 mrmartin, my main concern is that sometimes we need to reorganize part of the MySQL databases 17:27:48 based on features in the retrieval tools 17:27:51 what it means? 17:27:58 schema changes? 17:28:01 some example: we need either to add a new column to the database for some reason 17:28:04 yes, things like that 17:28:20 can we automatize that? 17:28:21 and I'm not sure if that's an issue 17:28:29 I'd say so 17:28:45 I think we can maintain the puppet module, it scales better than github pull requests 17:28:47 will this come as a part of the update? 17:28:50 the problem is the CLA 17:29:07 if you don't want to use the CLA then we can put it on stackforge 17:29:28 reed, what do you foresee as an issue wrt the CLA? 17:29:30 if you don't want to use stackforge, put it on github in your grimoire set 17:29:32 what is the license of those tools? 17:29:40 GPLv3 17:29:41 dizquierdo, it's annoying as hell 17:29:43 oh 17:29:47 ah ok reed 17:29:50 mrmartin, that's not an issue 17:30:24 probably github on your repos is the easiest option, since you already use it 17:30:31 as I know the puppet-modules under infra will be automagically published as puppet modules on forge in the near future 17:30:40 that's the plan 17:30:41 sure, from our side that's not an issue 17:31:15 but if you like to maintain your own puppet repo / handle module, it can work too 17:31:37 the openstack way have the advantage that we don't need to reinvent the wheel regarding some processes and toolsets 17:31:37 so reed your opinion is that we should maintain the puppet repo under our github account 17:31:48 I see mrmartin 17:32:02 but it is a decision, that must be made 17:32:02 mrmartin, I leave that decision up to you, I don't have a strong opinion 17:32:18 dizquierdo, are you confortable with the CLA? 17:32:26 you've already signed it, right? 17:32:32 for sure, as first step, we still need to play a bit, so we may have first versions under github, and later migrate to infra 17:32:37 we can start with a separate github repo, and move-in to openstack-infra if it is mature enough 17:32:37 reed, yes I signed that 17:32:46 yes, that sounds like a plan mrmartin 17:32:53 the other thing is that creating a new repo on infra will require weeks, while a new github repo is immediate 17:33:06 yeah, let's do that 17:33:10 yep 17:33:14 #info we can start with a separate github repo, and move-in to openstack-infra if it is mature enough 17:33:37 reed: event if it not takes for weeks, patch acceptance have some delivery time depending on the load of infra 17:33:40 event / even 17:34:13 #the github repos will contain the puppet modules to deploy and configure all grimoire toolsets (cvsanaly, mailing list stats, bicho, etc) 17:34:16 then, as a first action, we'll create that github repo 17:34:30 and send to you an email 17:34:40 mrmartin, we may need some help from your side 17:35:09 I hope we wont' be too annoying 17:35:37 reed, is the part of the OpenStack Foundation project? 17:36:01 so this migration project 17:36:38 dizquierdo, how much puppet experience your team have? 17:37:01 mrmartin, low I'm afraid 17:37:04 beginners 17:37:22 ok, so I'm used the puppetize using the following process: 17:37:37 1, write some spec about architecture, components, config required 17:38:05 2, do some detailed deployment guide, that explains everything step by step, so if I give it to a linux sysadmin he can do that 17:38:13 3, if all above works, puppetize the result 17:38:20 mrmartin, what's your question again? not sure I understand it 17:38:22 ok 17:38:58 we can start in that way 17:39:16 so if point 2 works well, we can identify some pain points the can cause problems during automatization 17:39:28 for example this schema change 17:39:51 or the deployment / packaging questions 17:39:55 ok, mrmartin we'll also add a list of potential issues we typically face when updating the toolset 17:39:56 or how-to upgrade things 17:40:05 yes, so we can deal with those in an automated way 17:40:13 update used to be a major problem usually 17:40:24 they're quite stable, but well... 17:40:25 there are updates 17:41:23 ok, so first of all I suggest to write the initial specs 17:41:39 setup the required github repos and accesses 17:41:59 and when we have a spec, we can estimate some delivery time 17:42:11 mrmartin, ok 17:42:17 and do regular meetings about the progress 17:42:32 and start to use storyboard 17:42:38 sure 17:43:01 reed, do you know when will storyboard email notifications start to work? 17:43:21 nope 17:43:55 #action write activity board migration spec 17:44:15 # info draft available on https://etherpad.openstack.org/p/activity-infratization-spec 17:44:29 #info draft available on https://etherpad.openstack.org/p/activity-infratization-spec 17:44:39 reed, do we need to create this spec under infra specs? 17:44:52 I think so, rigth? 17:44:57 ok, I agree 17:45:04 it's a similar process to askbot infratization 17:45:28 than the same story here, let's use the etherpad for collaborative work, to create a basic spec 17:45:40 mrmartin, http://paste.openstack.org/show/185288/ 17:45:42 and when it is in a good shape, push it through infra as an official spec 17:45:42 the thing is that we need to highlight in the spec that it's a long road and that we start small 17:45:49 these are our first steps with Puppet 17:45:52 (as an example) 17:46:39 I see, they should kill you asap due missing permission in file resources ;) 17:46:47 but looks promising 17:46:48 no requirements.txt? 17:47:09 ok, but first, let's focus on the spec 17:47:16 dizquierdo, is repositoryHandler in pip? 17:47:19 mmm we files that were created were init.pp, nodes.pp and site.pp 17:47:21 reed, nop 17:47:23 I agree, let's focus on the spec 17:47:25 ok 17:47:39 I suggest to create some minimal architecture diagram, that shows the basics 17:48:02 and explain all of the modules required, and highlight if some special configuration neeeded. 17:48:15 mrmartin, good idea... 17:48:15 ok 17:48:32 dizquierdo, do you have already a diagram for the grimoire tools? 17:48:32 #info create basic architecture diagram 17:48:57 reed, emm if you mean in terms of a picture, I think we have it around 17:49:11 if you mean in terms of specifications in a text file, I'm afraid not 17:49:18 yes, that's what I mean, I'm sure you have a picture somewhere 17:49:27 I'll look for that 17:49:55 a simple text diagram is enough 17:49:57 #action dizquierdo to look for a diagram (picture) of grimoire architecture to illustrate all the pieces 17:50:59 I'll try to find an example I made for one project 17:51:20 this one: https://review.openstack.org/#/c/140043/11/doc/source/askbot.rst 17:51:22 oh that's perfect, we can modify that according to the grimoire toolset 17:51:52 ok, and I suggest to do regular meetings 17:52:01 are you guys all located in EU? 17:52:03 mrmartin, sure 17:52:06 mrmartin, we are 17:52:17 not reed 17:52:36 I'm ok with taking this slot for community infra meeting 17:52:39 yes, I feel his problem in SFO ;) 17:52:45 this time is ok for me too. 17:52:53 i have no problem, I can also do one hour earlier 17:53:05 this 18.00 o'clock was better for me 17:53:16 this time is ok, and even later around 23 pm CET is ok for me 17:53:21 shall we set the meeting in the #openstack-meeting calendar? 17:53:26 and take this channel? 17:53:38 ok 17:53:39 yes, we can add this on wikipage 17:53:42 mrmartin, we end up syncing on other issues as well on MOndays anyway :) 17:54:21 #action reed to edit Meetings page and take #openstack-meeting-alt at 1700 UTC for #community meeting 17:54:22 so this channel is available until 19.00GMT (20.00CET) 17:54:39 17.00 UTC is perfect 17:54:58 ok, dizquierdo You can reach me during working hours also 17:54:59 it is 17:55:11 and we can share the results with reed on weekly meetings 17:55:12 mrmartin, ok, I'm also around during working hours 17:55:13 thanks 17:55:21 thanks in advance for your time mrmartin 17:55:54 ok, I guess the initial tasks are clear 17:56:21 yes 17:56:23 cool 17:56:39 thanks folks, I think we have a path forward. Let's meet again next week 17:56:48 thanks mrmartin and reed 17:56:59 ok, so the next meeting will be on March 09, 17.00GMT 17:57:00 we'll try to keep it shorter and keep on working offline, on community list 17:57:19 I'll be at the Operators Summit, I may be 'distracted' :) 17:57:24 but let's do it 17:57:32 :) 17:57:45 yeah, we are travelling sometimes 17:57:59 #endmeeting