Trey Morris wrote:
> I don't like that it currently only runs on ubuntu + the ppa. If it
> doesn't work with existing versions I think we're doing something wrong.
> Even when natty comes out, I don't like the idea of having to ensure I
> have latest ubuntu for openstack to run.
Maybe with my Ubun
Duck farm? :)
Are you two concerned about building a developer community around a
project in Erlang? I'm all for going that route if other folks are
comfortable with it.
I also have some concern around the speed of Erlang. It's great,
especially if you know what primitives can be expensive and ho
Soren, thank you for the explanation!
Jim
On Feb 17, 2011, at 5:11 PM, Soren Hansen wrote:
> 2011/2/17 Jim Curry :
>> By defining an unbreakable reference platform, are we necessarily limiting
>> its ability to integrate on other platforms? That is my underlying
>> question. I understand the
Sorry, I don't view the proposed changes from AMQP to REST as being
"customer facing API changes". Could you explain? These are internal
interfaces, no?
-jay
On Thu, Feb 17, 2011 at 8:13 PM, Justin Santa Barbara
wrote:
> An API is for life, not just for Cactus.
> I agree that stability is import
On Feb 17, 2011, at 5:55 PM, Soren Hansen wrote:
> 2011/2/17 Lorin Hochstein :
>> For those who deploy on platforms other than Ubuntu, are these
>> customizations recorded somewhere in the OpenStack documentation?
>
> Hmm.. No. I submitted it upstream, applied it in Ubuntu, and uploaded
> backpo
An API is for life, not just for Cactus.
I agree that stability is important. I don't see how we can claim to
deliver 'stability' when the plan is then immediately to destablize
everything with a very disruptive change soon after, including customer
facing API changes and massive internal re-arch
On Thu, Feb 17, 2011 at 6:57 PM, Justin Santa Barbara
wrote:
> Pulling volumes & images out into separate services (and moving from AMQP to
> REST) sounds like a huge breaking change, so if that is indeed the plan,
> let's do that asap (i.e. Cactus).
Sorry, I have to disagree with you here, Justi
Agreed. I don't think bleeding-edge pip should block a merge either. It could
cause a lot of false-positives.
I do think up-to-date Natty, Maverick, and Lucid with build-depends from PPA
should be tested, probably CentOS and SUSE if that can be automated. You want
apt-get dist-upgrade ; run_
Pulling volumes & images out into separate services (and moving from AMQP to
REST) sounds like a huge breaking change, so if that is indeed the plan,
let's do that asap (i.e. Cactus).
On Thu, Feb 17, 2011 at 3:44 PM, Paul Voccio wrote:
> I wanted to put out into the open where we think the ev
Believe, me we know. Our team is bringing up OpenStack on our heterogeneous
testbed, a 1TB 256core SGI UltraViolet machine, three Nvidia S2050 boards
connected to three SGI XE500 boxes (exposing the GPUs to new instance types
using a modified gVirtuS driver), and a nova-compute proxy managing 1
I wanted to put out into the open where we think the evolution of the apis will
go over the next few releases. This is by no means the only way to do this, but
I thought it would be a start of conversation.
http://wiki.openstack.org/api_transition
I also wanted to clear up some confusion that I
2011/2/17 Jim Curry :
> By defining an unbreakable reference platform, are we necessarily limiting
> its ability to integrate on other platforms? That is my underlying question.
> I understand the need for a reference platform but am trying to understand
> to what extent that results in us not
Hi Dan! Sorry you were the last of my reply emails on this thread.
Email overload today :) Comments inline.
On Thu, Feb 17, 2011 at 9:43 AM, Dan Prince wrote:
> I see the 'smoketests' directory in the nova code. Is anyone running these
> tests on a regular basis (every commit)? Is this the best
2011/2/17 Lorin Hochstein :
> For those who deploy on platforms other than Ubuntu, are these
> customizations recorded somewhere in the OpenStack documentation?
Hmm.. No. I submitted it upstream, applied it in Ubuntu, and uploaded
backported packages to the PPA's. I guess we could also add a patch
By defining an unbreakable reference platform, are we necessarily limiting its
ability to integrate on other platforms? That is my underlying question. I
understand the need for a reference platform but am trying to understand to
what extent that results in us not being able to easily support
2011/2/17 Jim Curry :
> Got it. But the primary tradeoff is simply that we need to make sure any
> changes we make to another platforms don't break the Ubuntu integration? And
> in general that should not be a major issue...?
I don't think I understand the question, I'm afraid. :( From where I
I'll put in a +1 for Erlang as an OpenStack supported platform. We'd be able
to write a stable queue with a much more concise code base, and this is project
would be a great fit for Erlang.
Devin
On Feb 17, 2011, at 2:21 PM, Eric Day wrote:
> Thanks to everyone who gave great feedback on the
Thanks to everyone who gave great feedback on the first queue service
thread. I've updated the wiki page to include the suggestions.
http://wiki.openstack.org/QueueService
With a decent vision of what we want to build, the next step is
figuring out how. In a previous thread it was suggested that
Got it. But the primary tradeoff is simply that we need to make sure any
changes we make to another platforms don't break the Ubuntu integration? And
in general that should not be a major issue...?
Jim
On Feb 17, 2011, at 1:32 PM, Soren Hansen wrote:
> 2011/2/17 Jim Curry :
>> Soren, can you
On Feb 17, 2011, at 4:21 PM, Soren Hansen wrote:
>
> I understand the motivation, I'm just not sure I want the latter to
> actually block a merge. As an example, the recent race condition I
> spotted and fixed required a patch to land in eventlet. If the latter
> was allowed to block a merge, we'
+1! (Yup, that was +factorial(1), for those keeping score at home)
2011/2/17 Sandy Walsh :
> I'd like to help out on the review process as
> per http://wiki.openstack.org/Governance/Approved/CoreDevProcess
> I like quiet walks in the park and black and white movies.
> -Sandy
>
> Confidentiality No
2011/2/17 Jay Pipes :
>> One thing we saw in the list and experienced first hand is that your Hudson
>> server uses a pre-configured environment and ours pulls virtual env every
>> time. We had failures on trunk that yours missed because of new pip pulled
>> versions.
>>
>> A fresh run_tests.sh
+1, this is a great suggestion.
On Feb 17, 2011, at 1:06 PM, Jay Pipes wrote:
> Although Soren adequately explained why he thinks that running
> run_tests.sh on Hudson should *not* be against a pip/virtualenv setup,
> I would like to state that I think it would be a good idea to have
> Hudson d
Great thoughts Jay - I think a push to improve test coverage is a great goal
for Cactus.
It seems like we are getting new contributors faster than ever these days. I
would like to suggest that we create a blueprint called something like "improve
test coverage" and create a number of bug repo
On Thu, Feb 17, 2011 at 12:53 AM, Brian Schott wrote:
> One thing we saw in the list and experienced first hand is that your Hudson
> server uses a pre-configured environment and ours pulls virtual env every
> time. We had failures on trunk that yours missed because of new pip pulled
> version
No disagreement with anything you say below, Matt. More testing of all
kinds, including unit tests, should be a priority.
Cheers,
jay
On Wed, Feb 16, 2011 at 11:37 PM, Matt Dietz wrote:
> These are all great points Jay.
>
> I'd like to re-echo the comment about unit tests. Obviously they aren't
On Wed, Feb 16, 2011 at 11:44 PM, Paul Voccio wrote:
> Jay,
>
> Thanks for throwing this out. How would we build this with Hudson? What
> would a "standard deploy" of Nova even look like for integration tests?
I replied with some specifics to Trey, who had a similar question, and
created a bug re
Devs:
The time to decide on GSOC is fast approaching. As I indicated earlier this
month, we will decide to proceed based on the projects developers would like to
submit. As of today, there are no project submissions at the Wiki page at
http://wiki.openstack.org/Project%20List. The schedule cal
I would agree with Devin. Monsyne, I'd like to see some of your
reviews before I give a thumbs up to nova-core. Please do participate
in the review process so we've got a bit more to base a decision on.
:) Of course, I may just be missing reviews you have done? If so,
please don't hesitate to corre
On Thu, Feb 17, 2011 at 11:32 AM, Josh Kearney
wrote:
> I'd like to volunteer my time to help out with reviews in Nova by becoming a
> member of Nova-Core.
+1 from me.
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lis
On Thu, Feb 17, 2011 at 1:58 PM, Trey Morris wrote:
> sounds like a good plan to me :)
Awesome. I'm glad you're taking the lead on this ;)
https://bugs.launchpad.net/nova/+bug/720941
Cheers!
jay
___
Mailing list: https://launchpad.net/~openstack
Post
+1!
On Feb 17, 2011, at 8:25 AM, Sandy Walsh wrote:
> I'd like to help out on the review process as per
> http://wiki.openstack.org/Governance/Approved/CoreDevProcess
>
> I like quiet walks in the park and black and white movies.
>
> -Sandy
>
> Confidentiality Notice: This e-mail message (in
I think the best way to get involved is to just start doing reviews.
A branch still requires 2 core reviews to be merged, but that doesn't mean
other people can't jump in and give their 2 cents in the meantime. So just
dive on in and you can start learning about the review process and helping o
+1 :-D
From: Josh Kearney
mailto:josh.kear...@rackspace.com>>
Date: Thu, 17 Feb 2011 10:32:04 -0600
To: mailto:openstack@lists.launchpad.net>>
Subject: [Openstack] Proposal to be a member of Nova Core
I'd like to volunteer my time to help out with reviews in Nova by becoming a
member of Nova-Co
+1 for sure.
2011/2/17 Josh Kearney :
> I'd like to volunteer my time to help out with reviews in Nova by becoming a
> member of Nova-Core.
> -Josh Kearney
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.n
2011/2/17 Jim Curry :
> Soren, can you clarify what you mean by Ubuntu being the primary platform?
> Why is that the reference? What limitations does this introduce?
It's the primary platform because it's the platform we test everything
on, it's the platform we spend time integrating with, etc.
One other thing I forgot to point out is that there's a world outside
of Python, too. You can pull all the stuff you want from pip, but
there's still a whole bunch of things that aren't managed by pip that
you need to rely on your distro for anyways. Like, say, a kernel,
Python itself, libvirt, isc
2011/2/17 Jay Pipes :
> Also, good point to keep in mind: Membership to nova-core isn't a
> privilege or even any fun. It's a responsibility and a duty to your
> fellow contributors :)
The first draft of my e-mail said something about it being a chore,
but I decided to edit that out to not demotiv
sounds like a good plan to me :)
On Thu, Feb 17, 2011 at 11:44 AM, Jay Pipes wrote:
> On Thu, Feb 17, 2011 at 12:19 PM, Trey Morris
> wrote:
> > I don't like that it currently only runs on ubuntu + the ppa. If it
> doesn't
> > work with existing versions I think we're doing something wrong. Eve
+1 for jk0
Jay Pipes wrote:
>On Thu, Feb 17, 2011 at 1:25 PM, Vishvananda Ishaya
> wrote:
>> +1
>> Jk0 has been contributing a lot and doing reviews even when they don't
>> "count".
>
>All reviews count :)
>
>-jay
>
>___
>Mailing list: https://launchp
On Thu, Feb 17, 2011 at 1:25 PM, Vishvananda Ishaya
wrote:
> +1
> Jk0 has been contributing a lot and doing reviews even when they don't
> "count".
All reviews count :)
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@li
+1
Jk0 has been contributing a lot and doing reviews even when they don't
"count".
On Feb 17, 2011 8:33 AM, "Josh Kearney" wrote:
> I'd like to volunteer my time to help out with reviews in Nova by becoming
a
> member of Nova-Core.
>
> -Josh Kearney
___
On Thu, Feb 17, 2011 at 1:14 PM, Joshua McKenty wrote:
> Paul, I would add that I think typical etiquette would be for someone on
> nova-core to ping the team member in question (off-list if possible) and
> check in on whether they can stay committed to their participation, whether
> they're on
On Thu, Feb 17, 2011 at 12:19 PM, Trey Morris wrote:
> I don't like that it currently only runs on ubuntu + the ppa. If it doesn't
> work with existing versions I think we're doing something wrong. Even when
> natty comes out, I don't like the idea of having to ensure I have latest
> ubuntu for op
I don't like that it currently only runs on ubuntu + the ppa. If it doesn't
work with existing versions I think we're doing something wrong. Even when
natty comes out, I don't like the idea of having to ensure I have latest
ubuntu for openstack to run.
As far as stability goes, i think integration
Soren, can you clarify what you mean by Ubuntu being the primary platform? Why
is that the reference? What limitations does this introduce?
Jim
On Feb 17, 2011, at 4:31 AM, Soren Hansen wrote:
> 2011/2/17 Brian Schott :
>> One thing we saw in the list and experienced first hand is that your H
"Also, good point to keep in mind: Membership to nova-core isn't a
privilege or even any fun. It's a responsibility and a duty to your
fellow contributors :)"
well said!
On Thu, Feb 17, 2011 at 9:59 AM, Jay Pipes wrote:
> On Thu, Feb 17, 2011 at 9:26 AM, Thierry Carrez
> wrote:
> > That said t
On Thu, Feb 17, 2011 at 11:25 AM, Sandy Walsh wrote:
> I'd like to help out on the review process as
> per http://wiki.openstack.org/Governance/Approved/CoreDevProcess
+1 from me.
> I like quiet walks in the park and black and white movies.
/me nominates you for core-dev at eHarmony.com :P
> -
I'd like to volunteer my time to help out with reviews in Nova by becoming a
member of Nova-Core.
-Josh Kearney
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
I'd like to help out on the review process as per
http://wiki.openstack.org/Governance/Approved/CoreDevProcess
I like quiet walks in the park and black and white movies.
-Sandy
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclu
Reposting this in a separate thread as requested by Thierry.
I'm volunteering to do code reviews/ other core-dev duties, so we can
get some of our review logjam through.
--
--
-Monsyne Dragon
work: 210-312-4190
mobile210-441-0965
google voice: 210-338-0336
C
Josh Kearney wrote:
> I'm with Sandy on this. I'd like to step in as well.
Could you each start a new thread about your application ? That should
make it easier to track the lazy consensus described in:
http://wiki.openstack.org/Governance/Approved/CoreDevProcess
--
Thierry Carrez (ttx)
Release
I'm with Sandy on this. I'd like to step in as well.
On Thu, Feb 17, 2011 at 8:57 AM, Sandy Walsh wrote:
> I'll throw my hat in the ring for core if deemed worthy.
>
> Soren's point about 1 review day per # core developers was refreshing. I
> had previously held back from applying because I was a
On Wed, Feb 16, 2011 at 9:53 PM, Paul Voccio wrote:
> Not sure what the etiquette is for removing someone. Michael Gundlach is
> still listed but is no longer participating.
I think these sorts of things can be resolved on the mailing list just
fine. It's not a big deal for a developer to leave n
On Thu, Feb 17, 2011 at 9:26 AM, Thierry Carrez wrote:
> That said that shouldn't prevent anyone from also reviewing stuff that
> they care about any day.
This is EXTREMELY important. Remember that anyone can (and is
encourage to) review anyone else's branches. IMHO, the best way to
"get into nov
On 2/16/11 6:28 PM, Paul Voccio wrote:
Have we considered pruning and expanding the core team to help speed the
reviews along? There are some people who are no longer day-to-day active
in Nova and some that are that could help in this process.
I'd be willing to make time for code reviews, if it
On Thu, Feb 17, 2011 at 9:51 AM, Ed Leafe wrote:
> On Feb 17, 2011, at 4:18 AM, Soren Hansen wrote:
>
>> That's really a corollary to this proposal: Being in nova-core means you have
>> a review day once every N days (where N is the amount of (human) members of
>> nova-core). As such, if you're no
I'll throw my hat in the ring for core if deemed worthy.
Soren's point about 1 review day per # core developers was refreshing. I had
previously held back from applying because I was afraid all my time would be
tied up with reviews.
?
From: openstack-
On Feb 17, 2011, at 4:18 AM, Soren Hansen wrote:
> That's really a corollary to this proposal: Being in nova-core means you have
> a review day once every N days (where N is the amount of (human) members of
> nova-core). As such, if you're not prepared to accept such a review day, you
> don't get
Hey Jay,
I like what you propose here. I have a couple of comments and questions.
I see the 'smoketests' directory in the nova code. Is anyone running these
tests on a regular basis (every commit)? Is this the best place to further
build out integration tests?
---
Regarding environment/setup
Soren Hansen wrote:
> That's really a corollary to this proposal: Being in nova-core means you have
> a review day once every N days (where N is the amount of (human) members of
> nova-core). As such, if you're not prepared to accept such a review day, you
> don't get to be part of the team. Simple
Romain,
Please call me hisaharu :)
I have read your proposal and felt the below point is important.
> - create_network(address_prefix): network_id
> This cannot be part of the API because it violates criterion 4): a
> network service plugin may not support NATted IPv4 networks, for in
2011/2/17 Brian Schott :
> One thing we saw in the list and experienced first hand is that your Hudson
> server uses a pre-configured environment and ours pulls virtual env every
> time. We had failures on trunk that yours missed because of new pip pulled
> versions.
> A fresh run_tests.sh -f
2011/2/17 Paul Voccio :
> Have we considered pruning and expanding the core team to help speed the
> reviews along? There are some people who are no longer day-to-day active
> in Nova and some that are that could help in this process.
That's really a corollary to this proposal: Being in nova-core
2011/2/16 Eric Day :
> On Wed, Feb 16, 2011 at 11:20:31PM +0100, Soren Hansen wrote:
>> 2011/2/16 Sandy Walsh :
>> >> Hmmm... I am not sure about exposing internal structure to customers in
>> >> this
>> >> way. Would you really want the more 'internal' zones exposed?
>> > To Jay's point, the "co
Hey Ahmed,
TL;DR Glance doesn't appear to be supported with libvirt driver yet.
Judging by the stack trace, it looks like the code is taking an S3 code path
even though you've selected the GlanceImageService.
Looking through the code, it doesn't appear that the libvirt/Glance code is
there ye
Ahmed El Gamil wrote:
> (nova.compute.manager): TRACE: Error: Unexpected error while running
> command.
> (nova.compute.manager): TRACE: Command: /usr/bin/curl --fail
> --silent http://:/_images/2/image -H 'Date: Wed, 16
> Feb 2011 14:23:23 GMT' -H 'Authorization: AWS
>
67 matches
Mail list logo
