15:31:04 <mfer> #startmeeting openstack-sdk-php
15:31:05 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:31:08 <openstack> The meeting name has been set to 'openstack_sdk_php'
15:31:23 <mfer> Can everyone please state your name and any applicable association.
15:31:26 <mfer> Matt Farina, HP
15:31:29 <samchoi> Sam Choi, HP
15:31:33 <jamie_h> Jamie Hannaford, Rackspace
15:31:43 <jamie_h> Shaunak and Glen are at a meeting, so won't be attending today
15:32:25 <mfer> #topic Agenda
15:32:33 <mfer> #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP
15:32:59 <mfer> 1. Intro to the PHP SDK if there is anyone new? (mfer)
15:32:59 <mfer> 2. Near term roadmap (mfer)
15:32:59 <mfer> 3. Service definitions (jamie_h)
15:32:59 <mfer> 4. Blueprints / Bugs / Reviews (mfer)
15:32:59 <mfer> 5. Copyrights? (jamie_h)
15:32:59 <mfer> 6. Open Discussion (mfer)
15:33:13 <mfer> Since there is no one new here we can jump to #2
15:33:23 <mfer> #topic Near term roadmap
15:33:35 <mfer> #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Short_Term_Roadmap
15:33:56 <mfer> 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 <jamie_h> Today I've been working on 2 (Guzzle transport layer)
15:34:22 <jamie_h> Shaunak will be commencing progress on Friday with his doc stuff
15:34:38 <jamie_h> He put together this spec: https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/UserFacingDocumentation
15:35:03 <jamie_h> Other than that, I have nothing else
15:35:30 <mfer> jamie_h #2 was marked as complete so that's something we might want to talk about.
15:35:46 <mfer> I'm glad to see Shaunak working on that stuff. I'll poke around at what he put together
15:35:55 <jamie_h> It's adding no new functionality - just refactoring existing stuff and adding missing tests
15:36:01 <jamie_h> adding FIG messages etc.
15:36:24 <samchoi> jamie_h: is there a bug/blueprint with additional details?
15:37:10 <mfer> jamie_h FIG message for a response was already included.
15:37:33 <mfer> jamie_h i think the question is why and how does it fit in the scope of what
15:37:40 <jamie_h> only a ResponseInterface was there - there was no MessageInterface or RequestInterface
15:38:18 <mfer> 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 <jamie_h> it's work on the transport layer that enables us to move on with the more complex service stuff
15:38:40 <jamie_h> right now there are inefficiencies which need to be cleaned up
15:38:54 <jamie_h> When we agreed to take on the codebase, we agreed to the idea of refactoring
15:39:07 <jamie_h> I'm not going to steam on with adding stuff to a wobbly foundation
15:39:43 <mfer> 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 <jamie_h> Of course - I'll sketch one today
15:40:57 <mfer> 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 <jamie_h> 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 <mfer> 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 <mfer> if you have a question about why something is please ask and try to understand why something is a certain way
15:44:17 <mfer> i look forward to the blueprint
15:44:31 <mfer> is there anything else on the roadmap?
15:44:39 <jamie_h> just to clarify:
15:44:46 <samchoi> 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 <jamie_h> does every patch in OpenStack require a blueprint first?
15:45:04 <mfer> jamie_h no
15:45:31 <mfer> jamie_h not every patch requires a blueprint or bug. but, any new featuers or bugs should have something associated
15:45:39 <mfer> so, something like removing the credits file is just fine
15:46:20 <jamie_h> how about refactoring which doesn't introduce new features?
15:46:26 <samchoi> mfer: so there aren't many cases where a patch wouldn't have an associated bp/bug then?
15:46:31 <jamie_h> does that require an official blueprint?
15:47:38 <jamie_h> 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 <jamie_h> things like renaming "GuzzleClient" class to "GuzzleAdapter"
15:48:06 <mfer> 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 <jamie_h> I completely agree - I'm not trying to move to a different architecture, just strengthen and simplify the one we have :)
15:49:24 <mfer> jamie_h those are fine. strengthen just needs to be clearly communicated
15:49:52 <jamie_h> 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 <mfer> 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 <mfer> 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 <mfer> lets try to minimize those and work efficiently in them
15:51:23 <jamie_h> I agree - what's the best way to communicate prospective refactorings?
15:51:38 <jamie_h> surely that's what Gerrit is for?
15:52:02 <mfer> commit messages. when questions come up clearly articulate reasoning. things like that
15:52:25 <mfer> provide logic and reasoned cases
15:52:55 <jamie_h> 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 <jamie_h> 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 <mfer> 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 <mfer> is there a reason this won't work?
15:54:20 <jamie_h> Let's go with that for now
15:54:24 <jamie_h> I'm happy to move on
15:54:44 <mfer> anything else with the roadmap or shall we talk service definitions?
15:55:12 <jamie_h> I have nothing to add for roadmap
15:55:17 <samchoi> I'm good
15:55:21 <mfer> #topic Service definitions
15:55:36 <mfer> jamie_h since this is your item can you kick us off
15:55:53 <jamie_h> I sent out several e-mails and wrote up some Wiki articles detailing my idea
15:55:58 <jamie_h> did everyone get a chance to read it?
15:56:08 <mfer> jamie_h i did
15:56:20 <jamie_h> it was fairly long, so no worries if not :)
15:56:48 <jamie_h> 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 <samchoi> I was out earlier this week, I haven't gotten through all emails unfortunately
15:57:50 <jamie_h> 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 <mfer> 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 <mfer> so, i'm up to speed
15:58:56 <jamie_h> really? I didn't know they were generating go code - that's awesome
15:59:04 <jamie_h> I love their Discovery API
15:59:45 <jamie_h> 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 <mfer> i can come up with other ways to do the same thing w/o json schemas.
16:00:59 <mfer> better here is going to be a little subjectice on the developer experience side
16:02:07 <jamie_h> by "other ways" do you mean userland code? Or a DSL?
16:02:09 <mfer> 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 <mfer> i'd like to explore their thinking more.
16:02:45 <jamie_h> okay, sure. Let's try and compile a list of strong reasons for/against so we can evaluate further
16:02:53 <mfer> 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 <jamie_h> I agree. The openstack-dev mailing list is a great way to find this out too
16:03:32 <mfer> 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 <jamie_h> I did a search for json-schema and the reaction was nearly always positive
16:03:48 <jamie_h> okay - sounds like a plan
16:03:51 <mfer> 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 <mfer> i have a feeling that those who didn't take on json schema didn't say anything at all
16:04:31 <mfer> and, i wonder if there is some stuff that's misunderstood
16:05:17 <jamie_h> do you want to postpone this schema stuff until after the summit?
16:05:32 <mfer> 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 <mfer> yeah, i was thinking we postpone that until after the summit. i'll collect a bunch of feedback and share
16:06:17 <samchoi> btw, OS summit is next week and mfer is out all week right?
16:06:35 <mfer> the OS summit is the week after next
16:06:38 <jamie_h> so, can we halt work on all service stuff until after the summit - since schemas are linked to that
16:07:02 <jamie_h> 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 <mfer> if something becomes clear during the summit i'll be sure to start emails then
16:07:23 <mfer> thanks.
16:07:45 <jamie_h> so until the summit finished, how will this affect the roadmap?
16:07:50 <mfer> 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 <jamie_h> okay that's fair
16:08:29 <mfer> i'm not sure how it affects the roadmap
16:09:01 <mfer> there are some other things we can work on in the meantime
16:09:11 <jamie_h> sure okay
16:09:17 <jamie_h> I'm happy to move on to next topic
16:09:43 <mfer> samchoi are you ready to move on?
16:10:01 <samchoi> sure, I'll gather more information on my own and from emails
16:10:10 <samchoi> no further comments at this time
16:10:20 <mfer> #topic Blueprints / Bugs / Reviews
16:10:57 <mfer> Lets start with the credits file one
16:10:59 <mfer> #link https://review.openstack.org/#/c/91305/
16:11:19 <mfer> I don't see an issue with this one. It seems fairly straight forward.
16:12:15 <jamie_h> samchoi did you have reservations for this one?
16:12:31 <samchoi> no, looks fine
16:13:07 <mfer> then i just merged it now :)
16:13:23 <mfer> err, reviewed it for Jenkins to do it's thing
16:13:26 <jamie_h> cool!
16:13:42 <mfer> then there is the test separation one
16:13:45 <mfer> #link https://review.openstack.org/#/c/90407/
16:14:03 <jamie_h> can we talk about https://review.openstack.org/#/c/90378/7 first?
16:14:08 <jamie_h> since it's a dependency
16:14:15 <mfer> ok
16:14:43 <jamie_h> thanks mfer for your feedback on this one. I ended up adding back in a lot of the original tests
16:14:55 <jamie_h> there's only minor refactoring, removing duplication etc.
16:14:57 <mfer> i've not had a chance to look through the latest patch set
16:15:22 <mfer> i'd like to get to that later today
16:15:28 <jamie_h> okay
16:16:18 <mfer> 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 <mfer> i'll review this one before i get to the test structure changes one
16:16:58 <jamie_h> thanks
16:18:27 <mfer> jamie_h with this change would it be safe to run against devstack too?
16:18:37 <jamie_h> mfer yep, that's what I was running against
16:18:45 <mfer> great. i'll do that. thanks
16:19:43 <mfer> 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 <jamie_h> samchoi do you need today to review this one too? I know you approved of the other one (separating out tests)
16:20:06 <jamie_h> mfer okay, sounds good
16:21:06 <samchoi> 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 <jamie_h> mfer can we talk about whether to have a global context (like Bootstrap) or individual service builders - perhaps in IRC later?
16:21:35 <jamie_h> I haven't had much time to get to grips with bootstrap yet
16:21:36 <mfer> jamie_h sure.
16:22:08 <mfer> 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 <jamie_h> yeah, like a single access point
16:22:40 <mfer> 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 <mfer> i'll start with a spec
16:23:38 <jamie_h> I like the idea of making it as easy as possible to create a service
16:24:18 <jamie_h> are there any other patches that need discussion?
16:24:19 <mfer> 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 <mfer> those are the only 3 open reviews right now
16:24:40 <mfer> samchoi did you have anything that needed discussing?
16:24:51 <samchoi> nope
16:25:15 <mfer> shall we move on to copyrights?
16:25:24 <jamie_h> sure
16:25:33 <mfer> #topic Copyrights?
16:26:02 <mfer> jamie_h this is another one you added. can you fill in the context
16:26:11 <mfer> i think i know what you mean but i don't want to assume
16:26:44 <jamie_h> 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 <jamie_h> more time was required for investigation to see the legal ramifications of changing to OpenStack Foundation
16:27:35 <mfer> Unfortunately, I've not had the time for that yet.
16:27:38 <mfer> #link https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers
16:28:00 <jamie_h> that's fine - shall we add this to next week's agenda?
16:28:30 <jamie_h> basically, an overwhelming reason to keep HP as the copyright holder on this project
16:28:43 <jamie_h> instead of switching everything to OpenStack Foundation
16:28:45 <mfer> 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 <mfer> can we punt it to the week after the summit?
16:29:10 <mfer> there's actually a "duplicative licensing situation" going on here
16:29:33 <samchoi> mfer: Is this something we can send off to HP legal to research for us?
16:29:34 <mfer> 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 <jamie_h> sure, let's talk about it after the simmit
16:29:57 <mfer> samchoi I need to check with HPs lawyers
16:30:11 <mfer> note, it's not uncommon for companies to be in the headers like this.
16:30:20 <mfer> you'll see it in lots of projects
16:30:35 <mfer> i'm just always very caucious around these legalities
16:31:29 <samchoi> we should wrap up... I think we'll be kicked out shortly
16:31:49 <mfer> ok, there is another meeting starting. see y'all in #openstack-sdks
16:31:56 <mfer> #endmeeting