15:31:04 #startmeeting openstack-sdk-php 15:31:05 Meeting started Wed Apr 30 15:31:04 2014 UTC and is due to finish in 60 minutes. The chair is mfer. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:31:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:31:08 The meeting name has been set to 'openstack_sdk_php' 15:31:23 Can everyone please state your name and any applicable association. 15:31:26 Matt Farina, HP 15:31:29 Sam Choi, HP 15:31:33 Jamie Hannaford, Rackspace 15:31:43 Shaunak and Glen are at a meeting, so won't be attending today 15:32:25 #topic Agenda 15:32:33 #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP 15:32:59 1. Intro to the PHP SDK if there is anyone new? (mfer) 15:32:59 2. Near term roadmap (mfer) 15:32:59 3. Service definitions (jamie_h) 15:32:59 4. Blueprints / Bugs / Reviews (mfer) 15:32:59 5. Copyrights? (jamie_h) 15:32:59 6. Open Discussion (mfer) 15:33:13 Since there is no one new here we can jump to #2 15:33:23 #topic Near term roadmap 15:33:35 #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Short_Term_Roadmap 15:33:56 I left this on here because we've had a bit of discussion on it. is there anything else we should talk about? 15:34:10 Today I've been working on 2 (Guzzle transport layer) 15:34:22 Shaunak will be commencing progress on Friday with his doc stuff 15:34:38 He put together this spec: https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/UserFacingDocumentation 15:35:03 Other than that, I have nothing else 15:35:30 jamie_h #2 was marked as complete so that's something we might want to talk about. 15:35:46 I'm glad to see Shaunak working on that stuff. I'll poke around at what he put together 15:35:55 It's adding no new functionality - just refactoring existing stuff and adding missing tests 15:36:01 adding FIG messages etc. 15:36:24 jamie_h: is there a bug/blueprint with additional details? 15:37:10 jamie_h FIG message for a response was already included. 15:37:33 jamie_h i think the question is why and how does it fit in the scope of what 15:37:40 only a ResponseInterface was there - there was no MessageInterface or RequestInterface 15:38:18 only the featuers that need to be present are the ones that will be used. the use case and how it fits into scope is the larger question 15:38:26 it's work on the transport layer that enables us to move on with the more complex service stuff 15:38:40 right now there are inefficiencies which need to be cleaned up 15:38:54 When we agreed to take on the codebase, we agreed to the idea of refactoring 15:39:07 I'm not going to steam on with adding stuff to a wobbly foundation 15:39:43 this isn't about refactoring. anything that goes in should have a purpose in the broader scope. can you please add a blueprint describing what, why, and how it fits in. 15:40:21 Of course - I'll sketch one today 15:40:57 we're building a binding in an SDK and not an application. This is meant for end users to have a simple and useful way to map to services. i just want to make sure we don't go down a road of feature creep or into something larger and more unwieldy than needed. 15:41:36 I agree. But we also have an obligation to provide users with code that is well-written and not riddled with technical debt 15:43:29 jamie_h i'd prefer if you didn't call this a wobbly foundation or otherwise poke it with a negative tone. there are some things you have looked down upon which were intentional decsions based on good engineering principles with end users in mind. I do agree that debt should be removed. 15:44:00 if you have a question about why something is please ask and try to understand why something is a certain way 15:44:17 i look forward to the blueprint 15:44:31 is there anything else on the roadmap? 15:44:39 just to clarify: 15:44:46 For work done on the transport layer/Guzzle, I think we should also keep in mind that how we make use of Guzzle can make it more difficult for contributors to understand the codebas since Guzzle itself takes some time to get used to. 15:44:49 does every patch in OpenStack require a blueprint first? 15:45:04 jamie_h no 15:45:31 jamie_h not every patch requires a blueprint or bug. but, any new featuers or bugs should have something associated 15:45:39 so, something like removing the credits file is just fine 15:46:20 how about refactoring which doesn't introduce new features? 15:46:26 mfer: so there aren't many cases where a patch wouldn't have an associated bp/bug then? 15:46:31 does that require an official blueprint? 15:47:38 samchoi: I agree - we need to minimize the complexity underneath, and separate it out so it's not intimidating or cryptic for new users - that was what I was working on today 15:47:50 things like renaming "GuzzleClient" class to "GuzzleAdapter" 15:48:06 jamie_h possibly not. but, the refactor should be discussed and intents be clear. many of the decisions were made for good technical reasons. to switch to a different architecture the technical changes and reasoning needs to be clear and understood 15:48:34 I completely agree - I'm not trying to move to a different architecture, just strengthen and simplify the one we have :) 15:49:24 jamie_h those are fine. strengthen just needs to be clearly communicated 15:49:52 Okay. I just think we need to be open to the idea of changing parts of the codebase. Asking for formal blueprints and debating every minutiae of detail raises barriers IMHO 15:50:04 and not on a personal pref merit. i've seen some of that on some projects recently and i'd like to avoid those things. 15:50:50 doing things in openstack has extra barriers. that's part of the system of folks from very different walks of life working together and the large companies being incolved. 15:51:06 lets try to minimize those and work efficiently in them 15:51:23 I agree - what's the best way to communicate prospective refactorings? 15:51:38 surely that's what Gerrit is for? 15:52:02 commit messages. when questions come up clearly articulate reasoning. things like that 15:52:25 provide logic and reasoned cases 15:52:55 Okay - what's the best way to do that? Gerrit doesn't have a great commenting system - shall we use the Wiki? 15:53:27 I'm wary about having to write a wiki article for every patch I write. It'll take days to merge simple refactorings then 15:53:44 The latest release of Gerrit has the ability to just do comments in addition to reviews. comments inline are a great way. someone can ask a question about a section of code in context and a discussion can happen there 15:54:03 is there a reason this won't work? 15:54:20 Let's go with that for now 15:54:24 I'm happy to move on 15:54:44 anything else with the roadmap or shall we talk service definitions? 15:55:12 I have nothing to add for roadmap 15:55:17 I'm good 15:55:21 #topic Service definitions 15:55:36 jamie_h since this is your item can you kick us off 15:55:53 I sent out several e-mails and wrote up some Wiki articles detailing my idea 15:55:58 did everyone get a chance to read it? 15:56:08 jamie_h i did 15:56:20 it was fairly long, so no worries if not :) 15:56:48 so it's just an idea - I'm not firmly advocating it. I think it could offer us and our users a lot of advantages 15:57:08 I was out earlier this week, I haven't gotten through all emails unfortunately 15:57:50 mfer do you have any questions? If not, shall we postpone this topic until next week so Sam has a chance to read everything? 15:58:32 jamie_h I understand the case you're making. I took this a few steps further. I looked at other places that are using this. did you know Google is taking json schema and generating Go code from it? i also dug into the debugging experience even if something like Guzzle isn't used. 15:58:54 so, i'm up to speed 15:58:56 really? I didn't know they were generating go code - that's awesome 15:59:04 I love their Discovery API 15:59:45 mfer do you have any concerns about using a definitions DSL like the one I described? Or any reason why userland code would be better? 16:00:43 i can come up with other ways to do the same thing w/o json schemas. 16:00:59 better here is going to be a little subjectice on the developer experience side 16:02:07 by "other ways" do you mean userland code? Or a DSL? 16:02:09 my largest curiosity is that I discussed this with some folks in and out of HP who work on SDKs. the majority reaction I got was to use userland code. i was a little surprised 16:02:20 i'd like to explore their thinking more. 16:02:45 okay, sure. Let's try and compile a list of strong reasons for/against so we can evaluate further 16:02:53 personally, i don't have a preference one way or another. i'm fine either way. i'd like like to understand this first and why some folks had push back the way they did 16:03:23 I agree. The openstack-dev mailing list is a great way to find this out too 16:03:32 some of these folks will be at the summit. i'd like to spend some time face to face with them and talk it through. 16:03:42 I did a search for json-schema and the reaction was nearly always positive 16:03:48 okay - sounds like a plan 16:03:51 i'm saving the emails and wiki pages you had to use in the conversations. to share examples and talk it through 16:04:20 i have a feeling that those who didn't take on json schema didn't say anything at all 16:04:31 and, i wonder if there is some stuff that's misunderstood 16:05:17 do you want to postpone this schema stuff until after the summit? 16:05:32 jamie_h i think you did a good job of articulating your point. i was also able to easily find any missing information i wanted when i researched 16:05:53 yeah, i was thinking we postpone that until after the summit. i'll collect a bunch of feedback and share 16:06:17 btw, OS summit is next week and mfer is out all week right? 16:06:35 the OS summit is the week after next 16:06:38 so, can we halt work on all service stuff until after the summit - since schemas are linked to that 16:07:02 I don't want to get started on something, realize we've committed to a solution, and that forms the basis for not including schemas 16:07:06 if something becomes clear during the summit i'll be sure to start emails then 16:07:23 thanks. 16:07:45 so until the summit finished, how will this affect the roadmap? 16:07:50 i was really interested in the schema work. then i spoke with some others and they had reservations. i'd like to just make sure everything is vetted 16:07:59 okay that's fair 16:08:29 i'm not sure how it affects the roadmap 16:09:01 there are some other things we can work on in the meantime 16:09:11 sure okay 16:09:17 I'm happy to move on to next topic 16:09:43 samchoi are you ready to move on? 16:10:01 sure, I'll gather more information on my own and from emails 16:10:10 no further comments at this time 16:10:20 #topic Blueprints / Bugs / Reviews 16:10:57 Lets start with the credits file one 16:10:59 #link https://review.openstack.org/#/c/91305/ 16:11:19 I don't see an issue with this one. It seems fairly straight forward. 16:12:15 samchoi did you have reservations for this one? 16:12:31 no, looks fine 16:13:07 then i just merged it now :) 16:13:23 err, reviewed it for Jenkins to do it's thing 16:13:26 cool! 16:13:42 then there is the test separation one 16:13:45 #link https://review.openstack.org/#/c/90407/ 16:14:03 can we talk about https://review.openstack.org/#/c/90378/7 first? 16:14:08 since it's a dependency 16:14:15 ok 16:14:43 thanks mfer for your feedback on this one. I ended up adding back in a lot of the original tests 16:14:55 there's only minor refactoring, removing duplication etc. 16:14:57 i've not had a chance to look through the latest patch set 16:15:22 i'd like to get to that later today 16:15:28 okay 16:16:18 each day i'm carving out some time to do some reviews and that time hasn't come up since the last time you pushed a change 16:16:53 i'll review this one before i get to the test structure changes one 16:16:58 thanks 16:18:27 jamie_h with this change would it be safe to run against devstack too? 16:18:37 mfer yep, that's what I was running against 16:18:45 great. i'll do that. thanks 16:19:43 I was going to start the process to convert bootstrap away from a singleton (https://blueprints.launchpad.net/openstack-sdk-php/+spec/remove-openstack-singleton) 16:19:43 samchoi do you need today to review this one too? I know you approved of the other one (separating out tests) 16:20:06 mfer okay, sounds good 16:21:06 to review 90378? I'll look through the latest patch today. I haven't looked at others' comments, but I didn't see any blockers or serious issues. 16:21:19 mfer can we talk about whether to have a global context (like Bootstrap) or individual service builders - perhaps in IRC later? 16:21:35 I haven't had much time to get to grips with bootstrap yet 16:21:36 jamie_h sure. 16:22:08 the idea is the developer experience of developers integrating this into their setup. to make it easy for the long tail of developers 16:22:23 yeah, like a single access point 16:22:40 we're not targeting the top 10% of devs. they likely wouldn't need an SDK. i want to make sure we help the long tail be successful 16:22:49 i'll start with a spec 16:23:38 I like the idea of making it as easy as possible to create a service 16:24:18 are there any other patches that need discussion? 16:24:19 yeah, i do too. it's two slightly different audiences. someone who is going to add to/extend the binding and someone who is going to use it. 16:24:31 those are the only 3 open reviews right now 16:24:40 samchoi did you have anything that needed discussing? 16:24:51 nope 16:25:15 shall we move on to copyrights? 16:25:24 sure 16:25:33 #topic Copyrights? 16:26:02 jamie_h this is another one you added. can you fill in the context 16:26:11 i think i know what you mean but i don't want to assume 16:26:44 So I submitted a patch a week or so ago that rewrote all the copyright headers to use OpenStack Foundation as the copyright holder. Currently the files reference HP 16:27:03 more time was required for investigation to see the legal ramifications of changing to OpenStack Foundation 16:27:35 Unfortunately, I've not had the time for that yet. 16:27:38 #link https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers 16:28:00 that's fine - shall we add this to next week's agenda? 16:28:30 basically, an overwhelming reason to keep HP as the copyright holder on this project 16:28:43 instead of switching everything to OpenStack Foundation 16:28:45 I was going to save this for the open discussions but i will likely not be here next week. i'm on vacation. 16:28:56 can we punt it to the week after the summit? 16:29:10 there's actually a "duplicative licensing situation" going on here 16:29:33 mfer: Is this something we can send off to HP legal to research for us? 16:29:34 and I'm not sure of the legal stance within HP and within the community. i need to make checks on both sides 16:29:42 sure, let's talk about it after the simmit 16:29:57 samchoi I need to check with HPs lawyers 16:30:11 note, it's not uncommon for companies to be in the headers like this. 16:30:20 you'll see it in lots of projects 16:30:35 i'm just always very caucious around these legalities 16:31:29 we should wrap up... I think we'll be kicked out shortly 16:31:49 ok, there is another meeting starting. see y'all in #openstack-sdks 16:31:56 #endmeeting