What I see in this conversation is that we are talking about multiple different
user classes.
Infra-operator needs as much info as possible, so if it is a vendor driver that
is erring out, the dev-ops can see it in the log.
Tenant-operator is a totally different class of user. These guys need
I’ve prepared a copy of nova.objects as oslo_versionedobjects in
https://github.com/dhellmann/oslo.versionedobjects-import. The script to create
the repository is part of the update to the spec in
https://review.openstack.org/15.
Please look over the code so you are familiar with it. Dan
On 30/01/15 02:19, Thomas Spatzier wrote:
From: Zane Bitter zbit...@redhat.com
To: openstack Development Mailing List
openstack-dev@lists.openstack.org
Date: 29/01/2015 17:47
Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in
Heat
I got a question today about creating
Hi Pratik,
what would be the aim for this templating? I ask since we in Heat try to
keep the imperative logic like e.g. if-else out of heat templates, leaving
it to other services. Plus there is already a spec for a heat template
function to repeat pieces of template structure [1].
I can
On 2015-02-02 23:29:55 +0300 (+0300), Alexandre Levine wrote:
I'll do that when I've got myself acquainted with the weekly meetings
procedure (haven't actually bumped into it before) :)
[...]
Start from the https://wiki.openstack.org/wiki/Meetings page
preamble and follow the instructions
Thank you for the heads up.
—Morgan
--
Morgan Fainberg
On February 2, 2015 at 1:15:49 PM, Kurt Taylor (kurt.r.tay...@gmail.com) wrote:
Just FYI, in case there was any questions,
In addition to testing and reporting on Nova, the IBM PowerKVM CI system is now
also testing against Keystone
On Mon, Feb 2, 2015, at 04:33 PM, Doug Hellmann wrote:
I’ve prepared a copy of nova.objects as oslo_versionedobjects in
https://github.com/dhellmann/oslo.versionedobjects-import. The script to
create the repository is part of the update to the spec in
https://review.openstack.org/15.
On 2 February 2015 at 16:29, Sean Dague s...@dague.net wrote:
It's really easy to say someone should do this, but the problem is
that none of the core team is interested, neither is anyone else. Most
of the people that once were interested have left being active in
OpenStack.
EC2
Hi folks:
I've updated the schedule for the Trove Mid-Cycle Sprint at
https://wiki.openstack.org/wiki/Sprints/TroveKiloSprint#Schedule
and have linked the slots on the time-table to the etherpads that we're
planning on using to track the discussion.
I've also updated the page with some more
On Mon, Feb 02, 2015 at 01:21:31PM -0500, Andrew Laski wrote:
On 02/02/2015 11:26 AM, Daniel P. Berrange wrote:
On Mon, Feb 02, 2015 at 11:19:45AM -0500, Andrew Laski wrote:
On 02/02/2015 05:58 AM, Daniel P. Berrange wrote:
On Sun, Feb 01, 2015 at 11:20:08AM -0800, Noel Burton-Krahn wrote:
On 02/02/2015 02:52 PM, Kurt Taylor wrote:
Thanks Morgan, That's why I wanted to email.
And since we have over 100 third party CI accounts this is why this sort
of conversation can take place in channel rather than the mail list.
Everyone can attend meetings:
On Fri, 2015-01-30 at 23:05 +, Everett Toews wrote:
To converge the OpenStack APIs to a consistent and pragmatic RESTful
design by creating guidelines that the projects should follow. The
intent is not to create backwards incompatible changes in existing
APIs, but to have new APIs and
On Mon, Feb 2, 2015 at 11:01 PM, Alexandre Levine
alev...@cloudscaling.com wrote:
Michael,
I'm rather new here, especially in regard to communication matters, so I'd
also be glad to understand how it's done and then I can drive it if it's ok
with everybody.
By saying EC2 sub team - who did
On 2/2/15 11:15 PM, Michael Still wrote:
On Mon, Feb 2, 2015 at 11:01 PM, Alexandre Levine
alev...@cloudscaling.com wrote:
Michael,
I'm rather new here, especially in regard to communication matters, so I'd
also be glad to understand how it's done and then I can drive it if it's ok
with
On 02/02/2015 04:20 PM, Mark McClain wrote:
You’re right that the Mako dependency is really a side effect from Alembic.
We used jinja for tempting radvd because it is used by the projects within
the OpenStack ecosystem and also used in VPNaaS.
Jinja is far more used in other parts of
Just FYI, in case there was any questions,
In addition to testing and reporting on Nova, the IBM PowerKVM CI system is
now also testing against Keystone patches.
We are happy to also be testing keystone patches on PowerKVM, and will be
adding other projects soon.
Regards,
Kurt Taylor (krtaylor)
You’re right that the Mako dependency is really a side effect from Alembic. We
used jinja for tempting radvd because it is used by the projects within the
OpenStack ecosystem and also used in VPNaaS.
mark
On Feb 2, 2015, at 3:13 PM, Sean M. Collins s...@coreitpro.com wrote:
Sorry, I
I assumed [my mistake] this was not commenting/reporting, just running against
Keystone. I expect a more specific request to comment rather than a “hey we’re
doing this” if commenting is what is desired.
Please come to our weekly meeting if you’re planning on commenting/scoring on
keystone
Sorry, I should have done a bit more grepping before I sent the e-mail,
since it appears that Mako is being used by alembic.
http://alembic.readthedocs.org/en/latest/tutorial.html
So, should we switch the radvd templating over to Mako instead?
--
Sean M. Collins
On 02/02/2015 02:16 PM, Morgan Fainberg wrote:
Thank you for the heads up.
—Morgan
--
Morgan Fainberg
On February 2, 2015 at 1:15:49 PM, Kurt Taylor (kurt.r.tay...@gmail.com)
wrote:
Just FYI, in case there was any questions,
In addition to testing and reporting on Nova, the
OK, thanks Sebastien and Valeriy.
Jake
Sebastien Han sebastien@enovance.com wrote on 02/02/2015 06:51:10
AM:
From: Sebastien Han sebastien@enovance.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 02/02/2015 06:54 AM
On Mon, Feb 2, 2015 at 10:28 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:
I think the simple answer is yes. We (keystone) should emit
notifications. And yes other projects should listen.
The only thing really in discussion should be:
1: soft delete or hard delete? Does the service
On February 2, 2015 at 1:31:14 PM, Joe Gordon (joe.gord...@gmail.com) wrote:
On Mon, Feb 2, 2015 at 10:28 AM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:
I think the simple answer is yes. We (keystone) should emit notifications.
And yes other projects should listen.
The only thing really
Thanks Morgan, That's why I wanted to email. We will gladly come to a
meeting and formally request to comment and will turn off commenting on
Keystone until then.
Thanks,
Kurt Taylor (krtaylor)
On Mon, Feb 2, 2015 at 3:43 PM, Morgan Fainberg morgan.fainb...@gmail.com
wrote:
I assumed [my
On 2/2/2015 3:52 PM, Kurt Taylor wrote:
Thanks Morgan, That's why I wanted to email. We will gladly come to a
meeting and formally request to comment and will turn off commenting on
Keystone until then.
Thanks,
Kurt Taylor (krtaylor)
On Mon, Feb 2, 2015 at 3:43 PM, Morgan Fainberg
On 02/02/2015 01:27 PM, Mathieu Gagné wrote:
On 2015-02-02 11:36 AM, Chris Friesen wrote:
On 01/30/2015 06:26 AM, Jesse Pretorius wrote:
Have you tried manually updating the NoVNC and websockify files to later
versions from source?
We were already using a fairly recent version of
Yeah sure
From: blak...@gmail.com
Date: Mon, 2 Feb 2015 11:09:08 -0800
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev][Neutron] unable to reproduce bug 1317363
The mailing list isn't a great place to discuss reproducing a bug. Post this
comment on the bug report instead
On Tue, Feb 3, 2015 at 9:05 AM, Jay Pipes jaypi...@gmail.com wrote:
On 01/29/2015 12:41 PM, Sean Dague wrote:
Correct. This actually came up at the Nova mid cycle in a side
conversation with Ironic and Neutron folks.
HTTP error codes are not sufficiently granular to describe what happens
On 26/01/15 19:04, Angus Salkeld wrote:
On Sat, Jan 24, 2015 at 7:00 AM, Zane Bitter zbit...@redhat.com
mailto:zbit...@redhat.com wrote:
I'm also prepared to propose specs for all of these _if_ people
think that would be helpful. I see three options here:
- Propose 18 fairly
This broke grenade on stable/juno, here is the fix.
https://review.openstack.org/#/c/152333/
On Mon, Feb 2, 2015 at 10:56 AM, Joshua Harlow harlo...@outlook.com wrote:
The Oslo team is pleased to announce the release of:
TaskFlow 0.7.0: taskflow structured state management library.
For
+openstack-operators
On 2/2/15, 12:24 PM, Jesse Cook
jesse.c...@rackspace.commailto:jesse.c...@rackspace.com wrote:
Configuration options will change (https://review.openstack.org/#/c/146972/4):
- Removed config option: swift_enable_snet. The default value of
swift_enable_snet was False [1].
On 01/29/2015 12:41 PM, Sean Dague wrote:
Correct. This actually came up at the Nova mid cycle in a side
conversation with Ironic and Neutron folks.
HTTP error codes are not sufficiently granular to describe what happens
when a REST service goes wrong, especially if it goes wrong in a way
that
On 02/02/2015 05:35 PM, Jay Pipes wrote:
On 01/29/2015 12:41 PM, Sean Dague wrote:
Correct. This actually came up at the Nova mid cycle in a side
conversation with Ironic and Neutron folks.
HTTP error codes are not sufficiently granular to describe what happens
when a REST service goes
Sean Dague s...@dague.net wrote:
On 02/02/2015 06:06 PM, Mike Bayer wrote:
Sean Dague s...@dague.net wrote:
On 02/02/2015 04:20 PM, Mark McClain wrote:
You’re right that the Mako dependency is really a side effect from
Alembic. We used jinja for tempting radvd because it is used by the
On Mon, Feb 2, 2015 at 4:07 PM, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:
On 2/2/2015 3:52 PM, Kurt Taylor wrote:
Thanks Morgan, That's why I wanted to email. We will gladly come to a
meeting and formally request to comment and will turn off commenting on
Keystone until then.
+1 to that idea...
Jay Pipes jaypi...@gmail.com wrote on 02/02/2015 04:35:36 PM:
What about having a separate HTTP header that indicates the OpenStack
Error Code, along with a generated URI for finding more information
about the error?
Something like:
X-OpenStack-Error-Code: 1234
Sean Dague s...@dague.net wrote:
On 02/02/2015 04:20 PM, Mark McClain wrote:
You’re right that the Mako dependency is really a side effect from Alembic.
We used jinja for tempting radvd because it is used by the projects within
the OpenStack ecosystem and also used in VPNaaS.
Jinja is
+ openstack-operators
On 2/2/15, 12:24 PM, Jesse Cook
jesse.c...@rackspace.commailto:jesse.c...@rackspace.com wrote:
Configuration options will change (https://review.openstack.org/#/c/146972/4):
- Removed config option: swift_enable_snet. The default value of
swift_enable_snet was False
Agree with Sean. A short error name in response body would be better for
applications who consume OpenStack. To my understand, the
X-OpenStack-Error-Help-URI proposed by jpipes will be a uri to error
resolution method. Usually, a consumer application needn't to load its
content.
On Feb 3, 2015
Sigh... hit send too soon and forgot to sign...
+1 to that idea...
Ryan
Jay Pipes jaypi...@gmail.com wrote on 02/02/2015 04:35:36 PM:
What about having a separate HTTP header that indicates the OpenStack
Error Code, along with a generated URI for finding more information
about the error?
Matthew Booth mbo...@redhat.com wrote:
Based on my current (and still sketchy) understanding, I think we can
define 3 classes of database node:
1. Read/write
2. Synchronous read-only
3. Asynchronous read-only
and 3 code annotations:
* Writer (must use class 1)
* Reader (prefer
Thanks for that!
Much appreciated :-)
Joe Gordon wrote:
This broke grenade on stable/juno, here is the fix.
https://review.openstack.org/#/c/152333/
On Mon, Feb 2, 2015 at 10:56 AM, Joshua Harlow harlo...@outlook.com
mailto:harlo...@outlook.com wrote:
The Oslo team is pleased to
A spec has been raised to add a config option to allow operators to
choose whether to use the new convergence engine for stack operations.
For some context you should read the spec first [1]
Rather than doing this, I would like to propose the following:
* Users can (optionally) choose which
On 02/02/2015 06:06 PM, Mike Bayer wrote:
Sean Dague s...@dague.net wrote:
On 02/02/2015 04:20 PM, Mark McClain wrote:
You’re right that the Mako dependency is really a side effect from Alembic.
We used jinja for tempting radvd because it is used by the projects within
the OpenStack
On Mon, Feb 2, 2015 at 4:35 PM, Jay Pipes jaypi...@gmail.com wrote:
On 01/29/2015 12:41 PM, Sean Dague wrote:
Correct. This actually came up at the Nova mid cycle in a side
conversation with Ironic and Neutron folks.
HTTP error codes are not sufficiently granular to describe what happens
I believe this will start somewhere after Kilo.
On 28 Jan 2015, at 22:59, Valeriy Ponomaryov vponomar...@mirantis.com wrote:
Hello Jake,
Main thing, that should be mentioned, is that blueprint has no assignee.
Also, It is created long time ago without any activity after it.
I did not
Your VM must be launched on the controller node then. In a multi-node setup
the controller will also act as a compute node unless you have disabled the
n-cpu service. The 'host' attribute is specifically to indicate where a
port is being used. It's not for anything else.
On Mon, Feb 2, 2015 at
On Mon, Feb 02, 2015 at 02:45:53PM +0300, Alexandre Levine wrote:
Daniel,
On 2/2/15 12:58 PM, Daniel P. Berrange wrote:
On Fri, Jan 30, 2015 at 07:57:08PM +, Tim Bell wrote:
Alex,
Many thanks for the constructive approach. I've added an item to the list
for the Ops meetup in
On 01/30/2015 06:18 PM, Dean Troyer wrote:
On Fri, Jan 30, 2015 at 4:57 PM, Everett Toews
everett.to...@rackspace.com mailto:everett.to...@rackspace.com wrote:
What is the API WG mission statement?
It's more of a mantra than a Mission Statement(TM):
Identify existing and future
But why to add another interface when there is one already (rest api)?
I'm ok if we decide to use REST API, but of course there is a problem which
we should solve, like versioning, which is much harder to support, than
versioning
in core-serializers. Also do you have any ideas how it can be
On Fri, 30 Jan 2015, Everett Toews wrote:
To converge the OpenStack APIs to a consistent and pragmatic RESTful
design by creating guidelines that the projects should follow. The
intent is not to create backwards incompatible changes in existing
APIs, but to have new APIs and future versions of
On Fri, Jan 30, 2015 at 07:57:08PM +, Tim Bell wrote:
Alex,
Many thanks for the constructive approach. I've added an item to the list for
the Ops meetup in March to see who would be interested to help.
As discussed on the change, it is likely that there would need to be some
Hi,
It was not re-proposed for Kilo as there is basic work ongoing in Cinder to
create a common library Brick that can be used by Cinder and Nova.
There might be a chance in L* to get it in. Would be nice to get some people
together working on it
/Tobi
-Original Message-
From: Michael
On Mon, Feb 02, 2015 at 08:24:20AM +1300, Robert Collins wrote:
On 31 January 2015 at 05:47, Daniel P. Berrange berra...@redhat.com wrote:
In working on a recent Nova migration bug
https://bugs.launchpad.net/nova/+bug/1414065
I had cause to refactor the way the nova libvirt driver
Hi all,
For the past few days I have been facing the problem of getting the image
upload error while installation of devstack in my CI. The devstack
installation is triggered in CI when someone does the checkin, and the
failure cause comes out to be the same.
Below is the log for the error:
On 30/01/15 19:06, Mike Bayer wrote:
Matthew Booth mbo...@redhat.com wrote:
At some point in the near future, hopefully early in L, we're intending
to update Nova to use the new database transaction management in
oslo.db's enginefacade.
Spec:
Michael,
I'm rather new here, especially in regard to communication matters, so
I'd also be glad to understand how it's done and then I can drive it if
it's ok with everybody.
By saying EC2 sub team - who did you keep in mind? From my team 3
persons are involved.
From the technical point of
Thanks for the summary, I'll try to send first patch(maybe WIP) in few days.
On Mon, Feb 2, 2015 at 1:43 PM, Christopher Yeoh cbky...@gmail.com wrote:
On Sat, Jan 31, 2015 at 4:09 AM, Andrey Kurilin akuri...@mirantis.com
wrote:
Thanks for the answer. Can I help with implementation of
On Fri, Jan 30, 2015 at 04:38:44PM -0600, Matt Riedemann wrote:
On 1/30/2015 3:16 PM, Soren Hansen wrote:
As I've said a couple of times in the past, I think the
architecturally sound approach is to keep this inside Nova.
The two main reasons are:
* Having multiple frontend API's
On Sat, Jan 31, 2015 at 03:55:23AM +0100, Vladik Romanovsky wrote:
- Original Message -
From: Daniel P. Berrange berra...@redhat.com
To: openstack-dev@lists.openstack.org,
openstack-operat...@lists.openstack.org
Sent: Friday, 30 January, 2015 11:47:16 AM
Subject:
Hi Ken,
1 imageRef isn't the only attribute, which could receive an image id. There
are kernelId, ramdiskId, and even bdm v2 as well. So we couldn't guess
which attribute has the invalid value.
2 Besides NotFound case, other mixed cases are there. Such as attaching of
a volume. A mountpoint can
On Mon Feb 02 2015 at 11:49:31 AM Julien Danjou jul...@danjou.info wrote:
On Fri, Jan 30 2015, Yuriy Taraday wrote:
That's a great research! Under its impression I've spent most of last
evening reading PyMySQL sources. It looks like it not as much need C
speedups currently as plain old
The only thing this discussion has convinced me of is that allowing users
to change the fixed IP address on a neutron port leads to a bad
user-experience.
Not as bad as having to delete a port and create another one on the same
network just to change addresses though...
Even with an 8-minute
On Sun, Feb 01, 2015 at 11:20:08AM -0800, Noel Burton-Krahn wrote:
Thanks for bringing this up, Daniel. I don't think it makes sense to have
a timeout on live migration, but operators should be able to cancel it,
just like any other unbounded long-running process. For example, there's
no
On Sun, Feb 01, 2015 at 03:03:45PM -0700, David Medberry wrote:
I'll second much of what Rob said:
API that indicated how many live-migrations (l-m) were going would be good.
API that told you what progress (and start time) a given l-m had made would
be great.
API to cancel a given l-m would
On Sat, Jan 31, 2015 at 4:09 AM, Andrey Kurilin akuri...@mirantis.com
wrote:
Thanks for the answer. Can I help with implementation of novaclient part?
Sure! Do you think its something you can get proposed into Gerrit by the
end of the week or very soon after?
Its the sort of timeframe we're
Hi Abhishek,
This is bug https://launchpad.net/bugs/1415795 introduced by
https://review.openstack.org/#/c/142967/ because Swift doesn't use olso.config.
The fix is at https://review.openstack.org/#/c/151506/ which has not yet been
approved, but if you can cherry-pick it for your CI it should
Hello,
(resurrecting this old thread because I think I found the root cause)
The problem affects all OpenStack environments using Syslog, not only
Fuel-based installations: when use_syslog is true, the
logging_context_format_string and logging_default_format_string parameters
aren't taken into
Hi Bob,
Thanks for the reply, this is really a great help for me.
On Mon, Feb 2, 2015 at 3:11 PM, Bob Ball bob.b...@citrix.com wrote:
Hi Abhishek,
This is bug https://launchpad.net/bugs/1415795 introduced by
https://review.openstack.org/#/c/142967/ because Swift doesn't use
olso.config.
Daniel,
On 2/2/15 12:58 PM, Daniel P. Berrange wrote:
On Fri, Jan 30, 2015 at 07:57:08PM +, Tim Bell wrote:
Alex,
Many thanks for the constructive approach. I've added an item to the list for
the Ops meetup in March to see who would be interested to help.
As discussed on the change,
Hi Mike,
There is 2 features[1][2][3] of HNAS driver that still are not
approved/targeted.
Is there anything missing to then to be approved?
Erlon
[1] https://blueprints.launchpad.net/cinder/+spec/hds-hnas-ssh-backend
[2] https://blueprints.launchpad.net/cinder/+spec/hds-hnas-pool-aware-sched
On Tue, Jan 27, 2015 at 04:27:21AM +, Adrian Otto wrote:
Tony,
That would be terrific. Which iCal feed were you thinking of? I was planning
on making something similar to this:
Sorry Adrian I was a little off topic.
I was thinking that when you settle on a schedule for your regular
Sorry, i find it.
--
Best
Li Tianqing
At 2015-02-03 10:48:06, Li Tianqing jaze...@163.com wrote:
Hello,
I first install devstack, then install trove from source code. After
seraching on the net, i do not find how to enable trove in dashboard...
Can someone help to point out how
Hey Pavlov,
The main aim of this effort is to allow a more efficient template catalog
management, not unlike what is given in [2]. As a service to our customers,
Rackspace maintains a catalog of useful templates[3] which are also exposed to
the user through the UI. The template authors of
I think incremental adoption is a great principle to have and this
will enable that.
So +1
-Rob
On 3 February 2015 at 13:52, Steve Baker sba...@redhat.com wrote:
A spec has been raised to add a config option to allow operators to choose
whether to use the new convergence engine for stack
On Feb 2, 2015, at 7:24 PM, Sean Dague s...@dague.netmailto:s...@dague.net
wrote:
On 02/02/2015 05:35 PM, Jay Pipes wrote:
On 01/29/2015 12:41 PM, Sean Dague wrote:
Correct. This actually came up at the Nova mid cycle in a side
conversation with Ironic and Neutron folks.
HTTP error codes are
Meeting on #openstack-meeting at 1500 UTC (8:00AM MST)
1) Remove direct nova DB/API access by Scheduler Filters -
https://review.opernstack.org/138444/
2) Status on cleanup work - https://wiki.openstack.org/wiki/Gantt/kilo
--
Don Dugger
Censeo Toto nos in Kansa esse decisse. - D.
Just a reminder, we'll have the weekly Neutron meeting [1] at 2100UTC in
#openstack-meeting today. We'll likely spend the majority of the time going
over any critical bugs, as well as covering BPs for Kilo-2 which have yet
to land this week. The other two standing items we'll discuss are the
On Thu, 29 Jan 2015, michael mccune wrote:
in a similar vein, i started to work on marking up the sahara and barbican
code bases to produce swagger. for sahara this was a little easier as flask
makes it simple to query the paths. for barbican i started a pecan-swagger[1]
project to aid in
- Original Message -
From: Daniel P. Berrange berra...@redhat.com
To: Robert Collins robe...@robertcollins.net
Cc: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
openstack-operat...@lists.openstack.org
Sent: Monday, 2 February, 2015
Daniel P. Berrange wrote:
On Fri, Jan 30, 2015 at 04:38:44PM -0600, Matt Riedemann wrote:
Deprecation isn't a one-way street really, nova-network was deprecated for a
couple of releases and then undeprecated and opened up again for feature
development (at least for a short while until the
I'm with Daniel on that one. We shouldn't deprecate until we are 100%
sure that the replacement is up to the task and that strategy is solid.
My problem with this is: If there wasn't a stackforge project, what
would we do? Nova's in-tree EC2 support has been rotting for years now,
and despite
On 02/02/2015 07:01 AM, Alexandre Levine wrote:
Michael,
I'm rather new here, especially in regard to communication matters, so
I'd also be glad to understand how it's done and then I can drive it if
it's ok with everybody.
By saying EC2 sub team - who did you keep in mind? From my team 3
On 01/30/2015 07:23 AM, Sandy Walsh wrote:
From: Johannes Erdfelt [johan...@erdfelt.com]
Sent: Thursday, January 29, 2015 9:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][tc] SQL Schema Downgrades
On 02/02/2015 11:35 AM, Alexandre Levine wrote:
Thank you Sean.
We'll be tons of EC2 Tempest tests for your attention shortly.
How would you prefer them? In several reviews, I believe. Not in one,
right?
Best regards,
Alex Levine
So, honestly, I think that we should probably look at
On Mon, Feb 02, 2015 at 10:44:09AM -0600, Chris Friesen wrote:
Hi,
I'm trying to make use of huge pages as described in
http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-large-pages.html;.
I'm running kilo as of Jan 27th.
I've allocated 1 2MB pages on a
On 02/02/2015 12:54 AM, Christopher Yeoh wrote:
On Sun, Feb 1, 2015 at 2:57 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
On 01/31/2015 05:24 AM, Duncan Thomas wrote:
Hi
This discussion came up at the cinder mid-cycle last week too,
specifically in
After a long wait and much testing, we've merged a change[1] which
moves the remainder of Python 3.3 based jobs to Python 3.4. This is
primarily in service of getting rid of the custom workers we
implemented to perform 3.3 testing more than a year ago, since we
can now run 3.4 tests on normal
On 02/01/2015 06:20 PM, Morgan Fainberg wrote:
Putting on my sorry-but-it-is-my-job-to-get-in-your-way hat (aka security),
let's be careful how generous we are with the user and data we hand back. It
should give enough information to be useful but no more. I don't want to see
us opened to
Thank you Sean.
We'll be tons of EC2 Tempest tests for your attention shortly.
How would you prefer them? In several reviews, I believe. Not in one, right?
Best regards,
Alex Levine
On 2/2/15 6:55 PM, Sean Dague wrote:
On 02/02/2015 07:01 AM, Alexandre Levine wrote:
Michael,
I'm rather
On 02/02/2015 10:26 AM, Chris Dent wrote:
pecan-swagger looks cool but presumably pecan has most of the info
you're putting in the decorators in itself already? So, given an
undecorated pecan app, would it be possible to provide it to a function
and have that function output all the paths?
On 02/02/2015 11:35 AM, Alexandre Levine wrote:
Thank you Sean.
We'll be tons of EC2 Tempest tests for your attention shortly.
How would you prefer them? In several reviews, I believe. Not in one,
right?
Best regards,
Alex Levine
So, honestly, I think that we should probably look at
Hi Dmitry,
I've read about inventories and I'm not sure if it's what we really need,
inventory provides you a way to have some kind of nodes discovery
mechanism, but what we need is to get some abstract data and convert
the data to more tasks friendly format.
In another thread I've mentioned
On 01/29/2015 03:11 PM, Mike Bayer wrote:
Morgan Fainberg morgan.fainb...@gmail.com wrote:
Are downward migrations really a good idea for us to support? Is this downward
migration path a sane expectation? In the real world, would any one really
trust the data after migrating downwards?
Hi,
I'm trying to make use of huge pages as described in
http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/virt-driver-large-pages.html;.
I'm running kilo as of Jan 27th.
I've allocated 1 2MB pages on a compute node. virsh capabilities on that
node contains:
On 01/30/2015 02:19 AM, Thomas Spatzier wrote:
From: Zane Bitter zbit...@redhat.com
To: openstack Development Mailing List
openstack-dev@lists.openstack.org
Date: 29/01/2015 17:47
Subject: [openstack-dev] [Heat][Keystone] Native keystone resources in
Heat
I got a question today about
This is a bug that I discovered when fixing some of the NUMA related
nova objects. I have a patch that should fix it up shortly.
This is what happens when we don't have any functional testing of stuff
that is merged into master...
Best,
-jay
On 02/02/2015 11:44 AM, Chris Friesen wrote:
Hi,
Kevin,
I think we are finally converging. One of the points I've been trying to make
is that users are playing with fire when they start playing with some of these
port attributes, and given the tool we have to work with (DHCP), the
instantiation of these changes cannot be made seamlessly to a
On Mon, Feb 02, 2015 at 07:44:24AM -0800, Dan Smith wrote:
I'm with Daniel on that one. We shouldn't deprecate until we are 100%
sure that the replacement is up to the task and that strategy is solid.
My problem with this is: If there wasn't a stackforge project, what
would we do? Nova's
On 02/02/2015 07:01 AM, Alexandre Levine wrote:
Michael,
I'm rather new here, especially in regard to communication matters, so
I'd also be glad to understand how it's done and then I can drive it if
it's ok with everybody.
By saying EC2 sub team - who did you keep in mind? From my team 3
1 - 100 of 139 matches
Mail list logo
