15:30:23 <mfer> #startmeeting openstack-sdk-php
15:30:23 <openstack> Meeting started Wed Apr  9 15:30:23 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:25 <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:54 <jamie_h> hey folks
15:30:57 <mfer> Hi folks
15:30:57 <samchoi> hello all
15:30:58 <ycombinator> hi everyone
15:31:22 <mfer> For the first item, can everyone state your name along with an affiliation if there is one.
15:31:23 <mfer> Matt Farina, HP
15:31:34 <samchoi> Sam Choi, HP
15:31:35 <glenc> Glen Campbell, Rackspace
15:31:44 <ycombinator> Shaunak Kashyap, Rackspace
15:31:48 <jamie_h> Jamie Hannaford, Rackspace
15:32:40 <mfer> #topic Agenda Items
15:32:51 <mfer> #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP
15:33:45 <mfer> I wasn't sure who else would come. The first two items an introduction to what this project is and what's in an SDK.
15:34:12 <glenc> Do we have a definition of "SDK" (beyond just PHP)?
15:34:34 <mfer> glenc yes. https://wiki.openstack.org/wiki/SDK-Development
15:34:35 <ycombinator> glenc: item #2 on the agenda links to https://wiki.openstack.org/wiki/SDK-Development
15:34:40 <glenc> Yeah, found it
15:35:09 <mfer> The first item was meant to be an introduction to the PHP SDK and what it's for.
15:35:33 <mfer> #topic What is the OpenStack SDK for PHP?
15:35:43 <mfer> #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP
15:36:22 <jamie_h> I generally agree with the definition on https://wiki.openstack.org/wiki/SDK-Development, except that "system" is slightly unclear. I'd replace with "any remote OpenStack system"
15:36:33 <mfer> The goal of the PHP SDK is to have a language binding, documentation, and examples for PHP application developers to talk to OpenStack endpoints. they don't need to know how OpenStack works.
15:37:03 <jamie_h> and also tests, which guarantee API behaviour and allow users to understand how to interact with it
15:37:06 <mfer> I put this item on here for anyone not familiar with the concept
15:37:43 <mfer> since we've already talked about this, do we need to talk more about the point of a PHP SDK or can we move on to SDKs in general?
15:37:59 <ycombinator> mfer: looking at the short term roadmap items on https://wiki.openstack.org/wiki/OpenStack-SDK-PHP, should we say something about the specific services we'll aim to implement in the short term?
15:38:22 <mfer> ycombinator that's agenda item 3. we'll get there
15:38:32 <jamie_h> mfer My definition was for general SDKs
15:38:39 <jamie_h> but I'm happy to move on
15:38:43 <ycombinator> right, thanks
15:38:48 <ycombinator> in that case, move on
15:38:51 <samchoi> agreed
15:38:56 <mfer> #topic What's in an SDK?
15:39:04 <mfer> #link https://wiki.openstack.org/wiki/SDK-Development
15:39:45 <mfer> The section on "What's in an SDK?" was originally written by Jesse at Rackspace
15:40:44 <jamie_h> source code which provides a convenient API for interacting with OpenStack services; tests which guarantee behaviour; feature specs; documentation which explains in simple terms how to interact with the SDK; code samples
15:40:45 <mfer> The system is meat to talk about an OpenStack installation somewhere. The SDK interacts with it but is not part of it.
15:41:16 <jamie_h> Does anybody disagree with any of my points?
15:41:37 <mfer> this is a general description for all SDKs. Changing this shouldn't happen without engaging some of the other teams.
15:41:58 <mfer> what do you mean by tests which guarantee behavior?
15:42:03 <mfer> jamie_h ^^
15:42:54 <jamie_h> the purpose of a test is to guarantee that a class behaves in a certain way. It also serves as a working code sample for users
15:43:29 <mfer> i'm curious how you relate that to openstack api endpoints.
15:43:40 <jamie_h> i'm relating it to source code
15:44:30 <jamie_h> perhaps it should be changed to: "tests which guarantee the behaviour of elements in the SDK"
15:44:56 <mfer> you used the phrase "which guarantee behaviour". How do you see that as differing from other types of tests?
15:45:54 <jamie_h> because the scope is different. a unit test or spec test will guarantee internal threads of behaviour. acceptance tests verifies the API of the SDK. integration tests verifies our SDK successfully maps to remote endpoints
15:46:35 <jamie_h> i kept it general because we don't need to go into too much detail for this top-level definition of what a SDK is
15:46:44 <ycombinator> jamie_h: are you proposing adding tests to this list: https://wiki.openstack.org/wiki/SDK-Development#Goals_for_each_SDK?
15:47:26 <jamie_h> ycombinator i can do that as an action item if that's okay with everyone?
15:47:35 <ycombinator> well - as mfer said, that page is shared
15:47:45 <ycombinator> so we should probably make sure its okay with other SDK owners as well
15:47:58 <jamie_h> i want to make sure what i'm writing aligns with everyone else's opinions
15:48:32 <mfer> jamie_h this is for the SDK Development in general. it touches the python sdk, Go sdk, .NET sdk, and others.
15:48:50 <mfer> as ycombinator noted, any changes in scope to that should go through them as well
15:49:18 <ycombinator> mfer jamie_h: in the interest of time, should we take an action item to check with other SDK owners about adding tests?
15:49:36 <jamie_h> mfer ycombinator sure, i can do that
15:49:38 <samchoi> agree with ycombinator
15:50:12 <mfer> who wants to own that?
15:50:16 <mfer> ah
15:50:42 <mfer> #action jamie_h Connect with SDK owners about testing.
15:50:44 * ycombinator is excited about using meeting bot's features
15:51:14 <mfer> are there any other elements of the SDK Development page we should discuss?
15:51:16 <ycombinator> okay, I'm good with the SDK definition otherwise
15:51:35 <jamie_h> me too
15:52:10 <mfer> #topic Near term roadmap
15:52:18 <mfer> #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Short_Term_Roadmap
15:54:15 <mfer> ycombinator you asked earlier about specific services. There are currently blueprints for compute and networking.
15:54:48 <ycombinator> mfer: cool, is that something we ought to make explicit in the roadmap
15:54:56 <ycombinator> just so users know what's coming
15:55:26 <mfer> I intentionally kept it at a high level. If someone wants to contribute another service that would be great.
15:55:47 <jamie_h> I've submitted a bunch of blueprints that deal with core features for the SDK.
15:55:52 <mfer> I would also put image and block storage on the list to round out elements around compute
15:56:05 <mfer> jamie_h I saw that.
15:56:35 <ycombinator> so, to be clear: identity (implicit), compute, networking, image and block storage
15:56:49 <ycombinator> ... are all part of the short term deliverables
15:56:51 <ycombinator> ?
15:57:16 <jamie_h> these are high-level features, right? Would core components (like Guzzle, json-schema) get included in this list?
15:57:40 <mfer> ycombinator I would say the short term deliverables are to round out the architecture changes and then to add services. the short term is to change the architecture. adding servcies is both short and mid term
15:57:52 <jamie_h> +1
15:58:12 <ycombinator> okay, cool; then short term roadmap looks good to me as-is
15:58:34 <jamie_h> most of these short-term architectural changes are in separate blueprints
15:58:37 <glenc> is there a blueprint for the "support multiple service API versions"
15:58:39 <glenc> ?
15:58:50 <ycombinator> glenc: https://blueprints.launchpad.net/openstack-sdk-php/+spec/multiple-api-versions
15:58:55 <mfer> so, the second short term item is to move to HTTP Messages from FIG, Guzzle as the default transport layer, and make it pluggable. That is up for review at https://review.openstack.org/#/c/86137/
15:59:09 <glenc> we should probably link to those when possible
15:59:41 <mfer> glenc I was going to work on the support for multiple api versions first but Jamie had a great suggestion to deal with Guzzle so I did that first
15:59:50 <jamie_h> mfer I started a blueprint which invited discussion about what we mean by pluggable. I think we should move that discussion to the Wiki
16:00:11 <jamie_h> https://blueprints.launchpad.net/openstack-sdk-php/+spec/transport-client-flexibility
16:00:45 <ycombinator> mfer I'd like to take an action item to link short term roadmap to blueprints
16:00:50 <mfer> i see you added that. for reference take a look at https://review.openstack.org/#/c/86137/1/src/OpenStack/Transport/ClientInterface.php
16:00:59 <mfer> ycombinator I'll do that
16:01:11 <ycombinator> thanks
16:01:12 <mfer> #action mfer link the short term roadmap to blueprints.
16:01:41 <glenc> heh I just did the first one :)
16:02:18 <jamie_h> mfer I think the interface looks promising. By pluggable, do you mean the ability for the entire client to be swappable? (So a user can define their own)
16:02:28 <mfer> yes
16:02:35 <jamie_h> If so, is there a real use-case for that?
16:02:37 <mfer> but Guzzle is the fall back/default
16:02:57 <jamie_h> Connection adapters offer as much flexibility
16:03:53 <mfer> They are flexible. and the Guzzle implementation lets you inject a Guzzle client you've altered as needed
16:04:15 <mfer> but, there are cases where you'd want to do something entirely different. we've run into two use cases for that.
16:04:44 <jamie_h> okay, so we could add the ability where a service (like SwiftClient) could redefine its HTTP client?
16:05:10 <jamie_h> setHttpClient(HttpClientInterface $client)
16:05:20 <jamie_h> and the service effectively wraps it
16:05:55 <glenc> yes, a dependency injection to override
16:06:07 <mfer> soft of. it's dependency injection rather than extending. so, the clients/managers for servcies are loosly coupled to the http client
16:06:18 <jamie_h> okay, i think that's a great idea
16:06:19 <mfer> but, Guzzle is the fall back default
16:07:11 <mfer> in the interest of time, is there something else on the roadmap to talk about?
16:07:32 <mfer> i'm happy to talk about transport layer elements. we can carry those into #openstack-sdks too
16:07:45 <glenc> is there any proposal for how to handle vendor extensions yet?
16:07:52 <jamie_h> i've added a blueprint for it
16:07:58 <mfer> yes. it's been discussed in the past
16:08:13 <mfer> both in the low level and for the service discovery parts.
16:08:14 <glenc> ok, sorry
16:08:26 <jamie_h> details are vague at the moment because it's not a top level priority right now, as i understand it
16:08:27 <mfer> i've even discussed those with some of the other SDK groups.
16:08:50 <mfer> when I update the short term plan I'll add lots of details to the blueprints
16:10:09 <mfer> something else worth noting from an implementation standpoint is the user facing docs. we'd wanted that to be an all in one getting going guide
16:10:29 <mfer> the idea is that application developers don't know openstack and should learn what they need there.
16:10:41 <mfer> we'd talked about doing it consistently with rst/sphinx
16:11:00 <mfer> That might even have been Jessies idea
16:11:01 <jamie_h> i agree that having a good "getting started" guide is essential
16:11:09 <glenc> yes, we've discussed with anne gentle as well
16:11:22 <glenc> specifically about making the technology as easy as possible for devleopers to contribute
16:11:27 <glenc> s/devleopers/developers/
16:12:01 <mfer> i'm actually not sure RST is the easiest method for developers. Far more developers are familiar with markdown than RST.
16:12:16 <mfer> but, RST/Sphinx is what openstack uses and it's increasing in use.
16:12:30 <mfer> it's also richer to describe these types of things
16:12:37 <ycombinator> I'm happy to take a stab at the user-facing docs using rst/sphinx
16:12:49 <ycombinator> I see the bp for it
16:13:24 <mfer> ycombinator in the order of things i put it a little later because any code might change due to architecture stuff. but, if you want to start it sooner that would be great
16:13:42 <mfer> there is already a doc directory with a bunch of material to be reworked into the new format or thrown out
16:13:45 <ycombinator> yeah, totally, makes sense to let the code "settle" a bit
16:13:59 <ycombinator> but I'll start playing with sphinx/rst
16:14:27 <mfer> other projects like the python-openstackclient already have a setup in a subdirectory. might be worth looking at those setups as well
16:14:33 <ycombinator> will do
16:15:09 <mfer> if you have questions feel free to ask. I've worked with these before.
16:15:18 <glenc> fwiw, most other OpenStack docs are in a separate repo from the code
16:15:24 <glenc> not sure I like that model personally
16:15:37 <glenc> I'd rather see docs committed alongside code
16:16:14 <glenc> we can always move to that in the future if that's what OpenStack wants
16:16:44 <ycombinator> okay, sounds good to me
16:16:48 <mfer> glenc the scope and setup is interesting. for many projects there is end user docs for a service as a separate repo. then there's different internal docs. for example see https://github.com/openstack/nova/tree/master/doc and https://github.com/openstack/api-site
16:17:17 <glenc> yup
16:17:20 <mfer> we'd discussed that we want the docs to be internal and easy to use/follow. so you can generate a site or you can just read it and use it as part of the sdk
16:17:33 <ycombinator> +1 to getting the docs as part of the SDK codebase
16:17:40 <mfer> the goal is end user application developers. give them one package that just gives them what they need to know
16:17:45 <ycombinator> yup
16:18:20 <ycombinator> okay, so I think we are all in agreement here: subdir in same repo as code
16:18:36 <mfer> i think so
16:18:37 <samchoi> yes, that certainly seems sensible
16:18:52 <glenc> +1
16:18:59 <jamie_h> +1
16:19:05 <mfer> I'm glad everyone is in agreement. that's the direction we'd been taking here and on other SDKs.
16:19:14 <mfer> if there's not other discussion on the near term goals, shall we move onto the bugs/reviews?
16:19:36 <ycombinator> mfer: possibly
16:19:50 <mfer> ycombinator is there something else?
16:19:55 <ycombinator> is now a good time to talk repo initial state (i.e. as part of short term goals), or do you want to save that for open discussion?
16:20:12 <mfer> i was thinking open discussion
16:20:33 <ycombinator> okay, cool; lets keep moving
16:20:45 <mfer> #topic Bugs / Reviews
16:20:54 <mfer> #link https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z
16:21:03 <mfer> #link https://bugs.launchpad.net/openstack-sdk-php
16:21:27 <mfer> The one item out for review actually fixes bug #1277535
16:21:38 <mfer> the other two bugs are linked and something I'm working this week.
16:21:48 <mfer> did anyone want to discuss them?
16:23:59 <mfer> silence. i'll take that as no discussion.
16:24:03 <jamie_h> i haven't spent much time on these patches because the repo issue was under discussion
16:24:07 <jamie_h> i have nothing to add
16:24:08 <ycombinator> to be honest, I feel like reviews are closely related to the initial repo state discussion so...
16:24:17 <mfer> #topic Open Discussion
16:25:00 <mfer> It seems the repo state discussion is the one on your minds
16:25:21 <mfer> Here is where I'm at...
16:25:25 <ycombinator> yeah, its pretty fundamental to any actual changes
16:26:55 <mfer> We have an SDK that we contributed to stackforge and altered to be OpenStack rather than HP Cloud. We have a larder codebase than we released because we went all in on OpenStack rather than continuing to drive our own. We wanted to make the needed changes for OpenStack before we added service....
16:27:24 <mfer> For example, there are things like multiple api version support that needed to happen.
16:28:07 <mfer> I'm sorry if there was confusion. I'd stated some months ago that we were planning to start with this codebase and alter it as needed.
16:28:59 <samchoi> larger codebase that was *not released, meaning our internal PHP SDK right?
16:29:06 <samchoi> to avoid confusion
16:29:23 <mfer> This is the SDK we're going all in on for PHP. Our HP one is only in major bugfix mode.
16:29:33 <ycombinator> mfer: likewise
16:29:46 <ycombinator> from a general contributor perspective, wouldn't it be easier to start from an empty repo, though?
16:29:46 <mfer> samchoi yes. the lager codebase is the internal one you've done a great job with.
16:30:40 <jamie_h> yes. no legacy decisions, cleaner code, and it allows members to be included from the very beginning
16:30:50 <mfer> i'm curious to know why? many folks prefer to join into an architecture that's already there so add to it or work on needed tasks.
16:30:51 <tjones> you guys almost done?  we have another meeting starting now.  sorry to push you out
16:31:05 <ycombinator> lets continue in openstack-sdks?
16:31:09 <tjones> thanks
16:31:10 <jamie_h> yeah okay
16:31:10 <samchoi> that's fine
16:31:12 <mfer> tjones thanks
16:31:25 <mfer> #endmeeting