open PaaS over your OpenStack infrastructure will significantly help your
developers and operational teams.
John
John Purrier
Chief Technology Officer appfog.com <http://www.appfog.com>
jpurr...@appfog.com
j...@openstack.com
About: johnpur <http://www.linkedin.com/in/johnpur>
From: F
This is great info, John. Thanks.
John
John Purrier
j...@openstack.com
(206) 930-0788
http://www.linkedin.com/in/johnpur
On 8/10/12 9:31 AM, "John Dickinson" wrote:
>In a standard swift deployment, the proxy server is running behind a load
>balancer and/or an SSL terminato
I haven't seen a proposal for Heat incubation?
John
John Purrier
j...@openstack.com
Chief Technology Officer, Appfog
(206) 930-0788
http://www.linkedin.com/in/johnpur
On 8/6/12 2:29 PM, "Jonathan Bryce" wrote:
>Does everyone want to cover this and the supporting p
m and also one of the contest
judges.
John
John Purrier
j...@openstack.com
(206) 930-0788
http://www.linkedin.com/in/johnpur
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpa
Hi all, recently there was a post by Zdnet about some folks that are
implementing VDI (virtual desktop) integrated with OpenStack. I would like
to get in touch with the project, if anyone knows of or are part of the
effort.
Thanks,
John
John Purrier
j...@openstack.com
(206) 930-0788
http
Congratulations to everyone in the OpenStack community for achieving this
milestone!
John
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
Of Thierry Carrez
Sent: Thursday, April 0
+1.
Interesting scenarios open up if we can have the scheduler intelligently
direct workloads based on config/metadata.
johnpur
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
Of Vishvananda Ishay
arrez (ttx)(Rackspace)
John Dickinson (notmyname)(Rackspace))
Vish Ishaya (vishy)(Rackspace)
Josh Kearney (jk0)(Rackspace)
Joshua McKenty (jmckenty)(Piston)
Ewan Mellor (ewanmellor)(Citrix)
Jay Pipes (jaypipes)(Rackspace)
John Purrier (johnpur)(HP)
Monty Taylor (mordred)(Rackspace)
Paul Voccio (pvo)(Racks
OK.
-Original Message-
From: openstack-poc-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-poc-bounces+john=openstack@lists.launchpad.net] On
Behalf Of Jonathan Bryce
Sent: Monday, October 03, 2011 1:38 PM
To: openstack-poc@lists.launchpad.net
Subject: [Openstack-poc]
Ok, but we should tie up these threads soon. We should add a policy discussion
around security updates and processes.
Additionally, I would like to start a discussion around setting up targeted
'work groups' that have significant project impacts, but may not involve code.
The two I am thinking
Nice work by all in hitting this milestone!
johnpur
On Jun 30, 2011, at 10:47 AM, Thierry Carrez wrote:
> Hello everyone,
>
> Another four weeks, another milestone ! In the spirit of getting
> features out to the world as soon as possible, today sees the
> availability of the second milestone
or PaaS-elements. As
the projects mature and some of them apply to be "incubated" we should have
an agreed to position as to what is within the OpenStack charter and what is
clearly not.
John
From: Joshua McKenty [mailto:j...@piston.cc]
Sent: Tuesday, June 14, 2011 5:08 AM
To: Jay
@lists.launchpad.net] On
Behalf Of Thierry Carrez
Sent: Monday, June 13, 2011 1:48 PM
To: openstack-poc@lists.launchpad.net
Subject: Re: [Openstack-poc] Meeting tomorrow
John Purrier wrote:
> Does it make sense to discuss the state/progress on the GitHub migration
> project? I think someone needs to se
nstack-poc-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-poc-bounces+john=openstack@lists.launchpad.net] On
Behalf Of John Purrier
Sent: Monday, June 13, 2011 1:10 PM
To: 'Jay Pipes'; 'Jonathan Bryce'
Cc: openstack-poc@lists.launchpad.net
Subject: Re: [Openstac
+1 on being totally transparent. Advocates for projects must be at the meeting
where the application is discussed, inevitably questions will come up that can
only be answered by someone with project knowledge.
Jay, what is your concern with PHP?
With all of the project integration work in fligh
Monty, this is great stuff, glad to see significant movement on the
CI/testing front.
The OpenStack PPB has claimed the hour prior to the OpenStack weekly
meeting, can you go 2 hours earlier?
Thanks,
John
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
Guys, I suggest we turn down the heat and rhetoric on this. We all are working
to make OpenStack great, and need to work through our internal
issues/disagreements in concise and professional manners.
Prior to anyone doing anything regarding projects moving to GitHub, let's get a
plan on the tab
On initial reading this is great stuff. As Josh McKenty pointed out you
should relocate the wiki page and then create a blueprint so we can track
the project.
I will have some specific responses and a couple of questions after spending
some time grokking the proposal.
John (johnpur)
-Origina
Where we left it at the design summit was that termie & mtaylor were going
to put together a plan for moving the code repositories to github. This plan
needs to detail not only the mechanics of moving from bzr but also how the
dev workflow works in terms of code management, code reviews, integratio
This time works for me.
John
On Jun 3, 2011, at 12:28 PM, Jonathan Bryce wrote:
> In yesterday's PPB meeting we discussed the meeting schedule. It sounded like
> most people preferred to keep it scheduled on a weekly basis and just
> continue skipping it when we didn't have any business to di
Agree. The fact remains that we need some leadership from the community over
the API's. And it would be nice to have a reference implementation.
John
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Wednesday, June 01, 2011 12:06 PM
To: John Purrier
Cc: Jon
t;> jos...@piston.cc
>>
>>
>>
>> On 2011-05-31, at 10:15 AM, John Purrier wrote:
>>
>>> +1.
>>>
>>> This will not slow the development of the projects and allows logical
>>> management of the projects to be promoted to &
+1.
This will not slow the development of the projects and allows logical
management of the projects to be promoted to "core". In order to make this
happen we will need to lead the DS timelines, as ttx points out, to allow
PTL elections and to involve the new project PTL's in the upcoming DS
plann
OK by me, I am on a plane tomorrow.
John
From: openstack-poc-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-poc-bounces+john=openstack@lists.launchpad.net] On
Behalf Of Jonathan Bryce
Sent: Wednesday, May 25, 2011 4:30 PM
To: openstack-poc@lists.launchpad.net
Subject:
I would add this, it fleshes details on the core project definition.
John
-Original Message-
From: openstack-poc-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-poc-bounces+john=openstack@lists.launchpad.net] On
Behalf Of Thierry Carrez
Sent: Thursday, May 19, 2011 1:
I think there is still much fuzziness in the incubation description. What
are the "incubation assets"? Define what "some access to community
resources" means. etc.
Also, and perhaps this is just a matter of timing, but how do we think of
projects like Lunr, Quantum, Melange, Burrow, etc.? Pre-i
Vish, this is good stuff. We should pick this up in glance and swift, either
sharing a common effort with nova or specifying for each project the same
documentation that Vish is suggesting.
Heads up for other projects that are looking to be affiliated or incubated
projects, it will save time an
Silly rabbit, Trix are for kids... Wait, what channel am I on?
-Original Message-
From: openstack-poc-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-poc-bounces+john=openstack@lists.launchpad.net] On
Behalf Of Vishvananda Ishaya
Sent: Monday, May 09, 2011 11:21 AM
To:
nstack.org/debian_package_guide.html
>
> What is that based on (if I wanted to provide patches for it)? Is it
> in the swift code repo?
Yes, just like nova.openstack.org swift.openstack.org is autobuilt via
Sphinx from the project's trunk.
As far as what should
Rick, we have set up a top level LP project "futurestack" and moved all of
the associated but not official projects to be children of this. Feel free
to link the new network projects here if you want, it allows us to have a
single LP spot to go to in order to see the activity on these projects.
Jo
Well deserved, Justin. You have been a great contributor to the project!
John
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
Of Justin Santa Barbara
Sent: Friday, April 15, 2011
How about gathering at the water cooler in Santa Clara in a couple of weeks and
discussing :)?
Until then, super focused energy on working out the remaining Cactus bugs,
validating the installation and operation of Nova/Swift/Glance, and getting our
packages ready to release would be super!
Jo
Thierry, this is a great way to keep the issues in front of people. We
should continually (at least once a day) publish the bugs that are not
assigned and being actively worked.
OK, folks, we are in the crunch for Cactus... Pick up a bug and knock it
off!
John
-Original Message-
From: op
" The problem we've been having revolves around the fact that we have
dozens of developers working on Nova, with no real guidance as to the
long-term direction of the project, and teams just doing whatever the
heck they want to, without ML discussion and blueprints, and then
expecting people to
Hi Thierry, in addition to the technical sessions for Nova, Swift, and
Glance at the design summit, I have asked Stephen to add "Project and
Release management". You will own the time slots, once the PTL's are on
board we will discuss how best to schedule the sessions.
Thanks,
John
-Original
Agree that this is a tricky technical issue, and I agree that the issue of
management of Authn and Authz should be external to Nova and all other
OpenStack components.
I believe there are two fundamental problems to be solved and that we will
confuse ourselves if we try to mix them together:
I am OK with whatever the group decides.
John
-Original Message-
From: openstack-poc-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-poc-bounces+john=openstack@lists.launchpad.net] On
Behalf Of Ewan Mellor
Sent: Thursday, March 24, 2011 10:01 AM
To: Jonathan Bryce; op
I know that creiht is looking at this for Rackspace. Chuck, anything to add
to this discussion?
John
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
Of Adam Johnson
Sent: Monday,
Agree with Eric and Thierry on this.
John
On Mar 8, 2011, at 1:09 AM, Thierry Carrez wrote:
> Eric Day wrote:
>> If we hit performance issues with this type of application, we'll
>> probably hit them around the same time with both Erlang and Python
>> (then we'll look to C/C++). Since most Open
Updates to the OpenStack Governance Model have been made and are published
here: http://wiki.openstack.org/Governance/Model.
A blog post with additional details is here:
http://www.openstack.org/blog/2011/03/openstack-governance-update/
Comments:
John
John Purrier
(206) 930-0788
x27;s for these services. We may also need to up-version these service
API's between Cactus and Diablo as they are currently under heavy discussion
and design.
John
From: Erik Carlin [mailto:erik.car...@rackspace.com]
Sent: Monday, February 28, 2011 3:16 PM
To: John Purrier; openstack
Has anyone done a gap analysis against the proposed OpenStack Compute API and
a) the implemented code, and b) the EC2 API?
It looks like we have had a breakdown in process, as the community review
process of the proposed spec has not generated discussion of the missing
aspects of the propose
Good work folks!
Do we understand what the dependencies/deltas are to support RHEL5 series
releases? Has anybody done this?
John
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
O
Sounds good.
John
-Original Message-
From: Eric Day [mailto:e...@oddments.org]
Sent: Thursday, February 24, 2011 6:17 PM
To: John Purrier
Cc: 'Devin Carlen'; 'Jay Pipes'; 'Josh Kearney'; so...@openstack.org; 'Andy
Smith'; openstack@lists.la
l Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
Of Devin Carlen
Sent: Thursday, February 24, 2011 4:34 PM
To: Jay Pipes
Cc: Josh Kearney; so...@openstack.org; Andy Smith;
openstack@lists.launchpad
ck-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
Of Jay Pipes
Sent: Thursday, February 24, 2011 12:20 PM
To: Eric Day
Cc: Josh Kearney; so...@openstack.org; Andy Smith;
openstack@lists.launchpad.net; John Purrier; Rick Cl
And we are back to the discussion about orchestration... Given the
flexibility of the OpenStack system and the goals of independently
horizontally scaling services I think we will need to address this head on.
#3 is the most difficult, but is also the right answer for the project as we
look forward
I agree, this is exactly where we want to take the network services for
OpenStack. The goal should be to decouple Compute from Network, with an eye
toward a project separation post-Cactus (this should have a lot of
discussion at the next design summit). For Cactus we have explicitly kept
the networ
I agree with this. Unless there are significant, obvious advantages to
Erlang I would suggest we stick with C/C++.
John
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf
Of Tim Bell
Bumping this to the top of the list. One of the key deliverables for Cactus
is a complete and usable OpenStack Compute API. This means that using only
the API and tools that interact with the OpenStack Compute API Nova can be
installed and configured; once running all of the Nova features and
funct
There are a lot of benefits to having an external system be responsible for
handling usage data from Nova, Swift, or other OpenStack services. I would
call out:
1. Simplification of code within each service. The collection and
publication of usage data is "dumb". store the service usage d
I think Glen is on the right track here. Having the account_ID be a string
with no connotation for Nova allows two benefits: 1) deployments can create
the arbitrary organizational models that fit their particular DC, physical,
and logical structures, and 2) the Nova code is simpler as the hierarchi
I would suggest that the theme(s) for the Cactus release be:
a. Deployability. This includes consistent packaging and deployment tools
support; but also includes good consistent documentation, approachability to
the project (how quickly can a novice get a running system going for proof
of concept)
.
We will target the Diablo design summit to discuss and review the progress made
on these services and determine if the best approach to the project has been
made.
Thoughts?
John
From: Andy Smith [mailto:andys...@gmail.com]
Sent: Friday, January 28, 2011 4:06 PM
To: John Purrier
Cc
ement code for this
milestone.
John
From: Andy Smith [mailto:andys...@gmail.com]
Sent: Friday, January 28, 2011 12:45 PM
To: John Purrier
Cc: Rick Clark; Jay Pipes; Ewan Mellor; Søren Hansen;
openstack@lists.launchpad.net
Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastru
+john=openstack@lists.launchpad.net] On Behalf
Of Thierry Carrez
Sent: Friday, January 28, 2011 1:52 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastructure
blueprint
John Purrier wrote:
> Here is the suggestion. It is clear from the response on
Some clarification and a suggestion regarding Nova and the two new proposed
services (Network/Volume).
To be clear, Nova today contains both volume and network services. We can
specify, attach, and manage block devices and also specify network related
items, such as IP assignment and VLAN crea
>From the Swift perspective, Ewan is correct... objects are objects. Glance
>associates meta-data with its objects to indicate they are virtual images.
John
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lis
This would make our API story cleaner (always a good thing).
We are likely to have similar discussions about volumes (block storage) and
network.
John
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.laun
Another thought, as we envision moving OpenStack forward we will likely be
including code and projects that are not written in Python. Being forward
looking should we structure openstack-common to segment along language lines?
John
-Original Message-
From: openstack-bounces+john=opensta
---
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, January 10, 2011 10:26 AM
To: John Purrier
Cc: Ewan Mellor; openstack@lists.launchpad.net
Subject: Re: [Openstack] Glance x-image-meta-type raw vs machine
And I think we need to come to an agreement on the terms used here...
What is a &
My 2 cents... We need to define a transport-neutral specification that allows
us to encapsulate and copy/move a variety of virtual image formats, this should
be based on OVF. The envelope can contain both the actual image as well as any
required meta-data.
The image elements specified are very
=openstack@lists.launchpad.net] On Behalf
Of Thierry Carrez
Sent: Tuesday, January 04, 2011 7:53 AM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] [RFC] OpenStack Programming Model Framework
John Dickinson wrote:
> On Jan 3, 2011, at 6:13 PM, John Purrier wrote:
>>
Good points, I just deleted my post as you made my points J.
The “devAPI” is valuable for developers/contributors to the OpenStack services
for all of the reasons Vishy stated in terms of immediacy, access, and easy
evolution. This should be internal to the project. Having a CLI to drive this
this real. This is a doc effort as well, as the tenor of the developers
documentation needs to be oriented to this approach.
Comments?
-John
John Purrier
(206) 930-0788 | <mailto:j...@openstack.org> j...@openstack.org
OpenID: http:// <http://john.purrier.com/> john.
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of
Jay Pipes
Sent: Friday, December 31, 2010 5:29 AM
To: Thierry Carrez
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [RFC] OpenStack API
On Fri, Dec 31, 2010 at 4:22 AM, Thierry Carrez wrote:
> John Purrier wr
in Cactus.
Thanks,
-John
From: Christopher MacGown [mailto:ign...@gmail.com]
Sent: Thursday, December 30, 2010 5:28 PM
To: John Purrier
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [RFC] OpenStack API
Hi guys,
It is clearly important to establish a viable OpenStack
Sounds like we need to update the blueprints for Bexar (quickly) to include
the OpenStack API 1.0 command line tools. I believe Sandy Walsh is working
on these.
Dendrobates/Pvo, can we *quickly* get an accurate status on the 1.0 API and
timing for Bexar?
Here is the minimal set of functionality w
I can create wiki pages, where should they live?
John
From: Andy Smith [mailto:andys...@gmail.com]
Sent: Thursday, December 30, 2010 3:20 PM
To: John Purrier
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] [RFC] OpenStack Scope and projects
I would quickly say this should
From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
Sent: Thursday, December 30, 2010 3:27 PM
To: John Purrier; openstack@lists.launchpad.net
Subject: RE: [Openstack] [RFC] OpenStack API
Thanks John. That's a good summary of the plan. I still have a few
questions, if you could
A discussion in order to set a common understanding of supported image
formats in OpenStack and how the project can approach the issues surrounding
various hypervisors, cross-cloud interoperability, and potentially setting
some necessary development work items. Once the community has reached
consen
The timing of this is interesting, as it comes when there is a lot of
discussion about EasyAPI. I would like to encourage discussions about the
EasyAPI extensibility mechanisms versus the OpenStack API v1.1 extension
mechanism. Jorge, you will need to let folks see the proposed updates to the
OpenS
I like Jay's approach, this gives us a view into the project as a whole
while maintain the bite sized merges that are digestible and less prone to
regressions or unintended side-effects.
-john
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openst
Yes, let's do the standard approach, no matter how easy!
-johnpur
-Original Message-
From: openstack-bounces+john=openstack@lists.launchpad.net
[mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of
Jay Pipes
Sent: Wednesday, December 08, 2010 10:42 AM
To: So
Is there any project to bring Beagle to Windows? Any interest in this?
-john
___
Dashboard-hackers mailing list
Dashboard-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/dashboard-hackers
75 matches
Mail list logo
