15:30:22 <mfer> #startmeeting openstack-sdk-php
15:30:23 <openstack> Meeting started Wed May 28 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:27 <openstack> The meeting name has been set to 'openstack_sdk_php'
15:30:37 <mfer> Hello everyone. Please state your name and any applicable association.
15:30:40 <mfer> Matt Farina, HP
15:30:44 <ycombinator> Shaunak Kashyap, Rackspace
15:30:46 <samchoi> Sam Choi, HP
15:30:47 <jamie_h> Jamie Hannaford, Rackspace
15:30:57 <glenc> Glen Campbell, Rackspace
15:31:57 <mfer> #topic agenda
15:32:07 <mfer> #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP
15:32:29 <mfer> 1. Intro to the PHP SDK if there is anyone new? (mfer)
15:32:29 <mfer> 2. Copyright statements in code files (mfer)
15:32:29 <mfer> 3. Service creation - context/bootstrap class which instantiates services, classnames of services, moving all authentication functionality (including X-Auth-Token stuff) to dedicated class (jamie_h)
15:32:29 <mfer> 4. 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:29 <mfer> 5. What are the essential blueprints/bugs that need to be finished before we can move on to working on additional services? (samchoi)
15:32:39 <mfer> anything else to add?
15:33:02 <jamie_h> I have nothing
15:33:29 <mfer> samchoi, glenc, ycombinator?
15:33:37 <ycombinator> nothing here either
15:33:37 <glenc> nope
15:34:00 <samchoi> I'm ok, I thought testing would be an item though
15:34:17 <mfer> 6. Testing
15:34:33 <mfer> I think we can skip number 1 since there is no one new.
15:34:43 <mfer> #topic Copyright statements in code files
15:35:11 <mfer> I had an action to dig into this so I went to talk with our legal folks. They are quite familiar with OpenStack.
15:36:12 <mfer> I was essentially told to put the HP copyright statement in any file we add or modify. If another organization adds or modifies a file they too can add their copyright statement to the file. That this is appropriate.
15:37:05 <glenc> Yup; cf. https://wiki.openstack.org/wiki/LegalIssuesFAQ#Copyright_Headers
15:37:15 <ycombinator> so mfer, to be clear, there can be multiple copyright headers per file if it is modified by multiple organizations?
15:37:32 <mfer> ycombinator yes. for example, https://github.com/openstack/swift/blob/6ac036fd013032287cfd8296c776ff57d7fcf79d/swift/common/middleware/tempurl.py
15:38:09 <ycombinator> cool, thanks
15:38:15 <glenc> The CLA gives OpenStack a license to use it but it does not transfer the copyright
15:38:40 <mfer> For us at HP, we'll be adding the appropriate HP copyright header. I'm not sure what rackspace is doing by jamie_h has suggested openstack having the copyright for your code.
15:38:49 <jamie_h> so would this be okay: https://gist.github.com/jamiehannaford/0b0801b6056217d04c97 ?
15:39:07 <mfer> jamie_h yes
15:39:42 <glenc> is that new code? if so, it shouldn't have then OpenStack Foundation line "the only valid reason for OpenStack Foundation copyright notices on new code these days is where the code was authored by an employee or contractor of the foundation"
15:40:21 <jamie_h> I'll add rackspace then
15:40:26 <glenc> Yes
15:40:38 <jamie_h> but otherwise, that's fine with me. I wanted to have a consistent formatting. ATM we're using colons instead of asterisks, which doesn't seem to be standard
15:40:45 <mfer> glenc it had previously been suggested that rackspace would use the OpenStack Foundation copyright. is should be rackspace instead?
15:41:14 <glenc> That's my understanding. Older stuff that Rackspace had done got transferred to the Foundation but, if you're working for Rackspace, then Rackspace holds the copyright and licenses it
15:41:20 <glenc> [to the Foundation]
15:41:31 <mfer> that makes sense. thanks for clearing that up
15:41:38 <glenc> Per that FAQ page as well as discussions with our legal folks a while back
15:42:00 <samchoi> About the specific type of license, what happens if two or more orgs use different licenses? (MIT, Apache etc)
15:42:27 <mfer> everything in OpenStack should be Apache 2.
15:42:36 <mfer> samchoi are you referring to dependencies?
15:43:06 <samchoi> No, I'm not familiar with all the copyright rules, but I was just wondering if that could happen
15:43:12 <samchoi> having multiple licenses that is
15:43:45 <mfer> you can dual license something. a copyright holder can do that. in our case that doesn't apply.
15:44:01 <jamie_h> so, moving forward: go through files that have been edited/added by Rackspace and add relevant copyright header
15:44:12 <mfer> jamie_h please
15:44:21 <jamie_h> and reformat to use standard docblock format (i.e. with asterisks instead of colons) - is that okay?
15:44:26 <glenc> http://lists.openstack.org/pipermail/legal-discuss/2014-January/000150.html
15:44:26 <jamie_h> but no content changes
15:44:41 <mfer> jamie_h will you take on that action?
15:44:49 <jamie_h> sure, I can do that
15:45:30 <mfer> jamie_h colons? Where is that used?
15:45:47 <jamie_h> sorry, ===== not colons
15:45:54 <jamie_h> long day :)
15:46:15 <mfer> jamie_h sure. i understand the long days
15:46:28 <mfer> is there anything else with regard to copyrights we should talk about?
15:47:04 <mfer> also, license and copyright are two related by separate issues. license is apache 2 and through the CLA. I don't think there are any issues with that.
15:47:30 <jamie_h> I don't have anything to add
15:48:32 <ycombinator> I'm good too
15:49:01 <samchoi> same, ready to move to 3.
15:49:12 <mfer> #topic Service creation
15:49:27 <mfer> jamie_h since you added this could you please start it up
15:50:21 <jamie_h> I've been working for the past 1-2 days on abstracting service creation. Nothing to do with how services are defined (since we still need to talk about that), but just the procedure of instantiating services and injecting the HTTP client into them
15:50:29 <jamie_h> I had a few questions before carrying on
15:51:01 <jamie_h> 1. Have we decided on a naming convention for services?
15:51:54 <jamie_h> so, for v2 swift - are we calling it ObjectStoreService, ObjectStorev2Service, or just ObjectStore\v2\ServiceClient
15:52:15 <mfer> #link https://wiki.openstack.org/wiki/SDK-Development#Goals_for_each_SDK
15:52:19 <notmyname> jamie_h: v2 swift?
15:52:40 <jamie_h> or v1 - just an example
15:52:48 <mfer> we should be using names reflective of the serivce not it's openstack name. so names like object store, identity, etc
15:53:19 <mfer> notmyname one of the considerations is the audience. these are app developers who don't know openstack. they don't typically understand what names like swift, keystone, etc are.
15:53:24 <jamie_h> yes, I agree. I have nothing against calling each one ServiceClient, and letting the namespace give the context
15:53:50 <ycombinator> I'd prefer ObjectStore\v2\ServiceClient
15:54:02 <jamie_h> me too - we already have a long namespace
15:54:04 <notmyname> mfer: no, my question is "what is 'v2' swift?" the v2 part, not the swift part
15:54:25 <mfer> jamie_h I was thinking something like ObjectStore\v1\ObjectStore or ObjectStore\v1\ObjectStoreClient. Something descriptice.
15:54:44 <mfer> notmyname ah, we're bouncing around conventions. we know there is no v2 swift yet
15:55:00 <jamie_h> mfer surely the namespace describes the context, though? I want to keep namespaces as succinct as possible
15:55:52 <mfer> What likes in ObjectStore\v1\ isn't something I have a strong opinion on
15:56:28 <ycombinator> okay, so are we agreeing on ObjectStore\v1\<something> as opposed to ObjectStoreV1Something?
15:56:56 <mfer> ycombinator I think so. it works better with the PHP namespaces and it's what we'd already put in place
15:57:01 <ycombinator> cool
15:57:12 <jamie_h> second thing I was working on was removing all auth logic from concrete services, and letting a subscriber do it
15:57:29 <mfer> what do you mean by a subscriber doing it?
15:57:41 <jamie_h> it listens out for any requests being sent, figures out whether the cached token is valid, and then re-authenticates as necessary
15:57:52 <jamie_h> instead of making services add their own headers whenever they make calls
15:58:13 <jamie_h> basically centralizing the process with a class that has a single responsibility, instead of dissipating the process over the codebase
15:58:38 <jamie_h> I can provide more details over mailing list
15:59:07 <mfer> jamie_hf ah, like a session handler?
15:59:13 <jamie_h> yeah pretty much
15:59:32 <jamie_h> you just attach it to the HTTP client and let it handle authentication
16:00:05 <mfer> attach it to the HTTP client?
16:00:21 <jamie_h> as a subscriber. and when the HTTP client sends a request, it informs the auth subscriber
16:00:38 <jamie_h> which checks the token, re-authenticates, and adds the token to the request headers
16:00:43 <mfer> first, i'm up for a session handler like that. i even have stub code somewhere to do that. it's also what the python sdk is doing.
16:01:38 <mfer> jamie_h so, you're talking about the way guzzle handles things. we can give that a shot. i see where you're going
16:01:49 <mfer> samchoi ycombinator glenc any thoughts on this?
16:02:19 <mfer> jamie_h the one thing we need to be careful of is the retry logic if the creds intentionally change and providing a means to catch errors around that
16:02:23 <samchoi> The general idea sounds fine. It seems we've even discussed this idea in the past mfer
16:02:30 <glenc> seems reasonable. better than some of the ways I've implemented reauth before :)
16:02:32 <ycombinator> I'm okay with the subscriber pattern
16:02:40 <ycombinator> but are we going to be tied into guzzle?
16:02:58 <mfer> we need to stay loosly coupled
16:03:03 <mfer> i think that's possible
16:03:04 <jamie_h> that's a good question - if we're using the subscriber, we can either create our own classes or use a dependency
16:03:20 <glenc> right. You might have to create a small wrapper around another HTTP client to implement this, right?
16:03:27 <jamie_h> subscriber dependency is separate from HTTP/transport layer
16:03:38 <jamie_h> we could use either symfony or guzzle IMO
16:04:05 <jamie_h> glenc that's what we're doing with the transport layer - wrapping guzzle to satisfy our interface
16:04:11 <glenc> right
16:04:50 <jamie_h> I see no reason why we can't rely on dependencies for utility classes, like subscribers
16:05:11 <jamie_h> it wouldn't compromise our decision to decouple the transport layer
16:06:21 <jamie_h> the last thing I did was rename Bootstrap to OpenStack, and having that as the main entry point for end-users to instantiate services
16:07:04 <mfer> there is a blueprint for that as well
16:07:28 <mfer> I'd like all dependencies to be injected and be replacable in some manner. loose coupling.
16:07:46 <jamie_h> yeah, me too
16:07:51 <mfer> it makes it a lot easier to not do major api breaking changes in the future if dependencies change
16:07:56 <jamie_h> I was thinking of something like:
16:08:09 <jamie_h> $openstack = new OpenStack(['username' => 'foo', etc. etc.]);
16:08:21 <mfer> yup
16:08:27 <jamie_h> $os = $openstack->objectStore();
16:08:38 <jamie_h> or something
16:09:06 <jamie_h> that's all I had - I can elaborate on details in mailing list after this meeting if anyone has questions or concerns
16:09:16 <ycombinator> jamie_h: how would they choose version?
16:09:20 <ycombinator> v1 vs. v2?
16:09:24 <ycombinator> in that construction
16:09:32 <samchoi> minor point, but I feel like the naming could be more descriptive. As a new user, I'd have no clue what an Openstack.php file would entail.
16:09:36 <mfer> I'd been thinking the same thing expect using something like $openstack->service('objectstore') .... so we can add more service w/ extensions
16:09:36 <jamie_h> they'd probably pass in to objectStore method
16:09:52 <jamie_h> mfer yeah - I used "get" method instead and had magic methods
16:09:59 <mfer> ycombinator in my service model we'd need to be able to firgure out things like version, region, etc
16:10:37 <mfer> service detection is something we can learn about from the openstackclient folks
16:10:57 <mfer> they've been learning the nuances of that in regard to different setups of openstack
16:12:52 <mfer> i'm good with this direction. shall we move on to the next item or is there more to talk about?
16:13:16 <jamie_h> samchoi I'll wrap all this stuff in an e-mail and we can talk about better alternatives for naming
16:13:24 <jamie_h> other than that, I have nothing else for this topic
16:13:41 <samchoi> sure, ready to move on
16:13:57 <mfer> jamie_h great. i think we're mostly on the same page with this stuff so that makes me quite happy
16:14:13 <mfer> #topic Reviews in progress
16:14:29 <mfer> #link https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z
16:14:33 <mfer> there are a bunch of them.
16:14:54 <mfer> which ones should we talk about with the 15 minutes we have left?
16:15:12 <mfer> the guzzle refactoring i'm in the process of reviewing given the latest changes
16:15:35 <jamie_h> a lot of patches hinge on the guzzle refactoring - but if that's mid-review there's not much to talk about
16:15:45 <jamie_h> Shaunak had reservations about the URL one
16:15:46 <mfer> jamie_h ycombinator can you look at https://review.openstack.org/#/c/94336/ and https://review.openstack.org/#/c/93892/
16:15:58 <ycombinator> looking
16:16:24 <mfer> i think you can look at them offline. we just need another person to review each of those
16:16:54 <mfer> ycombinator i saw your changes and i'll get to reviewing them this week. i hope others can as well.
16:17:02 <jamie_h> i'll take a look too
16:17:23 <mfer> jamie_h why a URL class rather than then PHP parse url function to an array? I'm not debating... just asking the why question.
16:17:37 <samchoi> I think ycombinator's changes were fairly independent of the others so that one should be easier to get in...
16:18:23 <jamie_h> because a lot of time we need more than what parse_url offers
16:18:32 <jamie_h> the ability to modify queries, add paths, etc.
16:18:40 <jamie_h> it's also useful for type hinting
16:19:03 <jamie_h> manipulating strings can also be verbose and annoying
16:19:21 <mfer> and why our own implementation rather than a dependency on someone else?
16:20:19 <jamie_h> because i wanted to have looser coupling
16:21:09 <jamie_h> if we relied on an external dependency, I think it might compromise our decision to have a generic transport layer
16:21:32 <jamie_h> plus the external dependency (non-Guzzle) has a lot of baggage we don't need
16:21:50 <mfer> we'd end up needing to have an interface and a default mechanism that would be easily overridden. for something like a URL class that could be difficult
16:22:36 <mfer> ycombinator you had concerns. do you have a strong opinion or any other thoughts?
16:22:44 <jamie_h> if that's the case - would folks be against using GuzzleHttp\Url ?
16:23:09 <mfer> jamie_h how would we make it easy to swap that out?
16:23:26 <jamie_h> I don't think we'd need to swap out a Url class
16:23:48 <jamie_h> it'd be up to an adapter to make other Url classes compatible with ours
16:23:51 <mfer> what if someone wasn't using guzzle or wanted to change to a newer major version where the Url class had been moved?
16:24:15 <jamie_h> they'd need to write an adapter than satisfies our type hints
16:24:40 <mfer> ah, ok. as long as it can be swapped i'm ok with it. the question is... should we? would making it an adapter be so much more code/complexity to make it worth it?
16:25:11 <jamie_h> the adapter would be required for the client to satisfy our ClientInterface
16:25:11 <ycombinator> I'm hesitant to roll something on our own for something so fundamental but I see Jamie's point about not pulling in a heavy dependency either
16:25:48 <ycombinator> the lightest dependency I found with some traction was this: https://packagist.org/packages/webignition/url
16:26:28 <jamie_h> why not use Guzzle's URL class instead of that, though? They'd both result in a tightly coupled dependency
16:26:45 <mfer> ycombinator given that we'd need to have an adapter/dependency injector for it... is using that worth it for something relatively small and simple?
16:26:48 <ycombinator> I'd be fine with using Guzzle's URL class if we are going to be pulling in Guzzle anyway
16:27:21 <jamie_h> I'm fine with using Guzzle for non-HTTP classes - like event subscribers - but I'm wary about keeping the transport layer as independent as possible
16:27:23 <ycombinator> in fact, if we are going to pull in Guzzle anyway, I'd /prefer/ to use its URL class
16:27:48 <mfer> ycombinator we loosly couple to Guzzle. we need to keep the things loosly coupled
16:27:51 <ycombinator> so - let me ask: are we going to be pulling in Guzzle as a dependency at all time?
16:28:01 <ycombinator> ok, so guzzle wouldn't be in composer.json then?
16:28:01 <jamie_h> it's a trade off between keeping things DRY or keeping things loosely coupled
16:28:27 <jamie_h> ycombinator it would because it acts as the default client. But users can override
16:28:37 <ycombinator> okay, so in that case, I say we use Guzzle's URL class
16:28:38 <jamie_h> so all the Guzzle codebase is there for us to use
16:28:56 <ycombinator> as opposed to pulling in yet another dependency or rolling our own
16:29:04 <jamie_h> hypothetical: say we add support for ZF2's HTTP client. their adapter would need to turn their URLs into Guzzle ones
16:29:08 <jamie_h> is that fine with you?
16:29:17 <mfer> i would be ok with using the Guzzle URL class if it can be swapped out in a similar manner to the the http client
16:29:32 <ycombinator> jamie_h: it wouldn't be different from turning it into our own URL class
16:29:38 <ycombinator> so yes, I'd be fine with that
16:30:05 <mfer> we should be able to use something like https://packagist.org/packages/webignition/url with ZF2's http client if someone wants
16:30:34 <ycombinator> should we continue in openstack-sdks?
16:30:41 <samchoi> sure ycombinator
16:30:44 <mfer> ycombinator yes. thanks for keeping time
16:30:48 <mfer> next meeting needs to start
16:30:51 <mfer> #endmeeting