15:30:22 <mfer> #startmeeting openstack-sdk-php
15:30:23 <openstack> Meeting started Wed May 21 15:30:22 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:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:26 <openstack> The meeting name has been set to 'openstack_sdk_php'
15:30:36 <mfer> Welcome everyone.
15:30:45 <glenc-> o/
15:30:51 <mfer> Please state your name and any applicable association
15:30:54 <mfer> Matt Farina, HP
15:31:03 <samchoi> Sam Choi, HP
15:31:06 <glenc-> Glen Campbell, Rackspace
15:31:23 <jamie_h> Jamie Hannaford, Rackspace
15:32:06 <mfer> #topic Agenda
15:32:11 <mfer> #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP
15:32:29 <mfer> There are 7 items on the agenda but given the audience we can do just the last 6.
15:32:35 <mfer> Is there anything that should be added?
15:32:57 <mfer> 1. Intro to the PHP SDK if there is anyone new? (mfer)
15:32:57 <mfer> 2. FQCNs in DocBlocks (mfer)
15:32:57 <mfer> 3. json schema (mfer)
15:32:57 <mfer> 4. transport layer (mfer)
15:32:57 <mfer> 5. testing (mfer)
15:32:57 <mfer> 6. Reviews in progress - any questions/concerns? We are quickly accumulating reviews that touch overlapping files. It would be in our best interest to move forward with reviews soon. (samchoi)
15:32:58 <mfer> 7. What are the essential blueprints/bugs that need to be finished before we can move on to working on additional services? (samchoi)
15:33:04 <jamie_h> I have nothing to add
15:33:40 <mfer> #topic FQCNs in DocBlocks
15:34:12 <mfer> In a recent review samchoi noticed that some cases have shortened references to classes to just the imported name rather than that full name
15:34:29 <mfer> As I understand it, some IDEs don't handle this well
15:34:40 <mfer> samchoi did you have anything else you wanted to add?
15:35:22 <samchoi> I can confirm several versions of Zend Studio (Eclipse) have the issue with auto complete. NetBeans appears to have the issue as well.
15:35:32 <samchoi> That's about it
15:35:45 <mfer> samchoi when the full path is provided it works?
15:35:51 <samchoi> yes
15:36:13 <mfer> jamie_h what do you think about using the full path for classes in @params, @returns, and @throws?
15:36:55 <jamie_h> the only advantage of short forms is that it's briefer and saves space
15:37:08 <jamie_h> playing devil's advocate: should IDE support inform technical/internal decisions?
15:37:37 <jamie_h> I don't really mind either way as long as we're consistent
15:37:41 <glenc> +1
15:38:16 <mfer> I think that's a good question. here was my initial take but i'm open to someone telling me something different. the goal of the SDK is developer experience. we want to have a good one. A lot of PHP devs use these IDEs so we should give them a good experience.
15:38:38 <mfer> that would lead to the longer form
15:39:13 <mfer> jamie_h glenc samchoi thoughts? other ways to look at it?
15:39:15 <jamie_h> there's also nothing really stopping us using short forms, say in a year or two, if IDEs start supporting them
15:39:27 <jamie_h> so for now I'm happy using FQCNs
15:39:51 <mfer> we can always change in the future. even without a major point release because the API wouldn't be changing
15:40:04 <glenc> I probably wouldn't spend a huge amount of time retrofitting existing stuff, but simply set a standard and change them as we encounter them.
15:40:17 <glenc> Make it a standard to use the FQCN
15:40:46 <samchoi> For the reasons jamie_h mentioned in response to my reviews, I also like local/short names as well if all things were equal. I think using FQCN and considering future changes would be a good approach
15:41:19 <mfer> ok, then i think this is settled. we can move on to the next topic. sorry if i push this a little quickly. there are a bunch of topics
15:41:27 <mfer> #topic json schema
15:41:45 <mfer> jamie_h glenc have the two of you had a chance to talk with jesse noller about this?
15:42:10 <glenc> Yes, we've had some extensive email threads
15:42:28 <jamie_h> jesse e-mailed us about a decision being made at the summit about not using JSON schemas for the time being - but to some how bake in support for the future
15:42:33 <glenc> I understand that it's not recommended for the time being
15:42:59 <glenc> but IMHO they don't really understand our use case within the SDK; doesn't make sense to develop something else and then replace it in six months to a year.
15:43:24 <mfer> Jesse and I each went out to assess the situation at the summit. we came together to talk about it. let me share what I learned and we can discuss.
15:44:22 <mfer> json schema was a fairly big and common topic at the summit. a number of projects want to or are starting to use it in different ways. For example, some wand to describe their "objects" in it and use that for validation. this is a fairly different case from ours.
15:45:01 <mfer> others want to use it to describe api interactions at the REST level. this is in line with what we are looking for.
15:45:36 <mfer> I spoke with several people on different teams who told me that using json schema the way we want to is a great idea. they also said don't do it yet
15:46:07 <mfer> of all the people i spoke with the common theme was that sdks should use json schema but not yet. no one was saying do it now.
15:46:11 <mfer> at least to me
15:46:36 <mfer> it opens up questions of who manages the schemas, where do they live, how are they shared and kept up to date.
15:46:54 <mfer> there is my context. i want to know what the rest of you think
15:47:25 <jamie_h> was there a reason for not using it right now? the ownership/location issue you just brought up isn't a temporary one, it will always be the case
15:47:25 <mfer> note, i'm sharing what i heard not my opinion on this topic
15:47:51 <mfer> jamie_h until service create schemas for their services and manage them themselves. then we would be a consumer of that
15:48:10 <jamie_h> another reason i can see for not using JSON schemas right now is because the actual spec is still a bit rough around the edges
15:48:50 <mfer> there were a number of sessions on cleaning up the api. there was quite a bit of agreement that it "needs work"
15:49:10 <jamie_h> if an API provides us with schemas (in the future), that won't give us the DSL we were talking about
15:49:23 <jamie_h> i.e. defining REST operations
15:49:37 <glenc> The use case for the SDK is that we need a way to describe a service so that the underlying code can be simplified and be metadata-driven. If we DON'T use json schema, then we need some other way to describe those services, and I don't know what that could be.
15:50:09 <jamie_h> all JSON schema is useful for is modelling data structures. We still need a way to describe services
15:50:17 <jamie_h> either in a DSL (metadata) or userland code
15:50:23 <glenc> WADL :(
15:50:25 <mfer> glenc there were a number of conversations on the side about metadata driven SDKs. I was surprised how many SDK devs there were opposed to it. I'm not opposed to it, personally.
15:50:49 <jamie_h> I don't mind not using schemas - but we need to think about how we'll describe services
15:50:51 <mfer> even if we do it on PHP there will be opposition on other SDKs which brings up a consistency problem
15:51:17 <glenc> I'm nervous about it but I can see the benefits, if implemented properly. FWIW, I did a ton of metadata-driven libraries back in my past, and sometimes the metadata DSL became more complicated than the underlying programming language.
15:51:59 <jamie_h> when I was searching on the mailing list, most people seem enthused about a metadata-driven SDK because it was so powerful. So I'm surprised to hear the contrary
15:52:23 <mfer> it more or less changes the problem from one of coding for the API or coding to make the DSL/metadata work well.
15:52:38 <mfer> jamie_h i was surprised too!
15:52:48 <glenc> Yes, and coding a DSL interpreter that is sufficiently rich to support everything in all the services
15:53:17 <jamie_h> but the tradeoffs are clear: userland code is slower to write, has duplication, bloats the codebase and requires hundreds more tests
15:54:03 <jamie_h> the debate between a DSL and userland code is separate from that of JSON schemas - I'm happy to ignore json schemas if openstack does not think it's ready
15:54:29 <mfer> well, a DSL and schema needs to be learned which is not common in many circles which takes more ramp up time. you can write userland code to cut down duplication.
15:55:07 <mfer> jamie_h how about this. we next look at what a DSL would look like without json schema. test the waters
15:55:09 <samchoi> mfer: Agreed..was just about to mention that implementing a DSL can create more of a barrier to entry for new contributors
15:55:22 <samchoi> If we don
15:55:29 <jamie_h> a DSL can also serve as living documentation, which is beneficial to end-users
15:55:46 <jamie_h> mfer that sounds good. Let's leave JSON schema behind and make this a question of how to describe services
15:56:13 <mfer> jamie_h we need to make sure it makes sense to those using an IDE or documentation system. A schema and DSL aren't self documentation to many in the long tail.
15:56:34 <mfer> jamie_h samchoi what about comparing a DSL to that of a userland code solution?
15:57:02 <jamie_h> mfer let's do some more investigation about DSL vs userland code - and then make a decision
15:57:08 <samchoi> mfer: My only thought at the moment is that topic could take us the rest of the meeting. I don't know that we've explored that enough.
15:57:23 <jamie_h> I think it's best to investigate outside of this meeting
15:57:29 <mfer> yeah
15:57:48 <mfer> jamie_h since you're interested in the DSL portion would you be willing to put something together for us to evaluate there?
15:57:54 <jamie_h> sure
15:58:17 <mfer> samchoi since you brought up the userland code option, would you be up for a solution that does that for us to look at?
15:58:27 <samchoi> alright
15:58:53 <mfer> yay! progress
15:59:09 <glenc> mfer - FYI, I have to step out to attend another meeting.
15:59:26 <glenc> see y'all next week
15:59:29 <mfer> #action jamie_h create a DSL demo to compare for an architecture path forward.
15:59:45 <mfer> #action samchoi create a userland code demo to compare for an architecture path forward.
15:59:50 <mfer> glenc see ya and thanks for coming
16:00:02 <mfer> ok, can we move on to the next topic
16:00:06 <jamie_h> I don't know whether it'll be a full demo - I'll outline tradeoffs and provide a sample implementation :)
16:00:13 <jamie_h> happy to move on to next topic
16:00:22 <samchoi> sure, ready to move on
16:00:26 <mfer> jamie_h yeah, i'm not looking for a full demo. just enough for evaluation
16:00:37 <mfer> #topic transport layer
16:01:15 <mfer> jamie_h i like what you'd started with the guzzle change. i just had one outstanding question...
16:01:24 <mfer> why the use of events to fire off exceptions?
16:01:53 <mfer> much of what you did could be implemented with a single class. i'm trying to understand the differences
16:02:08 <jamie_h> Guzzle uses events in the life cycle of its requests. This is how it handles exceptions. So if we're using Guzzle, it makes sense to take advantage of their underlying system
16:02:34 <jamie_h> plus events are extremely beneficial because it allows you to add in functionality instead of extending/overriding other library classes
16:03:03 <jamie_h> plus it allows you to have a class whose responsibilities are exception handling, instead of mixing that logic with others
16:04:48 <mfer> one of the things we should take care of doing is making the transport layer transparent to end users. you use one but in your general code it doesn't matter. an event attached to a service call is on the service and happens with all transport layers
16:04:58 <mfer> there is a clean separation
16:05:42 <mfer> #link http://docs.guzzlephp.org/en/latest/clients.html?highlight=exception#asynchronous-response-handling
16:06:05 <mfer> in that section of the guzzle docs it does say to use exceptions from events. so, this makes sense. not sure how i didn't see this before
16:06:30 <mfer> jamie_h what do you think of my thoughts on the separation?
16:06:33 <jamie_h> all that code does is attach the callback to the client
16:06:40 <mfer> yeah
16:06:52 <jamie_h> can you rephrase what you mean about separation - not sure I understood
16:07:41 <mfer> a service is one thing and a transport layer is separate. so, if we add events to services it's separate from events on the transport layer.
16:07:59 <mfer> i would like to see clear separation between the two systems
16:08:11 <mfer> even if one implents the system for the other
16:08:37 <jamie_h> me too. a transport client is injected into a service, with its own (i.e. exception) subscribers
16:08:52 <mfer> great
16:08:58 <jamie_h> the exception handling thing I coded isn't coupled to services - it's purely transport
16:09:03 <mfer> yeah
16:09:18 <jamie_h> keeping that separation is very important, I agree
16:09:22 <mfer> ok, great. i'm looking forward to the next patch set to fix the segfault issue so we can keep this moving.
16:09:35 <mfer> samchoi do you have any other questions about this?
16:09:45 <jamie_h> do you want me to submit that fix as a separate patch or shall I update the current patch with the changes?
16:09:57 <samchoi> no, it seems like we're just making sure the transport layer is still loosely coupled for flexibility
16:10:16 <mfer> jamie_h just update the current set. it's a dependency to your other one that's ready to go in.
16:10:44 <mfer> are we ready for the next topic?
16:10:52 <jamie_h> yep
16:10:56 <mfer> #topic testing
16:11:15 <mfer> when I was at the summit I wanted to know how we can get the PHP SDK tested against multiple PHP versions
16:11:39 <mfer> I found out that we now can. where there were limitation stopping us before we can do this and nodepool should enable it to work
16:12:05 <mfer> unless someone else wants the action, I was going to take a look into how we can get this setup
16:12:24 <jamie_h> that sounds *really* useful
16:12:49 <samchoi> sure mfer , I can't see anyone refusing automated testing
16:13:13 <mfer> that's all i wanted to say. i know it had been a point of frustration and we'd talked about Travis CI as an alternative
16:13:39 <mfer> does anyone else want to talk about testing the things or shall we move on?
16:13:41 <jamie_h> i have something to add about our testing setup - but more related to code than infra
16:14:04 <mfer> jamie_h is it about faster testing?
16:14:11 <jamie_h> that's one of them
16:14:21 <jamie_h> the other is for us not to use @depends
16:14:36 <mfer> why is that?
16:14:56 <jamie_h> because it tightly couples tests together and makes them brittle. unit tests should be completely isolated and autonomous
16:15:18 <jamie_h> there's nothing wrong with using class properties (like $this->resource), but a unit test should not rely on another for input
16:15:58 <mfer> jamie_h how would you handle all the different setup and tear down cases?
16:16:19 <jamie_h> you'd have a generic setup and tear down case, and allow individual tests to instantiate their own fixtures as needed
16:16:30 <jamie_h> but the majority of cases tests will probably need a generic fixture
16:17:04 <mfer> jamie_h in the interest of time can you send an email to the list about this? I'm not opposed to it but I fear we'll run out of time on this topic.
16:17:08 <jamie_h> sure
16:17:09 <mfer> would that work?
16:17:11 <mfer> thanks
16:18:13 <mfer> i look forward to that email. i know testing is a broader topic than just this and we really don't have the time today. if we aren't done on the list by next week we can pick it up again then.
16:18:39 <mfer> If we're ok with it, let's jump into the reviews in progress
16:18:51 <jamie_h> happy to move on
16:18:54 <samchoi> sure
16:19:00 <mfer> #topic Reviews in progress
16:19:10 <mfer> #link https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z
16:20:01 <mfer> first up we have https://review.openstack.org/#/c/93892/. This removed even having default swift regions.
16:20:11 <mfer> jamie_h would you have a chance to review this one?
16:20:22 <jamie_h> I'll take a look tomorrow morning
16:20:25 <mfer> thanks
16:20:49 <samchoi> In the interest of time, I'm ot too worried about the first three since it looks like those are fairly straightforward and already got positive reviews
16:20:57 <mfer> samchoi ok
16:21:34 <mfer> https://review.openstack.org/#/c/93089/ the clientinterface and guzzle changes. besides the segfault fix is there anything else that needs to be handled or talked about?
16:22:15 <mfer> samchoi jamie_h ??
16:22:23 <jamie_h> i have nothing to add
16:22:33 <samchoi> Since we're not going with JSON schema at this point, it seems like the concerns we had about having to refactor are invald now
16:22:46 <samchoi> so yes
16:22:47 <samchoi> that's it
16:22:48 <mfer> and if they aren't we'll modify things later
16:23:08 <mfer> https://review.openstack.org/#/c/92280/ the sphinx one. i was hoping Shaunak would be here to talk about this
16:23:41 <jamie_h> if there are any comments about this patch, i can pass them on
16:23:42 <mfer> jamie_h do you know when he'll be back to chat?
16:23:51 <mfer> there are questions on it
16:24:09 <jamie_h> i'm not sure, i think shaunak is travelling for conferences for a while
16:24:34 <jamie_h> shall we postpone this one until we know more
16:24:43 <mfer> sure.
16:24:50 <samchoi> Sure, this review has less of an effect on others' work
16:25:01 <mfer> if he's too busy and one of us wants to jump in we can talk about it then
16:25:21 <mfer> then there is https://review.openstack.org/#/c/90407/ which is on testing
16:26:03 <mfer> to be honest, i'd like to see if there is a better option
16:26:19 <jamie_h> so, some preamble: I'm completely for end-to-end testing, it's incredibly important. But it should not be mixed with unit tests
16:26:34 <mfer> how much isn't integration tests?
16:27:00 <jamie_h> i think the vast majority are integration tests
16:27:29 <mfer> is it worth the effort to separate them if we can have a way to run the who suite really fast?
16:27:45 <jamie_h> probably not - perhaps it requires a more comprehensive solution
16:27:51 <jamie_h> this was just a temporary workaround
16:28:07 <mfer> are you familiar with php vcr? i'm not but samchoi has been looking into it
16:28:16 <jamie_h> yeah, I've looked into it
16:28:30 <samchoi> From what I understand, the Ruby Fog guys are using it quite extensively and had great results
16:28:38 <samchoi> so it got my attention
16:28:48 <jamie_h> yeah, but that just speeds up integration tests. I can go into more detail on the mailing list
16:28:55 <jamie_h> about what I mean, because I don't think we have time now
16:29:05 <samchoi> sure
16:29:37 <mfer> jamie_h thanks. i'm not opposed to any changes. it would just be good to talk through it so we can all understand all the things
16:30:17 <mfer> and we are out of time. thanks everyone for coming. feels like this was a good meeting.
16:30:20 <samchoi> hmm the last agenda item wasn't a high priority btw, since we're going to be kicked out
16:30:26 <mfer> #endmeeting