15:30:05 #startmeeting openstack-sdk-php 15:30:06 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:30:09 The meeting name has been set to 'openstack_sdk_php' 15:30:23 Hello everyone. If you couple please state your name along with any association 15:30:26 Matt Farina, HP 15:30:29 Sam Choi, HP 15:30:32 Jamie Hannaford, Rackspace 15:30:35 Shaunak Kashyap, Rackspace 15:31:02 Glen Campbell, Rackspace 15:32:41 #topic Agenda 15:32:46 #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP 15:33:05 I updated the agenda on the Wiki. It's simliar to the last one. 15:33:38 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 So, let's move tot he second item 15:34:21 #topic State of the codebase 15:35:06 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 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 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 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 I want the PHP SDK to be something that helps OpenStack and those that use it. 15:37:29 All that being said... 15:37:53 http://www.dramabutton.com 15:38:07 *drumroll* 15:38:19 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 samchoi What do you think, Sam? 15:39:13 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 questions or other discussion on this point? 15:40:46 i'm happy to add context as needed. 15:42:11 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 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 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 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 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 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 understood 15:46:22 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 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 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 mfer sure, but none of the code was submitted through Gerrit. What you did before that is moot 15:47:59 all code that's come in since that import has gone through gerrit. this is typical. 15:48:05 mfer but we're not talking about generic projects, we're integrating into a very established larger project with rules 15:48:18 you can look at other example projects like barbacon, from Rackspace, and can see this in practice 15:48:29 mfer new code has, but the vast majority of existing code has not been reviewed 15:48:49 I've yet to hear a good reason to break OpenStack rules/protocol 15:49:00 apart from "it'll be faster" 15:49:16 from doing my due diligence here, the way this is handled is within the rules/protocols. 15:49:43 this is how other projects have gone in. Even project started by those at Rackspace 15:49:56 the python SDK doesn't 15:49:58 this is not stepping outside the process or what happens in practice 15:50:12 it is, because we're inheriting a codebase that's not gone through any review process 15:50:19 the python SDK is an outlier from the norm. 15:51:11 I disagree. It's taking a very sensible and democratic approach 15:51:12 So, for the first point... we're holding to the process and what has typically happened. 15:51:36 No, we're really not. Allowing unreviewed code is a clear breach of standard protocol 15:51:41 IMHO 15:52:31 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 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 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 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 what i've learned is that this approach is appropriate 15:58:34 mfer who exactly did you consult in the community? Have they had much exposure to OpenStack workflow? 15:58:55 My point is that a typical PHP project, for example, might have a different workflow than OpenStack 15:59:17 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 jamie_h: can you elaborate on that? 15:59:50 jamie_h and others who have experience in the community outside that 16:01:33 jamie_h: you're referring to PHP projects outside of OpenStack, correct? 16:02:51 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 I don't think we've reached consensus yet 16:03:52 jamie_h at what point will we reach concensus? 16:04:12 I don't agree with any of the counter-points made here, but I agree that we need to move forward 16:04:13 we have 27 minutes left in this meeting, there are two other areas, and the question from glenc 16:04:37 what jamie_h said 16:04:38 This is my opinion: 16:04:52 I think we need to move on 16:04:54 let's try to address the other topics quickly and come back to this? 16:04:59 Okay 16:05:19 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 jamie_h: that was my thought actually...I felt it to be a good compromise 16:05:48 yeah, I'm not seeing another way forward 16:06:04 jamie_h that's what we've been doing. the roadmap assumes that. 16:06:11 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 you'll notice it has guzzle4 support already 16:06:25 Sure, but I didn't know whether people might cling to certain existing concepts or areas of code 16:06:47 By being in the codebase they'll already have quasi-approval 16:06:48 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 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 Okay, I'm satisfied here. Shaunak and Glen, do you have anything else to add? 16:08:09 no, lets move on 16:08:12 I'm happy to address the point from Glen still if needed 16:08:27 no need to address - 16:08:50 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 yeah, I think the time we are losing in figuring out fastest path > choosing A path and moving on 16:09:29 so lets move on :) 16:10:00 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 shall we move on to the near term roadmap? 16:10:46 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 Yeah, let's move on 16:11:08 yeah, lets not rehash this; mfer: please move on to the near term roadmap 16:11:49 Not willing to argue the point; would rather move on 16:12:03 #topic Near term roadmap 16:12:13 #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Short_Term_Roadmap 16:12:35 as per my action from the last meeting, I linked the blueprints to the roadmap 16:13:03 The guzzle 4 work and phpdoc change has already been completed 16:13:25 next up, and not on here but happening, is the shift to PSR-2 that samchoi is working on 16:13:44 samchoi how are you getting on with PSR-2? 16:13:55 good, I'm reviewing diff logs from an automated tool 16:14:04 https://github.com/fabpot/PHP-CS-Fixer 16:14:15 I'm primarily checking to see if certain coding conventions are NOT addressed by the tool 16:14:25 but all good thus far 16:15:20 if you use PhpStorm, you can do it with that too. It has a neat reformatting tool 16:15:31 you can do it across a project directory 16:17:31 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 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 ok 16:19:06 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 https://github.com/jamiehannaford/json-schema - but this might not be anything like what we could end up using 16:19:40 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 jamie_h i'll go poke around at that this afternoon 16:20:40 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 ok 16:21:30 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 sure 16:21:39 thanks 16:22:10 once those areas are done we can move into extensions and service discovery while mroe services are being added and documented 16:22:25 there is an upcoming bottleneck of work and they we can do more in parallel 16:23:23 is there any questions on the roadmap? 16:23:47 I don't have any 16:24:04 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 but we can chat later 16:24:20 ok 16:24:28 #topic Bugs / Reviews 16:24:41 #link bugs.launchpad.net/openstack-sdk-php 16:24:54 there are two closely related bugs and nothing currently in review 16:25:13 the two bugs are on Sams plate to done once the PSR-2 work is complete. 16:25:49 if there is no discussion on this we can move to open discussion. 16:26:16 ok 16:26:25 sure 16:26:28 the bug has to do with a default for a region name. we can't assume a default for broader openstack 16:26:28 k 16:26:40 #topic open discussion 16:26:50 we've got about 4 minutes until the next meeting IIRC 16:27:58 I have nothing else to add, I think we covered the most important things during the codebase discussion 16:28:52 yeah, I'm good too 16:29:39 FYI I'm out next week 16:29:49 I'm sure you can carry on without me LOL 16:30:18 you guys done? i've got to start up the next meeting. sorry to kick you out 16:30:42 think we're good 16:30:55 Not sure what happened to mfer 16:30:57 #endmeeting