16:00:31 <adrian_otto> #startmeeting Solum Team Meeting
16:00:32 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:35 <openstack> The meeting name has been set to 'solum_team_meeting'
16:00:45 <adrian_otto> #topic Roll Call
16:00:51 <adrian_otto> hello everyone
16:01:00 <roshanagr> Hello
16:01:00 <muralia> Murali Allada
16:01:04 <roshanagr> Roshan Agrawal
16:01:04 <jwforres> hello
16:01:06 <muralia> Hi
16:01:14 <funzo> Chris Alfonso, Red Hat
16:01:27 <dmakogon_> Denis Makogon, Mirantis
16:01:31 <coolsvap-mob> Swapnil Kulkarni
16:01:33 <datsun180b> Ed Cranford, rax
16:01:39 <roshanagr> welcome Ed
16:01:42 <dmakogon_> datsun180b, hi =)
16:01:59 <datsun180b> howdy
16:02:46 <devkulkarni> Devdatta Kulkarni
16:02:49 <tomblank> tom blankenship
16:03:05 <ragss> Rags Srinivas - new
16:03:12 <tdeckers> Tom Deckers
16:03:21 <aratim1> Arati Mahimane
16:03:23 <hartsocks> Shawn Hartsock - new (just curious)
16:03:27 <sapuri> Sandeep Puri
16:03:56 <paulmo> Paul Montgomery, Rackspace
16:04:39 <adrian_otto> 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 <adrian_otto> I recognize that last time I made us feel rushed, so we can try to fix that
16:05:35 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum Our Agenda
16:05:49 <adrian_otto> #topic Announcements
16:05:58 <adrian_otto> 1) Working Groups
16:06:11 <adrian_otto> we have two working groups now
16:06:22 <adrian_otto> meeting series are scheduled for each
16:06:23 <adrian_otto> Design meeting schedule published: https://wiki.openstack.org/wiki/Solum/BreakoutMeetings
16:06:51 <adrian_otto> 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 <adrian_otto> yesterday we had our first in the LP series
16:07:36 <adrian_otto> any other announcements from team members?
16:07:53 <kraman> git-integration series is scheduled for tomorrow
16:08:07 <kraman> December 4, 2013 1700 UTC
16:08:13 <adrian_otto> kraman: yes, thanks for setting that up! I'm looking forward to that
16:08:24 <adrian_otto> okay, let;s do blueprint status next
16:08:26 <adrian_otto> #topic Review Blueprints: https://launchpad.net/solum/+milestone/milestone-1
16:08:46 <adrian_otto> before I begin, I wanted to alert you to some adjustments in the milestone targeting
16:09:00 <adrian_otto> I have scoped a limited portion of the CLI to be implemented for milestone-1
16:09:11 <adrian_otto> and the full CLI can come in a subsequent milestone
16:09:35 <adrian_otto> the idea is that anyone taking an interest in the CLI can subscribe to the narrow scope blueprint too
16:09:40 <adrian_otto> and work together on that
16:10:06 <adrian_otto> we have done the same for the informational blueprints and big epic ones like the Git Integration one
16:10:20 <adrian_otto> note that the dependency graphs needed to be reversed, so I worked on that a bit too
16:10:29 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/api Solum API (aotto)
16:10:35 <adrian_otto> Status: Drafting revisions to definition/spec wiki based on feedback from Solum SFO Community Workshop
16:10:45 <adrian_otto> I did not make much progress last week due to time out for holidays
16:11:18 <adrian_otto> 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 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-minimal-cli Command Line Interface for Solum (devdatta-kulkarni)
16:11:40 <devkulkarni> Okay. So some updates on this one.
16:11:47 <adrian_otto> devkulkarni: tx
16:11:58 <devkulkarni> As Adrian mentioned, we have drafted a minimal cli.
16:12:04 <adrian_otto> (spec)
16:12:05 <devkulkarni> https://etherpad.openstack.org/p/MinimalCLI
16:12:16 <devkulkarni> yeah, just the spec
16:12:36 <devkulkarni> its still in the works. please take a look and give any feedback you may have.
16:12:38 <adrian_otto> we do have an active ML thread on this relating to stylistic concerns
16:12:45 <devkulkarni> yes
16:12:50 <adrian_otto> so if you take an interest we ask that you participate in that thread
16:12:56 <adrian_otto> LMK if you want a pointer to that
16:13:25 <devkulkarni> so apart from that I don't have any more update as such at this point.
16:13:45 <adrian_otto> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/020913.html ML Thread for CLI
16:13:52 <adrian_otto> ok, thanks devkulkarni
16:13:58 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-git-pull Pull integration of Solum from an external Git repo (kraman)
16:14:14 <kraman> Meeting for that is scheduled
16:14:30 <kraman> and the blueprint has some basic flow as well as unresolved questions.
16:14:56 <kraman> We should have a more concrete update for this BP in next weeks meeting
16:15:13 <adrian_otto> awesome, I look forward to the design meeting on this.
16:15:22 <adrian_otto> should I proceed?
16:15:26 <kraman> yes please
16:15:29 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/user-authentication User authentication for incoming requests (gokrokvertskhov)
16:15:34 <gokrokve> Hi
16:15:45 <gokrokve> Technically it is mostly done.
16:16:02 <gokrokve> There is an external issue in keystoneclient which does not work in python33.
16:16:17 <gokrokve> I am working with keystone team to figure out how to fix this.
16:16:34 <adrian_otto> gokrokve: I saw some discussion on that in #solum yesterday. Thanks for driving this.
16:16:53 <adrian_otto> is there any help you need from other team members to help you, or are you all set?
16:17:12 <gokrokve> I have some free time, so I can join any other development activities if there are some.
16:17:23 <adrian_otto> gokrokve:  !! :-) !!
16:17:40 <adrian_otto> #link https://review.openstack.org/58811
16:17:51 <adrian_otto> that's the review for gokrokve's auth code
16:18:19 <paulmo> Could we make sure that NoAuth is not a default setting?
16:18:20 <adrian_otto> 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 <gokrokve> paulmo: It will break unit tests.
16:19:16 <adrian_otto> how to other projects handle this?
16:19:20 <adrian_otto> s/to/do/
16:19:36 <gokrokve> adrian_otto: I can check this.
16:20:04 <adrian_otto> 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 <adrian_otto> paulmo has volunteered to represent us for security matters
16:20:31 <paulmo> I'm making notes in the review now, sorry to slow down the meeting. :)
16:20:39 <adrian_otto> paulmo: do you want to say a word about that?
16:20:51 <gokrokve> 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 <paulmo> 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 <adrian_otto> thanks paulmo
16:21:56 <adrian_otto> gokrokve: ok, thanks. Let's be sure to regroup on this.
16:22:16 <adrian_otto> maybe worth a little follow up in open discussion time today
16:22:23 <gokrokve> Sure. I need to figure out how to fix unit tests before enabling this by default.
16:22:28 <adrian_otto> #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 <adrian_otto> I think this one does not have status to report, right devkulkarni?
16:22:52 <devkulkarni> Okay, so this bp talks about the ability to specify a language pack as part of app registration.
16:23:10 <devkulkarni> the status is basically that I will start working on it
16:23:16 <adrian_otto> :-)
16:23:19 <adrian_otto> ok, thanks!
16:23:25 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/logging Logging Architecture (paulmo)
16:23:58 <paulmo> Status on logging:
16:24:14 <adrian_otto> 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 <paulmo> 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 <kgriffs> paulmo: +1
16:25:49 <adrian_otto> 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 <adrian_otto> for example, if we throw an exception, we don't want people's email addresses to show up in log files.
16:26:45 <adrian_otto> 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 <paulmo> Yes, Clayton actually implemented some of this using base Oslo Log.  He uses the extra field to add "private" data.
16:27:18 <devkulkarni> sounds like a good interim step.. no objections from me.
16:27:42 <paulmo> I suspect that most folks agree but the timing is the concern with the quick speed we are running at.
16:27:47 <datsun180b> I've seen a transaction-id or request-id pattern before for tracking these kinds of things in logs
16:27:47 <coolsvap> its a necessity i think to control what we log in terms of user private data
16:28:08 <adrian_otto> 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 <adrian_otto> s/though/thought/
16:28:57 <paulmo> 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 <adrian_otto> 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 <tomblank> coolsvap:  i agree and we should design for this from the beginning even though we may phase the implementation
16:29:46 <adrian_otto> #agreed to approve direction of https://blueprints.launchpad.net/solum/+spec/logging
16:29:50 <paulmo> Yay!
16:29:57 <adrian_otto> anything more on this one?
16:30:12 <coolsvap> +1
16:30:15 <adrian_otto> ok, next
16:30:15 <paulmo> No, I'm getting up to speed with the security group and willhave more next week I'm sure.
16:30:23 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/solum-zuul-integration Solum integration with Zuul (devdatta-kulkarni)
16:30:31 <adrian_otto> this is on here as an FYI, brand new
16:30:46 <devkulkarni> Okay, so I drafted this blueprint based on what we have discussed about Zuul.
16:31:00 <devkulkarni> I am not familiar with it that much.
16:31:03 <kraman> is this part of milestone-1 ?
16:31:15 <devkulkarni> kraman: I had the same question
16:31:27 <adrian_otto> devkulkarni: it is investigational in nature, so yes.
16:31:36 <adrian_otto> we can decide to table it if we judge this is too early
16:31:49 <adrian_otto> but I think we should base a decision from a well informed perspective
16:32:09 <adrian_otto> so although the priority is set Low on this, I did target it for M1
16:32:10 <kraman> I think we need to look a bit more into the push side of git0integration before we can investigate this
16:32:30 <rajdeep> i have one question on zuul integration
16:32:37 <kraman> If we can git through most of git-pull integration, I would not mind looking into this BP
16:32:37 <devkulkarni> or, does push git integration needs to first consider zuul?
16:32:38 <adrian_otto> kraman: perhaps we should be looking at those concurrently
16:33:17 <devkulkarni> rajdeep:?
16:33:19 <kraman> adrian_otto: sure, we can look at those to concurrently
16:33:28 <rajdeep> very few developers would know about this outside openstack community
16:34:11 <adrian_otto> 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 <devkulkarni> developers won't be exposed to zuul directly imo
16:34:27 <adrian_otto> and we should contrast this among other options too
16:34:58 <devkulkarni> Solum's 'push based git integration' feature should/could leverage zuul setup, if possible (that is the idea)
16:34:59 <kraman> adrian_otto: +1
16:35:04 <adrian_otto> so this might make a good etherpad discussion
16:35:17 <adrian_otto> where we list a bunch of possibilities, and work to pro/con each
16:35:41 <adrian_otto> but I think we have some homework to do leading up to that, right?
16:35:53 <devkulkarni> adrian_otto: yes we do.
16:36:01 <devkulkarni> and +1 for etherpad discussion
16:36:02 <kraman> yes, I need to read up on Zuul and other OpenStack tools
16:36:04 <funzo> The git integration shouldn't be dependent upon external services should it?
16:36:27 <funzo> I mean as an option it could integrate Zuul, but you wouldn't want someone to have to use it
16:36:31 <adrian_otto> funzo: like github?
16:36:36 <kraman> funzo: the git-push BP may be able to leverage existing OS tools
16:36:41 <devkulkarni> funzo: are you thinking zuul as an external service?
16:36:48 <coolsvap> #link http://ci.openstack.org/zuul.html
16:37:00 <adrian_otto> coolsvap: thanks for the link!
16:37:21 <funzo> 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 <adrian_otto> I think they would need to use push in that case
16:37:56 <funzo> ok, I missed the idea that it would be a secondary flow or optional
16:38:05 <funzo> carry on
16:38:07 <adrian_otto> but whatever workflow/job solution we use, it will need to be tightly integrated
16:38:13 <funzo> kk
16:38:18 <adrian_otto> so that it acts like a "part" of Solum
16:38:33 <adrian_otto> maybe more on this tomorrow
16:38:43 <rajdeep_> is gerrit also part of the flow?
16:38:49 <kraman> yes, i have an item in agenda to discuss existing tools
16:39:08 <adrian_otto> rajdeep_: good question, not in milestone-1
16:39:18 <rajdeep_> ok
16:39:21 <funzo> 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 <adrian_otto> but we will have a CI flow in a subsequent milestone
16:39:35 <devkulkarni> kraman: for tomorrow, we are going to target just the solum-git-pull, or both pull and push?
16:39:43 <rajdeep_> gerrit is pretty neat
16:39:48 <rajdeep_> but keep it optional
16:39:49 <kraman> devkulkarni: just pull
16:40:16 <adrian_otto> ok, so that brings us to a nice chunk of time for open discussion today.
16:40:23 <kraman> devkulkarni: I would like to get all tasks for Milestone-1 started before we start looking at push
16:40:26 <adrian_otto> #topic Open Discussion
16:40:52 <muralia> adrian_otto: should the api worker architecture blueprint be included in milestone1?
16:40:58 <muralia> https://blueprints.launchpad.net/solum/+spec/api-worker-architecture
16:40:58 <devkulkarni> 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 <funzo> 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 <kraman> devkulkarni: probably not
16:41:46 <funzo> 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 <devkulkarni> kraman: thanks!
16:41:56 <adrian_otto> muralia: yes, we should probably scope that in
16:42:17 <adrian_otto> at least for some of the basics
16:42:20 <devkulkarni> funzo: was that decided? I personally like to keep things in the whiteboard section of BP itself.
16:42:38 <muralia> ok. thanks.
16:42:39 <funzo> devkulkarni: I thought that was the decision, maybe I misunderstood
16:43:15 <adrian_otto> funzo the whitebard may actually have a length lmit
16:43:18 <roshanagr> funzo: if the content is more detailed, then wiki page is a better location
16:43:38 <funzo> kk
16:43:55 <adrian_otto> 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 <adrian_otto> you can ask team members to bump the whiteboard in some way when they edit external resources
16:44:33 <adrian_otto> that way anyone subscribed keeps up to date with those details
16:45:04 <devkulkarni> adrian_otto: yeah, I like that when you update the BP subscribers are notified.
16:45:32 <adrian_otto> definitely my favorite feature of Lauchpad
16:46:05 <adrian_otto> let's just be cautious not to rely too much on that facility, and use the ML too
16:46:25 <adrian_otto> as that's where we are going to get a diverse base of input
16:46:41 <devkulkarni> makes sense
16:48:03 <adrian_otto> gokrokve: I am concerned about your review a little bit, as it will time out after a week of inactivity
16:48:44 <adrian_otto> there is a way to revive one I think
16:48:50 <gokrokve> adrian_otto: I can add new patch set in order to update it.
16:49:11 <adrian_otto> so as you get good feedback from reviewers, continue to iterate
16:49:25 <adrian_otto> anything I can be doing to help you all more?
16:49:49 <adrian_otto> one idea was a getting started "new contributor" wiki page
16:50:09 <adrian_otto> that details how to get involved and where we can use more participation
16:50:19 <gokrokve> 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 <adrian_otto> I have seen a nice boost in the number of code reviews, so thanks everyone for stepping up to that challenge.
16:51:38 <adrian_otto> gokrokve: wouldn't that weaken the value of the unit tests as py33 becomes our primary focus?
16:52:17 <gokrokve> adrian_otto: No. It will be a workaround which will work only in case of import failure.
16:52:55 <adrian_otto> actually, that might save me time on code review duty
16:53:07 <adrian_otto> as I look at a lot of patches that fail for that reason
16:53:38 <adrian_otto> 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 <paulczar> 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 <adrian_otto> 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 <adrian_otto> ok, any more for today, or would you like to wind down?
16:56:17 <paulczar> I would love to get some feedback on the vagrant environment I'm building - https://github.com/rackerlabs/vagrant-solum-dev
16:56:54 <adrian_otto> paulczar: I am interested in a compare/contrast on using devstack vs. vagrant
16:57:24 <devkulkarni> 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 <paulczar> 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 <adrian_otto> ok, so they are complimentary?
16:58:19 <kraman> adrian_otto: yes
16:58:24 <coolsvap> paulczar: I will check that tonight...
16:58:31 <adrian_otto> cool, I am checking to be sure I subscribe to that one!
16:58:36 <kraman> adrian_otto: vagrant allows you to spin up a Vm and run commands within it
16:58:42 <coolsvap> nice to bring that up
16:58:43 <kraman> in this case we will be running devstack
16:59:05 <paulczar> 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 <kraman> im looking into integration with fedora
16:59:19 <adrian_otto> ok, so we are coming to the end of our time for today.
16:59:31 <adrian_otto> we can continue discussion in #solum
16:59:53 <adrian_otto> thanks everyone for attending today. I felt that this one went a lot smoother than last week.
17:00:03 <adrian_otto> #endmeeting