15:30:56 <mfer> #startmeeting openstack-sdk-php
15:30:57 <openstack> Meeting started Wed Apr 23 15:30:56 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:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:31:00 <openstack> The meeting name has been set to 'openstack_sdk_php'
15:31:17 <mfer> Please state your name and any relevant association.
15:31:20 <mfer> Matt Farina, HP
15:31:23 <samchoi> Sam Choi, HP
15:31:28 <ycombinator> Shaunak Kashyap, Rackspace
15:31:30 <jamie_h> Jamie Hannaford, Rackspace
15:32:04 <mfer> Welcome folks
15:32:11 <mfer> #topic Agenda
15:32:15 <mfer> #link https://wiki.openstack.org/wiki/Meetings/OpenStack-SDK-PHP
15:32:42 <mfer> 1. Intro to the PHP SDK if there is anyone new? (mfer)
15:32:42 <mfer> 2. Near term roadmap (mfer)
15:32:42 <mfer> 3. Blueprints / Bugs / Reviews (mfer)
15:32:42 <mfer> 5. Open Discussion (mfer)
15:32:44 <mfer> 4. JSON Schema (jamiehannaford)
15:32:56 <mfer> is there anything else that should be added before we proceed?
15:33:19 <jamie_h> I have nothing
15:33:27 <ycombinator> me too
15:33:42 <mfer> I think we can skip #1 because no one is new here.
15:33:54 <mfer> #topic Near term roadmap
15:34:09 <mfer> #link https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Short_Term_Roadmap
15:34:24 <jamie_h> I have 1-2 things to discuss about near-term roadmap
15:34:31 <mfer> I have this on the agenda because I had an action to link the items on the roadmap to the blurprints which I did
15:34:37 <mfer> jamie_h what are they?
15:35:40 <jamie_h> I've started work on the codebase yesterday and my immediate priority was addressing the tests. At the moment there seems to be 2 problems: the first is that integration tests (hitting the API) are intermingled with unit tests, which is causing incredible slowness. The second is that many of the integration tests initially didn't work with Rackspace APIs
15:36:24 <mfer> jamie_h i'm aware of a couple issues that would cause problems. They are listed as bugs and samchoi is working on them right now
15:36:30 <mfer> was there something else beyond that?
15:36:39 <jamie_h> The patch I've submitted fixes the second issue, i.e. hotfixes which make tests work with Rackspace. I thought that was important before all other work commenced
15:36:58 <jamie_h> I can liaise with Sam about other stuff he's working on
15:37:25 <samchoi> sure, it's still early here so I haven't seen the changes yet. Will look into it shortly
15:37:35 <mfer> jamie_h we want the full test suite to work. for our testing purposes we'll be using devstack and our setup. devstack is is the openstack reference point.
15:37:45 <mfer> jamie_h we do want all the tests passing
15:38:01 <jamie_h> mfer yes, but I'm talking about splitting up integration tests from unit tests. Unit tests should not hit the API
15:38:14 <jamie_h> They should mock out responses or dependent classes
15:38:21 <jamie_h> Right now, that's not happening
15:38:30 <mfer> most of the test suite is integration testing
15:38:35 <jamie_h> exactly
15:38:48 <jamie_h> Today I've split them out into separate phpunit groups
15:39:03 <mfer> can we carve out some time to talk handling this at the openstack summit?
15:39:22 <jamie_h> mfer I won't be at the summit, I'm at a talk in Italy then
15:39:28 <mfer> ah, doh
15:39:36 <ycombinator> mfer: same here, I'm at a talk in NYC
15:39:51 <mfer> i'll miss meeting you two face to face
15:39:59 <ycombinator> yeah, its a bummer
15:40:42 <jamie_h> The main takeaway I have is that the initial code I've submitted in that patch (just the test fixes) is required for all other work to continue. I can look into extracting out the copyright headers into a separate patch
15:40:55 <jamie_h> mfer is that okay with you? extracting the copyright stuff out
15:41:53 <mfer> possibly. can you file a bug for this and detail out the issue as well. then link the commit to the bug.
15:42:12 <jamie_h> sure
15:42:16 <mfer> thanks
15:42:40 <jamie_h> would it be easier to delete the current patch in Gerrit? Can that happen?
15:42:52 <mfer> in the commit message on a link put Closes-Bug: 123 where 123 is the number
15:43:14 <mfer> you can abandon a patch set
15:43:33 <mfer> if you do the closes bug thing it will become a link to the bug in the review. it's useful for navigating the system
15:43:58 <mfer> jamie_h you said there was 1-2 things. is there something else?
15:44:04 <jamie_h> That's all I had
15:44:24 <mfer> anything else about the near term roadmap?
15:44:36 <ycombinator> I'm good
15:44:46 <jamie_h> Me too
15:45:06 <mfer> samchoi are you good?
15:45:32 <samchoi> I'm wondering what the priorities are, for the short term roadmap, in light of the testing issues jamie_h brought up
15:45:36 <samchoi> but we can save it for later
15:45:39 <samchoi> maybe open disc
15:46:08 <mfer> samchoi I think there is always a priority to have the system working. in the open discussion i'd like to now talk about testing.
15:46:22 <mfer> after than I think the priorities are numbered at the moment
15:46:23 <samchoi> ok, great
15:46:33 <mfer> does anyone disagree with the ordering?
15:46:51 <jamie_h> can we have json-schema before open discussion? since it follows on from blueprints
15:47:10 <samchoi> I would bump up the documentation a bit higher. I believe updating docs would be very helpful for newer contributors.
15:47:14 <mfer> jamie_h yes. i re-numbered above but slipped up where i hit enter
15:47:49 <ycombinator> samchoi: are you referring to user-facing docs (#8) or phpdoc (#3)?
15:47:58 <samchoi> user facing docs ycombinator
15:48:12 <samchoi> parts of the doc are out of date, due to a slew of recent changes
15:48:15 <ycombinator> that's good because I've started working on them :)
15:48:19 <ycombinator> I'll report in the BP section
15:48:24 <samchoi> thanks ycombinator
15:48:31 <mfer> samchoi i'm not sure we'll get many more contributors until after the first basic usable release is out.
15:48:39 <mfer> ycombinator btw, thanks for taking this on now
15:48:41 <jamie_h> me neither
15:48:57 <mfer> samchoi or I can somehow drum up some others at the summit. but, i'm not counting on it
15:48:57 <ycombinator> mfer: do you feel I should switch to something higher up on the list?
15:49:04 <ycombinator> since user-facing docs are #7
15:49:19 <samchoi> well, either for new contributors or even for jamie_h and ycombinator since they are getting into the codebase now
15:49:27 <samchoi> I'd hate for them to get into outdated docs, that's all
15:49:32 <mfer> ycombinator while it's a lower priority I still consider it a priority and a good chunk of work
15:49:42 <ycombinator> okay, thanks, I'll keep on keeping on
15:49:49 <mfer> priority doesn't necessairly suggest order we tackle
15:49:56 <mfer> though, maybe it should :)
15:50:04 <ycombinator> bingo, that was my confusion
15:50:07 <mfer> in any case, ycombinator i was happy to see you work on that
15:50:08 <samchoi> same
15:50:18 <ycombinator> cool cool
15:50:25 <mfer> are we ready to move on?
15:50:36 <jamie_h> yeah
15:50:38 <samchoi> yes
15:50:40 <ycombinator> yes
15:50:44 <mfer> #topic Blueprints / Bugs / Reviews
15:51:02 <mfer> #link https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z
15:51:09 <mfer> there are currently two reviews listed
15:51:25 <mfer> The .gitignore one I was reviewing when the meeting started
15:51:35 <mfer> that is https://review.openstack.org/#/c/89528/
15:51:49 <mfer> jamie_h what does the .idea directory work with?
15:51:56 <jamie_h> mfer PhpStorm
15:52:50 <jamie_h> it's becoming increasingly more common to add .idea to your .gitignore - I looked at a handful of other projects
15:53:05 <mfer> ok, i'll poke around at that shortly.
15:53:13 <mfer> samchoi can you take a look at that as well?
15:53:18 <samchoi> sure mfer
15:53:53 <mfer> great.
15:53:58 <mfer> the other issue was https://review.openstack.org/#/c/89785/
15:54:14 <mfer> it contains two separate changes so I've asked that it be broken up.
15:54:20 <jamie_h> yep
15:54:27 <jamie_h> copyright issue needs further investigation
15:54:38 <jamie_h> and the test fixes need consultation with Sam and a bug report
15:54:55 <mfer> the copyright headers portion is a legal thing. that might take a little time to track down guidance on. these are logically separate as well
15:55:18 <mfer> jamie_h if you hit any roadblocks on the bug portion please be sure to ping me
15:55:47 <jamie_h> mfer will do. I'll probably ping you about closing the existing patch too
15:55:53 <mfer> ok
15:55:58 <mfer> any other discussion on that one?
15:56:07 <jamie_h> not from me
15:56:18 <mfer> i have one other. https://review.openstack.org/#/c/88315/
15:56:35 <mfer> this change to infra would notify us in the sdk room when something went into review
15:56:46 <mfer> it's not landed yet but I thought it was worth automating
15:56:53 <ycombinator> yeah, I've seen it in solum
15:56:55 <ycombinator> I'm in favor of it
15:57:11 <jamie_h> also, another thing: what does Jenkins actually do when it checks a patch? It doesn't seem to run any testsuite
15:57:24 <mfer> unfortunately no.
15:57:35 <samchoi> correct, there are no gate tests at the moment
15:57:38 <jamie_h> is that something we can add in, or is out of our hands?
15:57:38 <mfer> the current setup works for python stuff. other languages and we run into problems
15:57:56 <mfer> it's out of our hands right now. i've spoken with the infra folks about it
15:58:06 <mfer> out of our hands for now not forever
15:58:15 <jamie_h> I think that should be the top priority issue with infra
15:58:53 <mfer> I do too. but, alas it's not.
15:59:29 <mfer> they have some bigger issues in the short term
15:59:32 <ycombinator> mfer: without knowing how the github mirroring of git.openstack.org works, could we setup a post-push hook in github to run the tests using something like travis?
15:59:53 <ycombinator> ... until infra gets php testing going
16:00:18 <jamie_h> ycombinator that would activate the hook after it's been merged though. I guess it's better than nothing
16:00:28 <ycombinator> yeah, its not perfect but its better than nothing, imo
16:00:33 <mfer> ycombinator i'd like to do that. i've been holding off asking them much about it lately because of other priorities. i was going to bring up the issue again at or after the summit
16:00:47 <mfer> other priorities for them that is
16:01:32 <mfer> ycombinator if you want to chance down an alternative setup in the short term that would be good
16:01:41 <ycombinator> ok, I'll investigate
16:01:43 <ycombinator> thanks
16:01:52 <mfer> there are currently two listed bugs http://bugs.launchpad.net/openstack-sdk-php
16:02:00 <mfer> they are related and samchoi is working on them
16:02:35 <jamie_h> samchoi I think I ran into the stream wrapper default region one
16:02:56 <jamie_h> and fixed it by pulling the region value out of the context options
16:03:00 <mfer> jamie_h i expected you would. i reported it thinking of you
16:03:15 <jamie_h> :)
16:03:15 <samchoi> mfer: jamie_h Yea the bugs aren't too bad, but I was holding off on submitting my changes until I have DevStack up and running
16:03:28 <samchoi> so that I'm able to test against a reliable environment
16:03:29 <mfer> gotcha
16:03:55 <mfer> there are two blueprints in progress as well https://blueprints.launchpad.net/openstack-sdk-php
16:04:14 <mfer> i've started the multiple api version one https://blueprints.launchpad.net/openstack-sdk-php/+spec/multiple-api-versions
16:04:27 <mfer> there's a spec at https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/Design/Multi-Version
16:04:35 <mfer> did anyone want to have any discussion about this?
16:04:37 <ycombinator> I've started (barely) the https://blueprints.launchpad.net/openstack-sdk-php/+spec/sphinx-docs one
16:04:49 <ycombinator> process question: do we report progress about the BP here?
16:04:52 <ycombinator> or how does that work?
16:05:07 <jamie_h> mfer the blueprint you've referenced ties in heavily with schemas - are you happy with starting to write that code?
16:05:13 <mfer> if you have something you want to talk about you can. but, this isnt' a standup
16:05:30 <mfer> jamie_h yes. and i'm prepared for schema discussions
16:05:43 <mfer> and how they relate
16:05:58 <jamie_h> okay, so everything falls into its own version directory. Nearly all of a service's functionality is defined by its schema file - right?
16:06:20 <jamie_h> Which utilizes classes, etc. inside the version directory
16:06:24 <mfer> this change doesn't do the schema portion. just the versions live in their own directories. it's a small change
16:06:32 <jamie_h> ah okay
16:06:41 <ycombinator> I have 2 questions about the sphinx docs BP but I'm holding off until the multiple-api-versions discussion is done
16:06:49 <mfer> micro changes. that's why i'm happy schemas has it's own blueprint
16:07:04 <jamie_h> so what would the directory structure look like?
16:07:15 <jamie_h> src / Identity / v3.0 /
16:07:36 <mfer> src / OpenStack / Identity / v3.0 /
16:08:02 <jamie_h> and inside 3.0 directory, would there be other standard folders? Is that covered in this blueprint?
16:08:13 <jamie_h> like Iterator or Resource etc.
16:08:28 <mfer> in that directory would be the thing to work with the service. this issue isn't dealing with what that thing is
16:08:36 <jamie_h> okay
16:08:53 <mfer> i'm intentionally keeping it vauge. the commit would keep the thing what's already in place.
16:09:07 <mfer> and leave changes to the thing to come separately
16:09:19 <jamie_h> which OpenStack services are you adding for now? Just Identity and Storage?
16:09:41 <mfer> identity and storage is all. adding more would mean more refactoring. that's whey we didn't put more out there from the start
16:10:15 <jamie_h> Today I worked on moving to a standard workspace structure, pretty much as you've outlined above with Identity and Storage as separate directories
16:10:26 <jamie_h> and common stuff (like transport, exceptions) in a Common directory
16:10:57 <mfer> ok
16:11:09 <jamie_h> How shall I continue with that work? Wait until you've submitted a patch and then rebase?
16:11:38 <mfer> sure. if you work on the bugs with sam i'll have my bit in for review here by tomorrow
16:11:54 <jamie_h> okay
16:12:01 <mfer> or, your work day might end first :)
16:12:23 <mfer> anything else or can we move on to ycombinators stuff? I'd like to have time for the json schema stuff
16:12:31 <jamie_h> I have nothing else
16:12:32 <mfer> and we have 18 mintues left
16:12:37 <ycombinator> okay -
16:12:37 <mfer> ycombinator what are your questions?
16:12:40 <ycombinator> mine should be quick
16:12:51 <ycombinator> 1. I've created a "spec" for the user facing docs here: https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/UserFacingDocumentation
16:12:55 <ycombinator> nothing ther eyet
16:13:17 <ycombinator> but: what is the process of getting all of your feedback on it?
16:13:58 <mfer> ycombinator you can email me, email the dev mailing list, and/or ping me in IRC
16:14:07 <mfer> as soon as I see any of this come through I'll jump on it
16:14:19 <mfer> I do hope that samchoi and jamie_h jump in with feedback as well
16:14:22 <ycombinator> okay, so there's no way of having the discussion in the wiki directly
16:14:23 <samchoi> we have a mailing list for the PHP SDK? Did I miss that
16:14:23 <ycombinator> got it
16:14:34 <jamie_h> ycombinator for now, maybe send it via e-mail to us all?
16:14:35 <ycombinator> samchoi: its just openstack-dev with the openstack-sdk-php tag
16:14:42 <mfer> samchoi no, all dev conversations go through the openstack dev list with a prefix for the project
16:14:48 <samchoi> ah i see
16:14:51 <samchoi> thanks
16:14:51 <jamie_h> okay, mailing list it is
16:14:55 <mfer> that's they way the openstack community does things
16:14:58 <ycombinator> and question 2. based on Matt's and Anne's email responses to my questions, I'm going to focus on having Sphinx spit out HTML in a directory (like build/) for now
16:15:08 <ycombinator> not worry about where they would be published eventually
16:15:18 <mfer> good
16:15:19 <ycombinator> I want to make sure everyone is okay with that scope for this BP
16:15:26 <mfer> i'm ok with it
16:15:28 <jamie_h> I'm happy with it
16:15:31 <ycombinator> cool
16:15:31 <samchoi> ok
16:15:31 <ycombinator> thanks
16:15:33 <ycombinator> that was it
16:15:38 <mfer> great
16:15:51 <mfer> if everyone is ok with it, lets move on to json schema
16:16:01 <samchoi> sure
16:16:08 <ycombinator> ok
16:16:08 <mfer> #topic JSON Schema
16:16:36 <mfer> jamie_h since this is your thing, can you present it?
16:16:47 <jamie_h> Okay
16:17:21 <jamie_h> So a few OpenStack services right now (Glance, Common, and possibly KeyStone) use json-schema to encapsulate data structures
16:17:44 <jamie_h> The plan is to use json-schemas in the SDK as a way to define services like Swift, Nova, etc.
16:18:29 <jamie_h> For example, HTTP operations will be clearly defined - with expected parameters, HTTP method types, URLs, etc. This avoids writing hundreds of lines of userland code which duplicates common functionality
16:19:01 <jamie_h> It also serves as living documentation - allowing end-users to understand exactly what they're expected to enter for operations
16:19:21 <jamie_h> Recently I've been working a light-weight library that allows schema files to be validated and consumed against live data
16:19:33 <ycombinator> jamie_h: dumb question: will this account for variances when certain services use PUT instead of POST to do resource creation, etc.
16:19:39 <ycombinator> s/account/allow
16:20:01 <jamie_h> yes, exactly. All API operations have their own entry, and allows for differences, say, in verb types
16:20:16 <jamie_h> we can also define models. Say for a Server, or for a DataObject
16:20:36 <jamie_h> so instead of writing a Server class, we define it in a few lines of JSON
16:20:57 <mfer> jamie_h i have a bunch of questions when you're ready
16:21:00 <jamie_h> sure
16:21:59 <mfer> jamie_h in your library you deal with validation. in your concepts how do you deal with the difference between testing and usage when it comes to validation?
16:22:36 <jamie_h> can you elaborate what you mean by "testing" and "usage"?
16:22:49 <jamie_h> do you mean how strict we'll be when using invalid schemas?
16:23:38 <mfer> this isn't user submitted data. we don't need to spend the time validating it every time the SDK uses it. it's not going to change over time. can you skip validation in use and do it as part of the test suite?
16:24:00 <mfer> i'm concerned with keeping things simple and code execution paths
16:24:12 <jamie_h> that's a good idea. Right now, it doesn't skip validation - but it's something I can look it when incorporating into the SDK
16:24:33 <mfer> when working with json schema files, how would you do debugging?
16:24:44 <jamie_h> debugging errors with schemas?
16:25:00 <mfer> that's one case
16:25:09 <jamie_h> so right now you have a ErrorHandler which collects validation errors
16:25:12 <mfer> to understand exactly what's going on and where. it's not in a line of code
16:25:29 <mfer> what happens if it's not a validation issue
16:25:44 <mfer> for example, the call goes through the proxy and the proxy changes things
16:25:57 <mfer> now you need to know what's going on and where it's happening
16:26:32 <jamie_h> There are two conceivable types of error: when a schema is itself invalid, or when a chunk of API data does not validate against a schema
16:26:51 <jamie_h> Is that what you're referring to? I don't know what you mean by proxy changes
16:27:16 <mfer> i'm thinking of the practical workflow of debugging.
16:27:34 <jamie_h> the error handler collects the errors, and it's up to you how you want to handle them. right now they're buffered, and i collect them after the validation process over a foreach
16:27:41 <mfer> when something normally encompassed in a method is now in a schema... what's that experience like?
16:27:42 <jamie_h> alternatively, you can emit them over STDOUT
16:28:00 <jamie_h> or save to a log file - it depends on how you implement ErrorHandlerInterface
16:28:21 <mfer> that assumes the issue is a schema not validating. the schema could be proper and the requests could still fail
16:28:32 <jamie_h> mfer when it comes to understanding normal SDK workflow debugging, I plead ignorance - I haven't got that far yet
16:28:44 <mfer> ok.
16:28:51 <jamie_h> If the request fails it indicates that the request data is invalid
16:28:57 <jamie_h> in which case you'll get precise reasons why
16:29:02 <mfer> given the time and the next meeting starting I think we need to take this offline. can we move this to an email?
16:29:08 <jamie_h> okay
16:29:19 <samchoi> please cc the rest of us, I'm interested as well
16:29:19 <ycombinator> jamie_h is there a BP + spec for this?
16:29:34 <mfer> i'm sorry to interrupt. i'd love to talk about this for a long time. i'll try to send it out later today
16:29:44 <jamie_h> https://blueprints.launchpad.net/openstack-sdk-php/+spec/service-json-schema
16:29:53 <mfer> samchoi i'll send it to the openstack-dev list. but, i'll cc you too. make sure you're getting that list
16:30:05 <mfer> #link https://blueprints.launchpad.net/openstack-sdk-php/+spec/service-json-schema
16:30:06 <ycombinator> thanks jamie_h
16:30:16 <mfer> ok, i'm calling the meeting so the next one can get started
16:30:19 <mfer> thanks for coming
16:30:22 <ycombinator> thanks
16:30:27 <mfer> #endmeeting