15:30:05 <mfer> #startmeeting openstack-sdk-php
15:30:06 <openstack> Meeting started Wed Apr 16 15:30:05 2014 UTC and is due to finish in 60 minutes.  The chair is mfer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:09 <openstack> The meeting name has been set to 'openstack_sdk_php'
15:30:23 <mfer> Hello everyone. If you couple please state your name along with any association
15:30:26 <mfer> Matt Farina, HP
15:30:29 <samchoi> Sam Choi, HP
15:30:32 <jamie_h> Jamie Hannaford, Rackspace
15:30:35 <ycombinator> Shaunak Kashyap, Rackspace
15:31:02 <glenc> Glen Campbell, Rackspace
15:32:41 <mfer> #topic Agenda
15:32:46 <mfer> #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP
15:33:05 <mfer> I updated the agenda on the Wiki. It's simliar to the last one.
15:33:38 <mfer> The first item was an intro if anyone new came. As it's the regular attenders I don't think we need to introduce the PHP SDK and can skip that item
15:34:15 <mfer> So, let's move tot he second item
15:34:21 <mfer> #topic State of the codebase
15:35:06 <mfer> Since we spoke last Wednesday I did a bunch of due diligence. I spoke with others in the community about process, community, history, and looked through other projects for examples
15:35:37 <mfer> So, it's taken a little time to do this legwork. Thanks for being patient with me. I wanted to get some good well rounded guidance.
15:36:16 <mfer> In the community sense I didn't want to make any decisions without doing the legwork and taking time to contact others with more experience
15:36:44 <mfer> that includes going outside HP. Please don't think that I only spoke with others at HP. I wanted a wider perspective than that
15:37:06 <mfer> I want the PHP SDK to be something that helps OpenStack and those that use it.
15:37:29 <mfer> All that being said...
15:37:53 <glenc> http://www.dramabutton.com
15:38:07 <samchoi> *drumroll*
15:38:19 <mfer> My stance is to keep the current codebase and continue on the path of re-factoring to better support OpenStack. We have a roadmap that will get us there.
15:38:57 <jamie_h> samchoi What do you think, Sam?
15:39:13 <mfer> I'd shared that if there was a better technological solution (measurable?) or a way to get there for OpenStack far faster we should talk about it. In the past few weeks since this came up a case has not been made for that.
15:40:32 <mfer> questions or other discussion on this point?
15:40:46 <mfer> i'm happy to add context as needed.
15:42:11 <jamie_h> mfer Did you read the e-mail I sent Sam? How do you respond to the three very strong points made there
15:43:43 <samchoi> My take on all of this is that I believe that using the current codebase would be the fastest route to make a pure OpenStack SDK available. I also understand there may be dissenting opinions on design/architecture. To be quite honest, I am not so concerned with debating design/architecture and believe a compromise may be to allow other contributors to get involed and make significant changes when necessary.
15:44:02 <glenc> Well, I disagree that it would get us broader support for OpenStack faster. If, for example, we used php-opencloud as a base, we'd have support for Nova, Swift, and Trove already, plus Heat in progress and some others. The current code base only supports Swift. Both cases would require refactoring. Plus, it already supports Guzzle. We need to understand that this decision involves stepping back and re-doing work that already exists.
15:44:26 <mfer> jamie_h I did see the email. I used is as a starting point for some of my research. I wanted to be able to clearly understand each point. My goal is to think long term best for the community, those that use the SDK, and the project itself.
15:44:54 <glenc> Having said that, this decision has already cost us some number of man-months. No matter what the decision, if we had made a decision earlier, we would be further along.
15:45:09 <mfer> glenc if you don't mind i'd like to address jamie_h before i circle back to your comment. i want you do know that i'm not forgetting it but i want touch there first.
15:45:28 <glenc> understood
15:46:22 <jamie_h> mfer I don't understand your counter-argument to our main point about community process. All code needs to be approved through Gerrit - that's a very foundational point about contributing to OpenStack. I don't see how consulting people on a few non-OpenStack projects gets around or addresses this issue...
15:46:41 <mfer> jamie_h the first point you brought up was the community angle. For our code we'd long used a process similar to what we do in Gerrit. So, when the codebase was put into Stackforge it was a transition not a change of pace.
15:47:31 <mfer> if you look at a majority of projects to come into the community they start with an existing codebase that's imported. the infra process to create a new project as a mechanism to pull in an existing codebase when it's setup. it's automated
15:47:32 <jamie_h> mfer sure, but none of the code was submitted through Gerrit. What you did before that is moot
15:47:59 <mfer> all code that's come in since that import has gone through gerrit. this is typical.
15:48:05 <jamie_h> mfer but we're not talking about generic projects, we're integrating into a very established larger project with rules
15:48:18 <mfer> you can look at other example projects like barbacon, from Rackspace, and can see this in practice
15:48:29 <jamie_h> mfer new code has, but the vast majority of existing code has not been reviewed
15:48:49 <jamie_h> I've yet to hear a good reason to break OpenStack rules/protocol
15:49:00 <jamie_h> apart from "it'll be faster"
15:49:16 <mfer> from doing my due diligence here, the way this is handled is within the rules/protocols.
15:49:43 <mfer> this is how other projects have gone in. Even project started by those at Rackspace
15:49:56 <jamie_h> the python SDK doesn't
15:49:58 <mfer> this is not stepping outside the process or what happens in practice
15:50:12 <jamie_h> it is, because we're inheriting a codebase that's not gone through any review process
15:50:19 <mfer> the python SDK is an outlier from the norm.
15:51:11 <jamie_h> I disagree. It's taking a very sensible and democratic approach
15:51:12 <mfer> So, for the first point... we're holding to the process and what has typically happened.
15:51:36 <jamie_h> No, we're really not. Allowing unreviewed code is a clear breach of standard protocol
15:51:41 <jamie_h> IMHO
15:52:31 <mfer> jamie_h may I test your point quickly. So, when barbacon was brought in should all of the code been removed and the project started from scratch. it was an existing codebase that was importent.
15:53:00 <mfer> please note, we've invited you and others to review the current codebase and file any issues found that are not already filed
15:54:34 <jamie_h> I'm not familiar with how older projects did things, I'm focusing on how we do it according to present rules
15:55:56 <mfer> can you point me to these present rules in writing? as of now I've heard your opinion on how we should do things. but, i've gone to others in the community with a lot of insight into the rules and the way the community operates now and historically.
15:56:20 <mfer> what i've learned is that this approach is appropriate
15:58:34 <jamie_h> mfer who exactly did you consult in the community? Have they had much exposure to OpenStack workflow?
15:58:55 <jamie_h> My point is that a typical PHP project, for example, might have a different workflow than OpenStack
15:59:17 <mfer> i'm not going to share names because I didn't ask them first. I will say I spoke to folks on the TC and who are PTLs
15:59:24 <samchoi> jamie_h: can you elaborate on that?
15:59:50 <mfer> jamie_h and others who have experience in the community outside that
16:01:33 <samchoi> jamie_h: you're referring to PHP projects outside of OpenStack, correct?
16:02:51 <mfer> given the time and that the conversation on this point seems to have stopped i'll move on to the second point of community
16:03:24 <jamie_h> I don't think we've reached consensus yet
16:03:52 <mfer> jamie_h at what point will we reach concensus?
16:04:12 <jamie_h> I don't agree with any of the counter-points made here, but I agree that we need to move forward
16:04:13 <mfer> we have 27 minutes left in this meeting, there are two other areas, and the question from glenc
16:04:37 <ycombinator> what jamie_h said
16:04:38 <jamie_h> This is my opinion:
16:04:52 <ycombinator> I think we need to move on
16:04:54 <samchoi> let's try to address the other topics quickly and come back to this?
16:04:59 <jamie_h> Okay
16:05:19 <jamie_h> I'm content to use the current codebase on the sole condition that everyone's open to the idea of aggressive refactoring
16:05:44 <samchoi> jamie_h: that was my thought actually...I felt it to be a good compromise
16:05:48 <ycombinator> yeah, I'm not seeing another way forward
16:06:04 <mfer> jamie_h that's what we've been doing. the roadmap assumes that.
16:06:11 <jamie_h> I don't want to be in a position were we're implicitly agreeing on the current code. So if we agree to allow people to refactor parts, it's a decent compromise
16:06:15 <mfer> you'll notice it has guzzle4 support already
16:06:25 <jamie_h> Sure, but I didn't know whether people might cling to certain existing concepts or areas of code
16:06:47 <jamie_h> By being in the codebase they'll already have quasi-approval
16:06:48 <mfer> there are definitely patterns to keep in the current code and to expand on. but, there are other things that need to change.
16:07:23 <mfer> for example, we are working to make PSR-2 happen, we use http messages from FIG and guzzle as a default (a suggestion from jamie_h), and more
16:07:53 <jamie_h> Okay, I'm satisfied here. Shaunak and Glen, do you have anything else to add?
16:08:09 <ycombinator> no, lets move on
16:08:12 <mfer> I'm happy to address the point from Glen still if needed
16:08:27 <glenc> no need to address -
16:08:50 <glenc> was just making the point that IMHO this is *not* the fastest way to get working code, but willing to defer that and use a slower path to get us moving
16:09:25 <ycombinator> yeah, I think the time we are losing in figuring out fastest path > choosing A path and moving on
16:09:29 <ycombinator> so lets move on :)
16:10:00 <mfer> glenc note, we have a much larger codebase that implements many other services. we have months and months and months of work on that. not contributing all of that back at the onset was intentional so we could refactor things. for example, to handle multiple API versions. something that I've only seen done well in the openstack client projects
16:10:45 <mfer> shall we move on to the near term roadmap?
16:10:46 <jamie_h> That's untrue, we actually have a considerably bigger codebase with more public support. But this is not really important after what we've just agreed on
16:11:05 <jamie_h> Yeah, let's move on
16:11:08 <ycombinator> yeah, lets not rehash this; mfer: please move on to the near term roadmap
16:11:49 <glenc> Not willing to argue the point; would rather move on
16:12:03 <mfer> #topic Near term roadmap
16:12:13 <mfer> #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Short_Term_Roadmap
16:12:35 <mfer> as per my action from the last meeting, I linked the blueprints to the roadmap
16:13:03 <mfer> The guzzle 4 work and phpdoc change has already been completed
16:13:25 <mfer> next up, and not on here but happening, is the shift to PSR-2 that samchoi is working on
16:13:44 <jamie_h> samchoi how are you getting on with PSR-2?
16:13:55 <samchoi> good, I'm reviewing diff logs from an automated tool
16:14:04 <mfer> https://github.com/fabpot/PHP-CS-Fixer
16:14:15 <samchoi> I'm primarily checking to see if certain coding conventions are NOT addressed by the tool
16:14:25 <samchoi> but all good thus far
16:15:20 <jamie_h> if you use PhpStorm, you can do it with that too. It has a neat reformatting tool
16:15:31 <jamie_h> you can do it across a project directory
16:17:31 <mfer> the next item to tackle once that is done is to add multiple api version support. i'd hoped to have that done but went after Guzzle first after you suggested it.
16:18:14 <jamie_h> mfer I think that's related to the service layer. I want to get stuck into that next week. I've nearly finalized my experimentation with json-schema, so it's at a point were we can think incorporating it
16:18:43 <mfer> ok
16:19:06 <mfer> i've been talking with others who've worked on doing this support in other clients on the lessons they've learned
16:19:38 <jamie_h> https://github.com/jamiehannaford/json-schema - but this might not be anything like what we could end up using
16:19:40 <mfer> i had something in mind that would work within json schema while taking their feedback into account. i'm curious to see what you've got brewing and why
16:19:54 <mfer> jamie_h i'll go poke around at that this afternoon
16:20:40 <jamie_h> mfer okay. It's effectively a validator and parser for consuming schemas - but as I've said, it might not look anything like what we end up using. Just a strawman
16:20:57 <mfer> ok
16:21:30 <mfer> while i look forward to chatting with you about it we have 9 minutes left. you mind if we take that off meeting?
16:21:36 <jamie_h> sure
16:21:39 <mfer> thanks
16:22:10 <mfer> once those areas are done we can move into extensions and service discovery while mroe services are being added and documented
16:22:25 <mfer> there is an upcoming bottleneck of work and they we can do more in parallel
16:23:23 <mfer> is there any questions on the roadmap?
16:23:47 <jamie_h> I don't have any
16:24:04 <samchoi> roadmap is clear, but I'd like further clarification later on what we plan to do now (the "bottlenecks") before getting to a point where we're able to add new services in parallel
16:24:16 <samchoi> but we can chat later
16:24:20 <mfer> ok
16:24:28 <mfer> #topic Bugs / Reviews
16:24:41 <mfer> #link bugs.launchpad.net/openstack-sdk-php
16:24:54 <mfer> there are two closely related bugs and nothing currently in review
16:25:13 <mfer> the two bugs are on Sams plate to done once the PSR-2 work is complete.
16:25:49 <mfer> if there is no discussion on this we can move to open discussion.
16:26:16 <samchoi> ok
16:26:25 <ycombinator> sure
16:26:28 <mfer> the bug has to do with a default for a region name. we can't assume a default for broader openstack
16:26:28 <glenc> k
16:26:40 <mfer> #topic open discussion
16:26:50 <mfer> we've got about 4 minutes until the next meeting IIRC
16:27:58 <jamie_h> I have nothing else to add, I think we covered the most important things during the codebase discussion
16:28:52 <ycombinator> yeah, I'm good too
16:29:39 <glenc> FYI I'm out next week
16:29:49 <glenc> I'm sure you can carry on without me LOL
16:30:18 <tjones> you guys done?  i've got to start up the next meeting.  sorry to kick you out
16:30:42 <samchoi> think we're good
16:30:55 <glenc> Not sure what happened to mfer
16:30:57 <glenc> #endmeeting