The meeting for today is canceled. Sorry for the short notice.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
The meeting for this Wednesday (8/20) is canceled.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
First I'd like to note that the weekly PHP SDK meeting this week is
canceled.
For the time being, unless someone has a good argument to the contrary, the
meeting will be suspended. Those of us working on PHP can be found in the
#openstack-sdks room in IRC.
The meetings have stopped being useful
When a group of us met recently we discussed documenting the contribution
process to the PHP SDK. I've now done so and it's available at
https://wiki.openstack.org/wiki/OpenStack-SDK-PHP/Process.
If there are any questions or comments I'd be happy to talk about them.
It seems we have two target audiences here. Developers who work on
OpenStack and developers who write apps to use it. In the long run I think
we need to optimize for both of these groups.
If we want developers to write applications to use OpenStack in python we
likely need a common python SDK.
It would really be nice to be able to hit an endpoint like
https://hostname:35357/ and get a list of available versions back. It would
make discovery easier.
But, for scripting languages like PHP this would add a lot of extra http
requests unless you cache the location between page
I would like to point out that the unified SDK has a different target
audience from the existing clients. Application developers who want to work
with OpenStack APIs are far different from those who are trying to build
OpenStack.
For example, application developers don't know what keystone, nova,
To make the OpenStack APIs easily accessible via PHP, the most popular
server side language of the web, we've been working on a PHP SDK in
Stackforge.
This week we are going to have our first IRC meeting on Wednesday. If
you're interested in a PHP SDK please come join in the discussion.
More
a specific and opinionated
design philosophy?
From: Jamie Hannaford [mailto:jamie.hannaf...@rackspace.com]
Sent: Tuesday, June 10, 2014 12:44 AM
To: Matthew Farina; Choi, Sam
Cc: Glen Campbell; OpenStack Development Mailing List (not for usage
questions); Shaunak Kashyap; Farina, Matt
.
If we keep things fairly simple, defined with interfaces, and reusable
this shouldn't be a problem.
When I asked a wide array of people about this topic without giving an
opinion I was surprised how many had similar ideas.
Thoughts?
- Matt
On Thu, Jun 12, 2014 at 4:12 PM, Matthew Farina m
I'll dig into these on Friday. Thanks for the poke. I started to review
them on Thursday and most of them are straight forward. But, something
happened to my test environment and I want to run the full test suite on
each of these. I should have that fixed and be able to finish working
through
at
doing it for things outside of python.
That's why I wanted to run the full test suite locally.
- Matt
On Fri, Jun 20, 2014 at 1:44 AM, Robert Collins robe...@robertcollins.net
wrote:
What does that check that the gate doesn't?
-Rob
On 20 June 2014 14:20, Matthew Farina m
users, use cases,
and other context. This is about solving problems and enabling users
to be successful over a particular sub-style in the PHP community.
Cheers,
Matt
On Mon, Jun 16, 2014 at 5:16 PM, Matthew Farina m...@mattfarina.com wrote:
Before I dig into the meat of my response, something
The PHP SDK Meetings for 7/23 and 7/30 are canceled. The next meeting will
be 8/6.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
We just completed a meeting on the OpenStack SDK for PHP and this email
attempts to sum up the discussion and action items to come from the
meeting. This was a face to face meeting that included discussions of
processes and architecture.
In attendance were,
- Glen Campbell, Rackspace
- Shaunak
, at 6:40 PM, Matthew Farina m...@mattfarina.com wrote:
We just completed a meeting on the OpenStack SDK for PHP and this email
attempts to sum up the discussion and action items to come from the
meeting. This was a face to face meeting that included discussions of
processes and architecture
Shaunak, these are some good questions. Input from the docs team would
be useful for some of these as well.
On Wed, Apr 16, 2014 at 10:06 PM, Shaunak Kashyap
shaunak.kash...@rackspace.com wrote:
Hi folks,
As part of working on
Jamie (and whom ever else wants to jump in),
It's been proposed to use json schema to describe the API calls rather
than code. The operations to perform and what they do would be
described rather than coded and then some code would use the schema to
know how to act.
Others are already doing
/JSON-schema-business-logic#So_how_can_it_be_done_well.3F
I think what you're proposing is that the methods map to API calls. There
isn't any logic in these objects that isn't an API call.
Jamie
From: Matthew Farina m...@mattfarina.com
Date: Thursday, April 24, 2014 at 5:42 PM
To: Jamie
Jamie, thanks for going into so much detail.
On Mon, Apr 28, 2014 at 9:28 PM, Matthew Farina m...@mattfarina.com wrote:
While reading this it struck me that we should prioritize the experience
of end-user, that is application developers, over the experience of those
working on the SDK. I
home with this audience is important. There are definitely
things we can link off to. I just want to make sure we hit home with
our target audiences.
On Thu, Apr 24, 2014 at 5:14 PM, Doug Hellmann
doug.hellm...@dreamhost.com wrote:
On Thu, Apr 24, 2014 at 11:18 AM, Matthew Farina m
Ken'ichi, thanks for the detail. I just added that summit session to my
list to attend. I'm looking forward to it.
On Thu, May 1, 2014 at 12:34 AM, Ken'ichi Ohmichi ken1ohmi...@gmail.comwrote:
Hi,
2014-04-29 10:28 GMT+09:00 Matthew Farina m...@mattfarina.com:
*3. Where would JSON
Vikas,
That's a great question. I was on vacation so it took me a little time to
respond.
If you use the OpenStack provider in jclouds you should be able to work
against OpenStack clouds from different providers. You won't have access to
any proprietary extensions. The package that seems to be
The golang-client/openstack-sdk-go is an SDK written in Go to operate
against OpenStack REST APIs. The project sits in stackforge and in one
of a number of Go clients for OpenStack. This email is here to
describe what we're doing and some base design decisions.
First, if there are Go clients for
It would be useful to have top level readme and contributing guides for
these two projects. I was going to round out both of these and wanted to
know what format would be good to use. Here's what I found.
First, a lot of .NET projects don't have top level files. I understand how
visual studio
We've started to talk about the interactions between transport
clients, service clients, and state. I've noticed we're not on the
same page so I wanted to start a dialog. Here's my starting point...
A Transport Client is about transporting data. It sends and receives data.
A Service Client
Some recent reviews have started to include the use of the private
keyword for methods and talk of using final on classes. I don't think
we have consistent agreement on how we should do this.
My take is that we should not use private or final unless we can
articulate the design decision to
, and re-used for every service client.
If we did that, there would be global state.
My opinion is that we create a *new* transport client instance for every
service client, not re-use existing instances. What’s your take on this?
Jamie
On June 5, 2014 at 5:17:57 PM, Matthew Farina (m
the two where the transport client knows about state of the service
breaks the separation of concerns.
They have separate jobs. The number of each you need depends on what's
happening in the scope of each space.
Does that make sense?
Jamie
On June 5, 2014 at 6:33:34 PM, Matthew Farina (m
, Matthew Farina (m...@mattfarina.com) wrote:
Some recent reviews have started to include the use of the private
keyword for methods and talk of using final on classes. I don't think
we have consistent agreement on how we should do this.
My take is that we should not use private or final
In my experience building apps that run in OpenStack, you don't give
up state. You shift how you handle state.
For example, instead of always routing a user to the same instance and
that instance holding the session data there is a common session store
for the app (possibly synced between
Jamie, thanks for sharing those links. They are quite useful and led
me to a couple questions.
1. To quote the first link, To do this, we need a way to describe the
requirement such that everyone – the business folks, the analyst, the
developer and the tester – have a common understanding of the
client, for example?
Jamie
On June 7, 2014 at 9:58:07 PM, Matthew Farina (m...@mattfarina.com) wrote:
My comments are inline below...
On Fri, Jun 6, 2014 at 8:47 AM, Jamie Hannaford
jamie.hannaf...@rackspace.com wrote:
Whether the same one is used for each service or a new one is used
The reviews are in and they are both merged. Thanks for the reminder.
On Tue, Jun 10, 2014 at 3:12 AM, Jamie Hannaford
jamie.hannaf...@rackspace.com wrote:
Hey folks,
Could we get these two patches reviewed either today or tomorrow? The
first is array syntax:
I would like to take a moment to point out that developing system software
is different from developing web applications. The way systems software is
developed and often deployed is different from web applications.
Horizon as it sits today appears to be web application development by
systems
In python we have a style to document methods, classes, and so forth. But,
I don't see any guidance on how JavaScript should be documented. I was
looking for something like jsdoc or ngdoc (an extension of jsdoc). Is there
any guidance on how JavaScript should be documented?
For anyone who doesn't
I'd like to step back for a moment as to the purpose of different kinds of
documentation. Sphinx is great and it provides some forms of documentation.
But, why do we document methods, classes, or functions in python? Should we
drop that and rely on Sphinx? I don't think anyone would argue for
too much.
-Matthew Farina m...@mattfarina.com wrote: -
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
From: Matthew Farina m...@mattfarina.com
Date: 01/14/2015 07:04AM
Subject: [openstack-dev] [horizon] function expressions vs
Doug, there still is one open question. Distributing JavaScript libraries
via system packages is unusual. Because of that, most of the JavaScript
libraries used by horizon don't have existing packages. Who will create and
maintain the packages for these JavaScript libraries for production? For
to have updates?
Thanks,
Matt
On Mon, Jan 19, 2015 at 3:45 AM, Radomir Dopieralski openst...@sheep.art.pl
wrote:
On 16/01/15 18:55, Matthew Farina wrote:
Doug, there still is one open question. Distributing JavaScript
libraries via system packages is unusual. Because of that, most
maintenance and updates for free. Since the system
packages don't exist now and we don't know who will create or maintain them
I'm not sure how to reconcile this.
What am I missing?
On Wed, Jan 21, 2015 at 3:04 AM, Radomir Dopieralski openst...@sheep.art.pl
wrote:
On 20/01/15 20:58, Matthew Farina
Martin,
django_compressor does handles creating aggregated and compressed files for
you. This isn't quite the same as C programs because it's not just due to
file size. For example, if you have 2 files many browsers will make two
separate connections to get each file. That mean negotiating a
JavaScript has multiple ways to deal with functions. There are function
declarations and function expressions (and named function expressions).
In looking at some reviews and the current code I found some
inconsistencies which leads me to ask, is there any guidance for handling
this in Horizon? I
I think we're discussing two different situations with slightly different
requirements.
First, there is development and test. I believe the stated goal is to have
node.js here. Would an environment not supporting node.js be needed for
development or testing? Note, the JavaScript under test and to
Radomir and Matthias,
Has anyone done an inventory of xstatic packages that are available as
system packages? I ask because I started asking these questions after doing
a cursory inventory and finding few xstatic packages as system packages. It
appeared to me that the common case was the one
. What's there isn't practically usable
today. Some things are missing.
Does that help add clarity?
On Thu, Jan 22, 2015 at 11:53 AM, Matthew Farina m...@mattfarina.com
wrote:
Radomir and Matthias,
Has anyone done an inventory of xstatic packages that are available as
system packages? I ask
for these dependencies. I imagine a solution has been thought
of for this. Can you share any details?
Thanks,
On Thu, Jan 22, 2015 at 2:35 PM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-01-22 11:53:10 -0500 (-0500), Matthew Farina wrote:
Has anyone done an inventory of xstatic packages
from
start to finish. I'm finding this to be incredibly revealing.
Thanks,
On Thu, Jan 22, 2015 at 3:47 PM, Richard Jones r1chardj0...@gmail.com
wrote:
On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina m...@mattfarina.com
wrote:
I would like to add one more nuance to this discussion that I
be required
for bower to work. Although, it seems something like private-bower [1]
could be utilized to leverage a local mirror where access or network
performance are issues.
David
[1] https://www.npmjs.com/package/private-bower
On Thu, Jan 8, 2015 at 2:28 PM, Matthew Farina m
wrote:
On 2015-02-05 09:20:35 -0800 (-0800), Matthew Farina wrote:
[...]
But, why do we document methods, classes, or functions in python?
Should we drop that and rely on Sphinx? I don't think anyone would
argue for that.
[...]
Particularly since Sphinx collects the method/class/function
Switching to an ini format would likely be painful to impossible.
Horizon is built on django which is where the settings.py format comes
from. It's part of a django app.
For more info see the django docs. The settings information is at
https://docs.djangoproject.com/en/1.6/topics/settings/
On
I've been going over the packaging problem in an effort to see how we can
move to something better. Given the current proposal around bower I'm still
left with a production deployment question.
For a build environment sitting in isolation, unable to download from the
Internet including Github,
Richard, thanks for sharing this. I hope we can move to bower sooner rather
than later.
On Sat, Mar 7, 2015 at 5:26 PM, Richard Jones r1chardj0...@gmail.com
wrote:
On Sun, 8 Mar 2015 at 04:59 Michael Krotscheck krotsch...@gmail.com
wrote:
Anyone wanna hack on a bower mirror puppet module
that Horizon should not be requiring optional headers. Changing
status of bug.
On Tue, Mar 3, 2015 at 5:51 PM, Jay Pipes jaypi...@gmail.com wrote:
Added [swift] to topic.
On 03/03/2015 07:41 AM, Matthew Farina wrote:
Radoslaw,
Unfortunately the documentation for OpenStack has some holes
54 matches
Mail list logo
