Excerpts from Adrian Otto's message of 2013-07-23 21:22:14 -0700:
Clint,
On Jul 23, 2013, at 10:03 AM, Clint Byrum cl...@fewbar.com
wrote:
Excerpts from Steve Baker's message of 2013-07-22 21:43:05 -0700:
On 07/23/2013 10:46 AM, Angus Salkeld wrote:
On 22/07/13 16:52 +0200, Bartosz
Hi,
Referring to https://bugs.launchpad.net/nova/+bug/1202136, it seems that the
novaclient
validates the flavor ID to be either an integer or a UUID string. This check
does not exist in Nova, so currently strings
are also accepted as flavor IDs by Nova when direct restful API calls are made.
Hi folks,
We decided to use openstack-dev@lists.openstack.org mailing list instead of
savanna-...@lists.launchpad.net for all savanna-related communication. The old
one will be closed and we’ll monitor it and forward all emails from it to the
correct mailing list. Additionally it means that
Hi Alex,
I'm inclined to agree with others that I'm not sure you need the complexity
that this BP brings to the system.If you want to provide a user with a
choice about how much overcommit they will be exposed to then doing that in
flavours and the aggregate_instance_extra_spec filter
Clay, It sounds like a bad idea to remove delay_denial support (at least in
the near term).
Authorizing up front seem to have certain advantages:
1. Flexibility - as it allows authenticating based on any attribute
returned from the get_info() (without changes to Swift).
2. Security - a single
It seems KMIP is getting lots of enterprise attention, so I think it may
be good candidate for future (as you already mentioned in your email
below) Barbican feature, as per the link below it seems our community
also expects KMIP to be integrated with OpenStack line of products.
· Agreed that there isn¹t an existing KMIP client in python. We are
offering to port the needed functionality from our current java KMIP
client to python and contribute it to openstack.
Are you taking about porting to Python or having python call a Java
wrapper?
· Good points about the common
I think we should transfer this discussion to the etherpad for this blueprint:
https://etherpad.openstack.org/api_policy_on_target
I have summarised the views of this thread there already, so let's make any
further comments there, rather than here.
Henry
On 24 Jul 2013, at 00:29, Simo Sorce
Shawn, or others involved in this effort,
Is there a quick README or equivalent on how to use the latest code
say with devstack and vCenter to get a simple deploy working?
thanks,
-- dims
On Mon, Jul 22, 2013 at 9:15 PM, Shawn Hartsock hartso...@vmware.com wrote:
** No meeting this week **
On 07/24/2013 08:51 AM, Stefano Maffulli wrote:
Hello
I have seen lots of discussions on blogs and twitter heating up around
Amazon API compatibility and OpenStack. This seems like a recurring
topic, often raised by pundits and recently joined by members of the
community. I think it's
On 07/23/2013 03:02 PM, Brian Curtin wrote:
On Jul 23, 2013, at 3:51 PM, Eric Windisch e...@cloudscaling.com
mailto:e...@cloudscaling.com
wrote:
On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton lo...@bacoosta.com
mailto:lo...@bacoosta.com wrote:
I'm sure this has been asked
On 07/24/2013 05:39 AM, Day, Phil wrote:
Hi Alex,
I'm inclined to agree with others that I'm not sure you need the complexity
that this BP brings to the system.If you want to provide a user with a
choice about how much overcommit they will be exposed to then doing that in
flavours
On 07/24/2013 11:57 AM, Monty Taylor wrote:
On 07/24/2013 08:51 AM, Stefano Maffulli wrote:
Hello
I have seen lots of discussions on blogs and twitter heating up around
Amazon API compatibility and OpenStack. This seems like a recurring
topic, often raised by pundits and recently joined
Hi Oslos,
I have a refactoring for common code needed to implement REST API
translations.
The change is a bit of a blocker for multiple other changes across
various components, and would just like to see if it could get bumped up
a bit in your review queues.
On 07/23/2013 06:00 PM, Clint Byrum wrote:
This is really interesting work, thanks for sharing it with us. The
discussion that has followed has brought up some thoughts I've had for
a while about this choke point in what is supposed to be an extremely
scalable cloud platform (OpenStack).
I
Welcome Ben and Julien!
On Wed, Jul 24, 2013 at 11:42 AM, Mark McLoughlin mar...@redhat.com wrote:
Hey
I just wanted to welcome Ben and Julien to oslo-core. They have both
been doing a lot of high quality reviews lately and it's much
appreciated.
Welcome to the team!
Cheers,
Mark.
If you are a developer using devstack, see:
https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide
If you are a user deploying from packages, see:
http://docs.openstack.org/trunk/openstack-compute/admin/content/vmware.html
Dan
On Wed, Jul 24, 2013 at 8:22 AM, Davanum Srinivas
First off, welcome! :)
FYI, this is the development mailing list. Questions like the one below
may find more helpful answers on the general OpenStack users' mailing list.
I have CC'd that list so that this response can be seen there, too, I suggest
you re-send your original message there as well.
I am trying to put everything here for now:
https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide
Let me know if you need more.
# Shawn Hartsock
Davanum Srinivas dava...@gmail.com wrote:
Shawn, or others involved in this effort,
Is there a quick README or equivalent on how to use the
Thanks Dan and Shawn. Those links are exactly what i was needed.
-- dims
On Wed, Jul 24, 2013 at 1:10 PM, Shawn Hartsock hartso...@vmware.com wrote:
I am trying to put everything here for now:
https://wiki.openstack.org/wiki/NovaVMware/DeveloperGuide
Let me know if you need more.
# Shawn
On Wed, 2013-07-24 at 09:31 -0700, Alex Gaynor wrote:
I believe Red Hat's new Software Collections things address this issue,
this is to the point which Django (which has historically used RHEL as a
barometer for when we could drop Pythons) will drop 2.6 in our next release.
Yep, that's a very
On Wed, 2013-07-24 at 08:51 -0700, Stefano Maffulli wrote:
Hello
I have seen lots of discussions on blogs and twitter heating up around
Amazon API compatibility and OpenStack. This seems like a recurring
topic, often raised by pundits and recently joined by members of the
community. I think
On Wed, Jul 24, 2013 at 8:51 AM, Stefano Maffulli stef...@openstack.org wrote:
Do you think OpenStack should have an ongoing effort to imitate Amazon's
API? If you think it should, how would you lead the effort?
We (Swift) moved the S3 compatibiliy middleware out of core swift for
quite some in
On 07/24/2013 01:43 PM, Mark McLoughlin wrote:
On Wed, 2013-07-24 at 08:51 -0700, Stefano Maffulli wrote:
Hello
I have seen lots of discussions on blogs and twitter heating up around
Amazon API compatibility and OpenStack. This seems like a recurring
topic, often raised by pundits and recently
Hi,
The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test
suites in the Openstack project is quite extensive. This is probably due to
the fact that it is the most familiar mocking object framework for most
python developers.
However there is big drawback with using mox across
On Jul 23, 2013, at 4:32 PM, Doug Hellmann
doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote:
On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton
lo...@bacoosta.commailto:lo...@bacoosta.com wrote:
I'm sure this has been asked before, but what exactly is the plan for Python
I think moving towards mock is a better long term strategy:
a) I don't you're correct that it's the most familiar for most python
developers. By PyPi installs (A TERRIBLE METRIC, but it's all we have).
Mock has 24k in the last week, mox has 3.5k
b) mock is a part of the standard library starting
On 07/24/2013 02:19 PM, Alex Gaynor wrote:
I think moving towards mock is a better long term strategy:
a) I don't you're correct that it's the most familiar for most python
developers. By PyPi installs (A TERRIBLE METRIC, but it's all we have).
Mock has 24k in the last week, mox has 3.5k
b)
Speaking of preferred ways to port, has there been any discussion about
which version takes precedence when we have to do different things? For
example, with imports, should we be trying the 2.x name first and falling
back to 3.x on ImportError, or vice versa?
Are we having it now? My belief
On Wed, 2013-07-24 at 14:12 -0400, Chuck Short wrote:
1. Change mox usage to more python3 friendly such as mock.
(https://pypi.python.org/pypi/mock/1.0.1). However this will cause
alot of code churn in the projects as we move away from mox to mock.
2. Use the python3 fork called pymox
+1 I prefer mock over mox as well. It's more readable and intuitive. I've had a
number of bad mox experiences lately so I'm a tad biased.
-Alex
-Original Message-
From: Jay Pipes jaypi...@gmail.com
Sent: Wednesday, July 24, 2013 2:24pm
To: openstack-dev@lists.openstack.org
Subject: Re:
On Jul 24, 2013, at 1:12 PM, Chuck Short
chuck.sh...@canonical.commailto:chuck.sh...@canonical.com
wrote:
Hi,
The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test suites
in the Openstack project is quite extensive. This is probably due to the fact
that it is the most
On Jul 24, 2013, at 1:27 PM, Eric Windisch
e...@cloudscaling.commailto:e...@cloudscaling.com
wrote:
Speaking of preferred ways to port, has there been any discussion about which
version takes precedence when we have to do different things? For example, with
imports, should we be trying the
On Wed, Jul 24, 2013 at 12:24 PM, Russell Bryant rbry...@redhat.com wrote:
On 07/23/2013 06:00 PM, Clint Byrum wrote:
This is really interesting work, thanks for sharing it with us. The
discussion that has followed has brought up some thoughts I've had for
a while about this choke point in
On 07/24/2013 02:32 PM, Kevin L. Mitchell wrote:
On Wed, 2013-07-24 at 14:12 -0400, Chuck Short wrote:
1. Change mox usage to more python3 friendly such as mock.
(https://pypi.python.org/pypi/mock/1.0.1). However this will cause
alot of code churn in the projects as we move away from mox to
+1 to everything Russell just said and of course Blueprints for this. One for
#3 (changing from mox - Mock) would be good so that anyone who is bored or
finds this urgent can collaborate. Also, we need to make sure reviewers are
aware (Hopefully they are reading this).
-Alex
-Original
On 07/23/2013 03:56 PM, David Chadwick wrote:
On 23/07/2013 18:36, Adam Young wrote:
On 07/23/2013 01:17 PM, David Chadwick wrote:
Of course the tricky thing is knowing which object attributes to fetch
for which user API requests. In the general case you cannot assume
that Keystone knows the
On Thu, 18 Jul 2013 12:31:02 -0500
Chuck Thier cth...@gmail.com wrote:
I'm with Chmouel though. It seems to me that EC policy should be chosen by
the provider and not the client. For public storage clouds, I don't think
you can make the assumption that all users/clients will understand the
The Ceilometer project team holds a meeting in #openstack-meeting, see
https://wiki.openstack.org/wiki/Meetings/MeteringAgenda for more details.
Next meeting is on Thu Jul 25th at 1500 UTC
Please add your name with the agenda item, so we know who to call on during
the meeting.
* Action from
Program Name: OpenStack Documentation
PTL: Anne Gentle
Mission Statement: Provide documentation for core OpenStack projects to
promote OpenStack. Develop and maintain tools and processes to ensure
quality, accurate documentation. Treat documentation like OpenStack code.
Details: Documentation is
On Wed, Jul 24, 2013 at 12:42 AM, Samuel Bercovici samu...@radware.comwrote:
Hi,
** **
This might be apparent but not to me.
Can you point to how broadcast can be turned on a network/port?
There is currently no way to prevent it so it's on by default.
** **
As for
+1 to removing the suders rules we have, there adding overhead and
contain enough wildcards that all they do is give people a false sense
of security
On 23/07/13 17:39, Chris Jones wrote:
Hi
On 23 July 2013 10:52, Robert Collins robe...@robertcollins.net
mailto:robe...@robertcollins.net
Day, Phil philip@hp.com wrote on 24/07/2013 12:39:16 PM:
If you want to provide a user with a choice about how much overcommit
they will be exposed to then doing that in flavours and the
aggregate_instance_extra_spec filter seems the more natural way to
do this, since presumably you'd
As far as the send only when you have to. That reminds me of this piece of work
that could be resurrected that slowed down the periodic updates when nothing
was changing.
https://review.openstack.org/#/c/26291/
Could be brought back, the concept still feels useful imho. But maybe not to
Russell Bryant rbry...@redhat.com wrote on 24/07/2013 07:14:27 PM:
I really like your point about not needing to set things up via a config
file. That's fairly limiting since you can't change it on the fly via
the API.
True. As I pointed out in another response, the ultimate goal would be
Roman,
Thank you for your comment. I agree that is should not be the only way to
look at the statistics and that is why Stackalytics also measures the
number of contributions and soon will add the number of reviews. I do,
however, think it a useful statistic as because not all commits are created
I think its still useful to have both, although I have a feeling that
something like the 'AWSOME' conversion layer from EC2 might still be a
pretty useful project to have to allow for a robust EC2 api which has a
dedicated group of people to support it. Never was quite sure what
happened to that
Hi Armando,
That happens from time to time.
Thanks,
Eugene.
On Thu, Jul 25, 2013 at 5:22 AM, Jian Wen jian@canonical.com wrote:
Hello,
I had trouble with run-tests.sh.
`tox -epy27` works.
On Fri, Jun 21, 2013 at 12:32 AM, Armando Migliaccio
amigliac...@nicira.com wrote:
Folks,
On 07/23/2013 12:32 PM, Sergey Lukjanov wrote:
Hi evereyone,
We’ve started working on upgrading Savanna architecture in version
0.3 to make it horizontally scalable.
The most part of information is in the wiki page -
https://wiki.openstack.org/wiki/Savanna/NextGenArchitecture.
Additionally
I would personally like it off, since it appears to me to offer a false sense
of security for the reasons mentioned in that review (doesn't stop DOS, doesn't
work across processes/API nodes).
Even though, I would recommend/think before its turned off that there should be
a detailed document on
50 matches
Mail list logo
