16:00:31 #startmeeting Solum Team Meeting 16:00:32 Meeting started Tue Dec 3 16:00:31 2013 UTC and is due to finish in 60 minutes. The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:35 The meeting name has been set to 'solum_team_meeting' 16:00:45 #topic Roll Call 16:00:51 hello everyone 16:01:00 Hello 16:01:00 Murali Allada 16:01:04 Roshan Agrawal 16:01:04 hello 16:01:06 Hi 16:01:14 Chris Alfonso, Red Hat 16:01:27 Denis Makogon, Mirantis 16:01:31 Swapnil Kulkarni 16:01:33 Ed Cranford, rax 16:01:39 welcome Ed 16:01:42 datsun180b, hi =) 16:01:59 howdy 16:02:46 Devdatta Kulkarni 16:02:49 tom blankenship 16:03:05 Rags Srinivas - new 16:03:12 Tom Deckers 16:03:21 Arati Mahimane 16:03:23 Shawn Hartsock - new (just curious) 16:03:27 Sandeep Puri 16:03:56 Paul Montgomery, Rackspace 16:04:39 Lots of newcomers. Welcome to you all. Okay, so this meeting I'm going to be a lot less ambitious than last week my goal is to give us a big chunk of time for open discussion. The way I think we can do this is by keeping our Blueprint status relatively short per each, letting the owner of the blueprint give an overview of where we are and next steps. 16:05:04 I recognize that last time I made us feel rushed, so we can try to fix that 16:05:35 #link https://wiki.openstack.org/wiki/Meetings/Solum Our Agenda 16:05:49 #topic Announcements 16:05:58 1) Working Groups 16:06:11 we have two working groups now 16:06:22 meeting series are scheduled for each 16:06:23 Design meeting schedule published: https://wiki.openstack.org/wiki/Solum/BreakoutMeetings 16:06:51 please take a moment to see if you will be participating in design for either of those groups, and attend those design meetings 16:07:03 yesterday we had our first in the LP series 16:07:36 any other announcements from team members? 16:07:53 git-integration series is scheduled for tomorrow 16:08:07 December 4, 2013 1700 UTC 16:08:13 kraman: yes, thanks for setting that up! I'm looking forward to that 16:08:24 okay, let;s do blueprint status next 16:08:26 #topic Review Blueprints: https://launchpad.net/solum/+milestone/milestone-1 16:08:46 before I begin, I wanted to alert you to some adjustments in the milestone targeting 16:09:00 I have scoped a limited portion of the CLI to be implemented for milestone-1 16:09:11 and the full CLI can come in a subsequent milestone 16:09:35 the idea is that anyone taking an interest in the CLI can subscribe to the narrow scope blueprint too 16:09:40 and work together on that 16:10:06 we have done the same for the informational blueprints and big epic ones like the Git Integration one 16:10:20 note that the dependency graphs needed to be reversed, so I worked on that a bit too 16:10:29 #link https://blueprints.launchpad.net/solum/+spec/api Solum API (aotto) 16:10:35 Status: Drafting revisions to definition/spec wiki based on feedback from Solum SFO Community Workshop 16:10:45 I did not make much progress last week due to time out for holidays 16:11:18 so I don't have a long update for you on this. Please stay tuned as a blueprint subscriber if you are interested in this one. I will post into the whiteboard upon revision of the proposal. 16:11:26 #link https://blueprints.launchpad.net/solum/+spec/solum-minimal-cli Command Line Interface for Solum (devdatta-kulkarni) 16:11:40 Okay. So some updates on this one. 16:11:47 devkulkarni: tx 16:11:58 As Adrian mentioned, we have drafted a minimal cli. 16:12:04 (spec) 16:12:05 https://etherpad.openstack.org/p/MinimalCLI 16:12:16 yeah, just the spec 16:12:36 its still in the works. please take a look and give any feedback you may have. 16:12:38 we do have an active ML thread on this relating to stylistic concerns 16:12:45 yes 16:12:50 so if you take an interest we ask that you participate in that thread 16:12:56 LMK if you want a pointer to that 16:13:25 so apart from that I don't have any more update as such at this point. 16:13:45 #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/020913.html ML Thread for CLI 16:13:52 ok, thanks devkulkarni 16:13:58 #link https://blueprints.launchpad.net/solum/+spec/solum-git-pull Pull integration of Solum from an external Git repo (kraman) 16:14:14 Meeting for that is scheduled 16:14:30 and the blueprint has some basic flow as well as unresolved questions. 16:14:56 We should have a more concrete update for this BP in next weeks meeting 16:15:13 awesome, I look forward to the design meeting on this. 16:15:22 should I proceed? 16:15:26 yes please 16:15:29 #link https://blueprints.launchpad.net/solum/+spec/user-authentication User authentication for incoming requests (gokrokvertskhov) 16:15:34 Hi 16:15:45 Technically it is mostly done. 16:16:02 There is an external issue in keystoneclient which does not work in python33. 16:16:17 I am working with keystone team to figure out how to fix this. 16:16:34 gokrokve: I saw some discussion on that in #solum yesterday. Thanks for driving this. 16:16:53 is there any help you need from other team members to help you, or are you all set? 16:17:12 I have some free time, so I can join any other development activities if there are some. 16:17:23 gokrokve: !! :-) !! 16:17:40 #link https://review.openstack.org/58811 16:17:51 that's the review for gokrokve's auth code 16:18:19 Could we make sure that NoAuth is not a default setting? 16:18:20 please review that so we can get some good feedback to him while we await resolution of the keystone concern that's blocking the py33 gate 16:18:42 paulmo: It will break unit tests. 16:19:16 how to other projects handle this? 16:19:20 s/to/do/ 16:19:36 adrian_otto: I can check this. 16:20:04 gokrokve: thanks. The nature of paulmo's concern is that auth on is a best practice for security. 16:20:15 * paulmo nods 16:20:30 paulmo has volunteered to represent us for security matters 16:20:31 I'm making notes in the review now, sorry to slow down the meeting. :) 16:20:39 paulmo: do you want to say a word about that? 16:20:51 adrian_otto: Yes I understand this. But when I tried to do this I saw that almost all test cases failed due to 401 error response fron API server. 16:21:26 Sure! I just joined the OpenStack Security Group. They have a 52 chapter security guideline set up already. They want a member in each OpenStack project ideally so I'll look towards representing Solum. Others are more than welcome to join! 16:21:52 thanks paulmo 16:21:56 gokrokve: ok, thanks. Let's be sure to regroup on this. 16:22:16 maybe worth a little follow up in open discussion time today 16:22:23 Sure. I need to figure out how to fix unit tests before enabling this by default. 16:22:28 #link https://blueprints.launchpad.net/solum/+spec/specify-lang-pack Specify the language pack to be used for app deploy (devdatta-kulkarni) 16:22:52 I think this one does not have status to report, right devkulkarni? 16:22:52 Okay, so this bp talks about the ability to specify a language pack as part of app registration. 16:23:10 the status is basically that I will start working on it 16:23:16 :-) 16:23:19 ok, thanks! 16:23:25 #link https://blueprints.launchpad.net/solum/+spec/logging Logging Architecture (paulmo) 16:23:58 Status on logging: 16:24:14 this one I am interested to gauge whether we have enough consensus for me to mark this as Approved directionally (pending proposal) 16:24:27 I joined the OSSG to get consensus from the security minded folks in OpenStack to see if Oslo log changes would make sense. 16:25:15 paulmo: +1 16:25:49 does anyone object to the idea of logging some additional metadata with our oslo logging calls so that it would be possible to use downstream middleware later to filter out PII and secrets that we know might show up in logs? 16:26:21 for example, if we throw an exception, we don't want people's email addresses to show up in log files. 16:26:45 so we might use a hint in the logging call to identify where that data might appear. Do I understand this right, paulmo? 16:27:17 Yes, Clayton actually implemented some of this using base Oslo Log. He uses the extra field to add "private" data. 16:27:18 sounds like a good interim step.. no objections from me. 16:27:42 I suspect that most folks agree but the timing is the concern with the quick speed we are running at. 16:27:47 I've seen a transaction-id or request-id pattern before for tracking these kinds of things in logs 16:27:47 its a necessity i think to control what we log in terms of user private data 16:28:08 I though Clayton's approach was a good compromise that suit our interests to leverage Oslo code while giving us the ability to be more secure later. 16:28:15 s/though/thought/ 16:28:57 I also found that there are special Gerrit review tags for security and I'm looking for the OpenStack comment style to indicate possible security issues if the developer doesn't have time to fix it immediately but wants to mark it to review later. 16:29:14 okay, so in the absense of any objections, I'm planning to approve the diection of this blueprint, and we can collaborate on the details of the implementation before we mark the design as approved. 16:29:30 coolsvap: i agree and we should design for this from the beginning even though we may phase the implementation 16:29:46 #agreed to approve direction of https://blueprints.launchpad.net/solum/+spec/logging 16:29:50 Yay! 16:29:57 anything more on this one? 16:30:12 +1 16:30:15 ok, next 16:30:15 No, I'm getting up to speed with the security group and willhave more next week I'm sure. 16:30:23 #link https://blueprints.launchpad.net/solum/+spec/solum-zuul-integration Solum integration with Zuul (devdatta-kulkarni) 16:30:31 this is on here as an FYI, brand new 16:30:46 Okay, so I drafted this blueprint based on what we have discussed about Zuul. 16:31:00 I am not familiar with it that much. 16:31:03 is this part of milestone-1 ? 16:31:15 kraman: I had the same question 16:31:27 devkulkarni: it is investigational in nature, so yes. 16:31:36 we can decide to table it if we judge this is too early 16:31:49 but I think we should base a decision from a well informed perspective 16:32:09 so although the priority is set Low on this, I did target it for M1 16:32:10 I think we need to look a bit more into the push side of git0integration before we can investigate this 16:32:30 i have one question on zuul integration 16:32:37 If we can git through most of git-pull integration, I would not mind looking into this BP 16:32:37 or, does push git integration needs to first consider zuul? 16:32:38 kraman: perhaps we should be looking at those concurrently 16:33:17 rajdeep:? 16:33:19 adrian_otto: sure, we can look at those to concurrently 16:33:28 very few developers would know about this outside openstack community 16:34:11 so my thinking on this is if we can afford to spend some cycles on understanding our options, then we can make a well informed choice on how to implement the various Git related features 16:34:21 developers won't be exposed to zuul directly imo 16:34:27 and we should contrast this among other options too 16:34:58 Solum's 'push based git integration' feature should/could leverage zuul setup, if possible (that is the idea) 16:34:59 adrian_otto: +1 16:35:04 so this might make a good etherpad discussion 16:35:17 where we list a bunch of possibilities, and work to pro/con each 16:35:41 but I think we have some homework to do leading up to that, right? 16:35:53 adrian_otto: yes we do. 16:36:01 and +1 for etherpad discussion 16:36:02 yes, I need to read up on Zuul and other OpenStack tools 16:36:04 The git integration shouldn't be dependent upon external services should it? 16:36:27 I mean as an option it could integrate Zuul, but you wouldn't want someone to have to use it 16:36:31 funzo: like github? 16:36:36 funzo: the git-push BP may be able to leverage existing OS tools 16:36:41 funzo: are you thinking zuul as an external service? 16:36:48 #link http://ci.openstack.org/zuul.html 16:37:00 coolsvap: thanks for the link! 16:37:21 devkulkarni: adrian_otto: I was just thinking about when developers don't have external connectivity how they would complete a git flow 16:37:34 I think they would need to use push in that case 16:37:56 ok, I missed the idea that it would be a secondary flow or optional 16:38:05 carry on 16:38:07 but whatever workflow/job solution we use, it will need to be tightly integrated 16:38:13 kk 16:38:18 so that it acts like a "part" of Solum 16:38:33 maybe more on this tomorrow 16:38:43 is gerrit also part of the flow? 16:38:49 yes, i have an item in agenda to discuss existing tools 16:39:08 rajdeep_: good question, not in milestone-1 16:39:18 ok 16:39:21 rajdeep_: since you can start the push with a git review, it seems like it wouldn't be terribly difficult to have that as an option 16:39:33 but we will have a CI flow in a subsequent milestone 16:39:35 kraman: for tomorrow, we are going to target just the solum-git-pull, or both pull and push? 16:39:43 gerrit is pretty neat 16:39:48 but keep it optional 16:39:49 devkulkarni: just pull 16:40:16 ok, so that brings us to a nice chunk of time for open discussion today. 16:40:23 devkulkarni: I would like to get all tasks for Milestone-1 started before we start looking at push 16:40:26 #topic Open Discussion 16:40:52 adrian_otto: should the api worker architecture blueprint be included in milestone1? 16:40:58 https://blueprints.launchpad.net/solum/+spec/api-worker-architecture 16:40:58 kraman: ok. in that case in the existing tools item on agenda, we won't be discussing/bringing up zuul I suppose 16:41:19 Yesterday during the lp workgroup discussion, we said details of the blueprints should stay in the blueprints and not on the wiki. That should be the case for all the blueprint details, correcdt? 16:41:35 devkulkarni: probably not 16:41:46 it's worth noting here so that blueprint owners that weren't in that lp workgroup know to be consistent about it 16:41:47 kraman: thanks! 16:41:56 muralia: yes, we should probably scope that in 16:42:17 at least for some of the basics 16:42:20 funzo: was that decided? I personally like to keep things in the whiteboard section of BP itself. 16:42:38 ok. thanks. 16:42:39 devkulkarni: I thought that was the decision, maybe I misunderstood 16:43:15 funzo the whitebard may actually have a length lmit 16:43:18 funzo: if the content is more detailed, then wiki page is a better location 16:43:38 kk 16:43:55 usually the part on the BP itself is summary in nature, and the implementation details are supplied separately, in reviews or other materials, including Wiki, etc. 16:44:21 you can ask team members to bump the whiteboard in some way when they edit external resources 16:44:33 that way anyone subscribed keeps up to date with those details 16:45:04 adrian_otto: yeah, I like that when you update the BP subscribers are notified. 16:45:32 definitely my favorite feature of Lauchpad 16:46:05 let's just be cautious not to rely too much on that facility, and use the ML too 16:46:25 as that's where we are going to get a diverse base of input 16:46:41 makes sense 16:48:03 gokrokve: I am concerned about your review a little bit, as it will time out after a week of inactivity 16:48:44 there is a way to revive one I think 16:48:50 adrian_otto: I can add new patch set in order to update it. 16:49:11 so as you get good feedback from reviewers, continue to iterate 16:49:25 anything I can be doing to help you all more? 16:49:49 one idea was a getting started "new contributor" wiki page 16:50:09 that details how to get involved and where we can use more participation 16:50:19 adrian_otto: I think I can fix test cases to not fail with exception on python33 but just do not execute them in case of import exception. 16:50:34 I have seen a nice boost in the number of code reviews, so thanks everyone for stepping up to that challenge. 16:51:38 gokrokve: wouldn't that weaken the value of the unit tests as py33 becomes our primary focus? 16:52:17 adrian_otto: No. It will be a workaround which will work only in case of import failure. 16:52:55 actually, that might save me time on code review duty 16:53:07 as I look at a lot of patches that fail for that reason 16:53:38 so I'm open to trying that to see how it works. I'm also interested in input from other team members for additional perspective. 16:53:54 adrian / gokrokve: there is a button to revive reviews that have been abandoned from age … but agree better not to let it age out in the first place. 16:54:37 paulczar: right, if we are waiting a week between revisions or abandonment, then we probably have something assigned to someone who is too busy. 16:56:08 ok, any more for today, or would you like to wind down? 16:56:17 I would love to get some feedback on the vagrant environment I'm building - https://github.com/rackerlabs/vagrant-solum-dev 16:56:54 paulczar: I am interested in a compare/contrast on using devstack vs. vagrant 16:57:24 fyi, a bp for this has been created as well: https://blueprints.launchpad.net/solum/+spec/vagrant-based-solum-local-development-environment 16:57:39 the vagrant file itself is a little long winded but if you run it with `SOLUM=~/dev/solum vagrant up devstack` it will bring up a vagrant box, map your solum directory to /solum on it, and add the solum devstack integration and then bring up solum. 16:58:11 ok, so they are complimentary? 16:58:19 adrian_otto: yes 16:58:24 paulczar: I will check that tonight... 16:58:31 cool, I am checking to be sure I subscribe to that one! 16:58:36 adrian_otto: vagrant allows you to spin up a Vm and run commands within it 16:58:42 nice to bring that up 16:58:43 in this case we will be running devstack 16:59:05 also `TESTS=true SOLUM=~/dev/solum vagrant up api` will spin up a box with all the bits needed to do run all the tests ( and will run them for you ) 16:59:07 im looking into integration with fedora 16:59:19 ok, so we are coming to the end of our time for today. 16:59:31 we can continue discussion in #solum 16:59:53 thanks everyone for attending today. I felt that this one went a lot smoother than last week. 17:00:03 #endmeeting