I'd like to point out a change I have waiting for reviews in Nova, in
case it has any impact: https://review.openstack.org/#change,2593
This is a user-launchable image that can connect from a VLAN to a
floating address as it is launched. It serves much the same function
as a cloudpipe, but can be
On Fri, Jan 6, 2012 at 5:26 AM, Mark McLoughlin wrote:
> Hi Todd,
>
> On Thu, 2012-01-05 at 18:29 -0500, Todd Willey wrote:
>> On Thu, Jan 5, 2012 at 5:19 PM, Mark McLoughlin wrote:
>> >
>> > The previous thread here that I contributed to felt a little like
>&
On Thu, Jan 5, 2012 at 5:19 PM, Mark McLoughlin wrote:
> Hi Mark,
>
> On Thu, 2012-01-05 at 15:16 -0500, m...@openstack.org wrote:
>> As Jim mentioned, I'm going to focus on establishing the foundation
>> this year and am really excited to be able to dedicate the time and
>> attention it deserves,
+1
On Tue, Nov 29, 2011 at 1:03 PM, Vishvananda Ishaya
wrote:
> Lorin has been a great contributor to Nova for a long time and has been
> participating heavily in reviews over the past couple of months. I think he
> would be a great addition to nova-core.
>
> Vish
> ___
Plus one
On Nov 9, 2011 9:25 AM, "Brian Waldon" wrote:
> I'd like to nominate Johannes for nova-core, as he has definitely been
> doing a good number of reviews lately.
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lis
This probably goes back to when there were problems with certain
kernels that would lock up when attaching volumes with virtio enabled.
There still may be issues with Windows images that don't have the
right drivers installed.
-todd[1]
On Thu, Oct 27, 2011 at 9:33 PM, Yun Mao wrote:
> Is there
Strictly speaking I think gerrit is the canonical one and github is a
mirror of that.
On Fri, Sep 23, 2011 at 1:53 PM, Lorin Hochstein wrote:
> Vish:
> The description at https://github.com/openstack/nova still says "GitHub
> Mirror of OpenStack Compute (Nova)". Is it now the case that the GitHub
One thing that might be added would be dynamic module and class
loading. This has implications for flags/options and help output as
well. It is something nova does, and I suspect keystone and others
will need to do as well.
On Mon, Jul 25, 2011 at 2:59 PM, Devin Carlen wrote:
> If by mini-proje
I think people will probably deploy in such a way that clients talk to
80 or 443. But there are a number of ways to get to that outcome,
including specifying it in the server configuration, or running behind
load balancers or other front-end services. Running everything be
default on different po
On Sat, Jun 25, 2011 at 11:47 AM, Jay Pipes wrote:
> On Fri, Jun 24, 2011 at 10:10 AM, Todd Willey wrote:
>> I'd prefer to keep it convenient to develop and demo on a single
>> machine. I don't think there is any added inconvenience during
>> deployment if the
I'd prefer to keep it convenient to develop and demo on a single
machine. I don't think there is any added inconvenience during
deployment if the ports are not the standard http ports.
On Fri, Jun 24, 2011 at 12:15 PM, Jay Pipes wrote:
> Hi!
>
> As I stated on our Skype chat about this the other
Needs
account_autocreate = true
in proxy-server.conf
I'm assuming your keystone baseURL points the public url of swift to
http://127.0.0.1:/v1/AUTH_%tennant_id%
I'm running trunk on swift and keystone w/o problems (though it was
broken for a bit on trunk keystone).
-todd[1]
On Tue, Jun 21
Agreed. Wholeheartedly.
On Wed, Jun 1, 2011 at 3:47 PM, Trey Morris wrote:
> I like vish's idea. instead of 999, maybe it should be anything over 9000.
> -tr3buchet
>
> On Wed, Jun 1, 2011 at 1:47 PM, Brian Schott wrote:
>>
>> That's not crazy, but I'd recommend a range of numbers 900-999? The
+1
On Tue, May 31, 2011 at 3:16 PM, Vishvananda Ishaya
wrote:
> While I was checking branch merges, I noticed that Brian Lamar (blamar), is
> not listed as a nova-core developer. This is most definitely a travesty, as
> he has been one of the most prolific coders/reviewers over the past few
>
I'm for zone-generated ids. If we take user input it is one more
thing to sanitize and scope accordingly. As the number is essentially
disposable, I don't know why they would care to provide one anyway, it
just seems like changing who is responsible for making a uuid.
On Tue, May 24, 2011 at 10:
Would adding new fields into a response bump the minor version number
and not the major? In that case, knowing the exact version would be
nice. In all honesty though, I'm for integer version numbers for APIs
anyway, so every set of changes bumps the revno, and you always have
good documentation s
Looks like the directories need to be named base 16. See
nova/images/local.py line 60 (in trunk).
On Mon, May 9, 2011 at 6:34 PM, Yang, Fred wrote:
> Hi,
>
>
>
> I am installing nova from the latest source trunk following
> http://wiki.openstack.org/InstallFromSource as a newbie and is having
>
I think we should finalize a plan for the forum before we start
changing IRC. I'd hate to become unresponsive on many fronts at once,
and I think growing just one of those communities will be hard enough.
On Tue, May 3, 2011 at 8:23 PM, Devin Carlen wrote:
> +1 to not splitting everything up.
>
On Tue, May 3, 2011 at 5:39 AM, Dirk-Willem van Gulik
wrote:
>
> On 3 May 2011, at 10:31, Soren Hansen wrote:
>
>> 2011/5/3 Todd Willey :
>>> In a heavily load-balanced environment you'll probably want to terminate
>>> SSL before it gets
>>> proxi
We should be able to do it with a wsgi middleware and either include
it or not in the paste config file. In a heavily load-balanced
environment you'll probably want to terminate SSL before it gets
proxied to the actual api servers, but it would be nice to support the
simple case where the api serv
I think between the list and the Launchpad Questions section we have
it covered. Maybe we could just make the Launchpad Questions section
mentioned more prevalently in docs?
-todd[1]
On Mon, May 2, 2011 at 4:12 PM, Jordan Rinke wrote:
> I had a number of discussions with various people at the s
On Wed, Mar 30, 2011 at 6:41 PM, Jay Pipes wrote:
> On Wed, Mar 30, 2011 at 6:17 PM, Todd Willey wrote:
>> On Wed, Mar 30, 2011 at 3:22 AM, Thierry Carrez
>> wrote:
>>> Todd Willey wrote:
>>>> Not all features take a long time to plan and implement.
On Wed, Mar 30, 2011 at 3:22 AM, Thierry Carrez wrote:
> Todd Willey wrote:
>> Not all features take a long time to plan and implement. Some are
>> quite tiny. Some are conceived and implemented near the end of the
>> release cycle. Size, scope, and timing can
On Tue, Mar 29, 2011 at 8:54 AM, Ewan Mellor wrote:
>> -Original Message-
>> From: Todd Willey [mailto:t...@ansolabs.com]
>> Sent: 29 March 2011 04:08
>> To: Ewan Mellor
>> Cc: Jay Pipes; openstack@lists.launchpad.net
>> Subject: Re: [Openstack] Featur
On Mon, Mar 28, 2011 at 7:42 PM, Ewan Mellor wrote:
>> -Original Message-
>> From: Todd Willey
>> Sent: 28 March 2011 21:11
>> To: Jay Pipes
>> Cc: openstack@lists.launchpad.net
>> Subject: Re: [Openstack] Feature Freeze status
>>
>> [Snip
On Mon, Mar 28, 2011 at 2:54 PM, Jay Pipes wrote:
> On Mon, Mar 28, 2011 at 2:32 PM, Todd Willey wrote:
>> Open == Accessible. Open != Verbose. I'm willing to discuss more at
>> the design summit, but my biggest concern is that we let the most
>> people possible can
Open == Accessible. Open != Verbose. I'm willing to discuss more at
the design summit, but my biggest concern is that we let the most
people possible can contribute. This includes those who work behind
closed doors on their own pet projects.
This thread started specifically in response to a few
With this switch to python, does it make sense to revisit the concept
of openstack-common for things like logging, flag parsing, etc? What
components would you like to just be able to drop in from nova,
glance, or swift?
-todd[1]
On Tue, Mar 8, 2011 at 4:05 PM, Eric Day wrote:
> Hi everyone,
>
I like prefixed names that are grouped in with user metadata.
On Wed, Mar 2, 2011 at 1:30 PM, Eric Day wrote:
> On Wed, Mar 02, 2011 at 01:31:27PM -0500, Brian Lamar wrote:
>> Wait, are we all in agreement that we need user-defined metadata and
>> service-specific metadata? I do agree that the d
I'd like to go on record as saying that anything related to nova or
openstack that doesn't allow you to configure which public API you're
consuming shouldn't bear the name nova or openstack. If you look at
http://nova.openstack.org/ you see "API Compatibility" in bold as one
of our design guidelin
The separation of flag definitions into the modules that consume them
is a good practice, IMO. This is especially true with a system as
configurable/pluggable as nova, as you don't want flags for unused
modules polluting your help output, etc. It also goes most of the way
into creating the logica
Ditto erl > cpp.
On Tue, Feb 22, 2011 at 3:57 AM, Vishvananda Ishaya
wrote:
> +1 for Erlang from me. I'm hoping to never have to see C++ templates again :)
>
> On Feb 21, 2011, at 10:58 PM, Devin Carlen wrote:
>
>> It's been discussed a fair amount already, but I think this is a good list
>> of
Good points Ken. I think we should leave the nova-core as the default
selection. This lets those go to the nova-core mailing list, and sets
it up so someone/anyone can add reviewers as those requests come in.
I just tried out the "Claim Review" button on a merge proposal. It
looks like using it
33 matches
Mail list logo
