2015-03-06 13:49 GMT+08:00 GHANSHYAM MANN ghanshyamm...@gmail.com:
Hi Sean,
That is very nice idea to keep only 1 set of tests and run those twice via
tox.
Actually my main goal was-
- 1. Create clean sample file structure for V2. V2.1 and micro-versions
Something like below-
Hi,
I thought the feature should be approved as long as the SPEC[1] is merged, but
it seems I am wrong from the beginning[2], both of
them (SPEC merged and BP approval[4][5]) is necessary and mandatory for getting
some effective reviews, right? anyone can help to
confirm with that?
Besides,
On Tue, 2015-03-03 at 17:30 -0500, James Slagle wrote:
Hi,
Don't let the subject throw you off :)
I wasn't sure how to phrase what I wanted to capture in this mail, and
that seemed reasonable enough. I wanted to kick off a discussion about
what gaps people think are missing from TripleO
I like the idea of a 'core-member'. But, how are core-members different from
core-reviewers? For instance, with core-reviewers it is very clear that these
are folks you would trust with merging code because they are supposed to have a
good understanding of the overall project. What about
First pass at trying to capture this thread into a README:
https://review.openstack.org/162334
On Tue, Feb 24, 2015 at 2:07 PM, Joe Gordon joe.gord...@gmail.com wrote:
On Tue, Feb 24, 2015 at 1:18 PM, melanie witt melwi...@gmail.com wrote:
On Feb 24, 2015, at 9:47, Sean Dague s...@dague.net
Hi everyone,
I am Xiaoyuan Lu, a recipient oftheHP Helion OpenStack scholarship, and
ElizabethK. Josephis my mentor from HP. I would like to work on projects
related to Keystone. Considering the amount of work and tiime limit,
after going through the Keystone specs, finally we decided to work
On 03/06/2015 01:29 PM, Matthias Runge wrote:
On Fri, Mar 06, 2015 at 11:08:44AM -0500, Adam Young wrote:
No matter what we do in devstack, this is something, horizon and
keystone devs need to fix first. E.g. in Horizon, we still discover hard
coded URLs here and there. To catch that kind of
With the advent of gabbi tests in both ceilometer and gnocchi, we've
started using xfail (expected failure) as a way of highlighting HTTP
behavior that is wrong or poor[1] and linking to bugs on launchpad in
the description of the tests.
This means that we need to start monitoring local test
Kamil,
thank you for the explanation.
Indeed, the idea of keeping two separate entry points — one for the old
functionality and another with the new cliff-based CLI makes more sense.
In addition to the advantages you mentioned it will allow us to avoid all the
mess with fall-backs and
I've been away from Horizon activities for a while, so this sad news has
come to me just a moment ago.
Julie, you were of great help on #openstack-horizon, especially to
newcomers, I'll be missing you there.
Wish you luck in any of your new endeavors :)!
On Fri, Feb 13, 2015 at 5:18 PM, David
Ramy,
Ok, I'll do that. Good idea.
Thang,
Thank you for all your help.
Regards,
Marcus
On Thu, Mar 5, 2015 at 11:41 PM, Thang Pham thang.g.p...@gmail.com wrote:
I commented on this in your patch (
https://review.openstack.org/#/c/161837/) and posted a patch to help you
along -
On Friday 06 March 2015 16:57:19 Nikolay Markov wrote:
Hi everybody,
From time to time some bugs appear regarding failed database migrations
during upgrade and we have High-priority bug for 6.1 (
https://bugs.launchpad.net/fuel/+bug/1391553) on testing this migration
process. I want to
Looks like we need some kind of _per compute node_ mutex in the critical
section,
multiple scheduler MAY be able to schedule to two compute node at same time,
but not for scheduling to the same compute node.
If we don't want to introduce another required component or
reinvent the wheel there are
+1 on avoiding changes that break rolling upgrade.
Rolling upgrade has been working so far (at least from my perspective), and
as openstack adoption spreads, it will be important for more and more users.
How do we make rolling upgrade a supported part of Neutron?
- Jack
-Original
We already run unit tests only using real Postgresql. But
this still doesn't answer the question how we should test migrations.
On Fri, Mar 6, 2015 at 5:24 PM, Boris Bobrov bbob...@mirantis.com wrote:
On Friday 06 March 2015 16:57:19 Nikolay Markov wrote:
Hi everybody,
From time to time
Hi all,
You could take a look at how this is done in OpenStack projects [1][2]
Most important parts:
1) use the same RDBMS you use in production
2) test migration scripts on data, not on empty schema
3) test corner cases (adding a NOT NULL column without a server side
default value, etc)
4) do a
Hi,
First, sorry for cross-posting on both dev and operator MLs but I also
would like to get operators feedback.
So, I was reviewing the scheduler ComputeFilter and I was wondering why
the logic should be in a filter.
We indeed already have a check on the service information each time that
On Fri, Mar 06 2015, Chris Dent wrote:
Gnocchi has already started using pretty_tox.sh, so as long as there
is a recent version of subunit-trace (from tempest-lib) installed,
gnocchi test runs will tell when there has been an unexpected
success.
Are you saying that unexpected success is not
Hi everybody,
From time to time some bugs appear regarding failed database migrations
during upgrade and we have High-priority bug for 6.1 (
https://bugs.launchpad.net/fuel/+bug/1391553) on testing this migration
process. I want to start a thread for discussing how we're going to do it.
I don't
On 03/06/2015 12:37 AM, Matthias Runge wrote:
On 05/03/15 19:49, Adam Young wrote:
I'd like to drop port 5000 all-together, as we are using a port assigned
to a different service. 35357 is also problematic as it is in the
middle of the Ephemeral range. Since we are talking about running
- Original Message -
From: Attila Fazekas afaze...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Friday, March 6, 2015 4:19:18 PM
Subject: Re: [openstack-dev] [nova] blueprint about multiple workers
supported
Hi, just some oslo.messaging thoughts about having multiple
nova-scheduler processes (can also apply to any other daemon acting as
rpc server),
nova-scheduler use service.Service.create() to create a rpc server, that
one is identified by a 'topic' and a 'server' (the
+1
Ihar has been made great jobs and it is a nice addition for the team.
2015年3月5日木曜日、Edgar Maganaedgar.mag...@workday.com
javascript:_e(%7B%7D,'cvml','edgar.mag...@workday.com');さんは書きました:
No doubt about it!
+1 Cheers for a new extremely good core member!
Thanks,
Edgar
From:
On 03/06/2015 02:37 AM, Matthias Runge wrote:
On 05/03/15 19:49, Adam Young wrote:
I'd like to drop port 5000 all-together, as we are using a port assigned
to a different service. 35357 is also problematic as it is in the
middle of the Ephemeral range. Since we are talking about running
On Fri, 6 Mar 2015, Julien Danjou wrote:
On Fri, Mar 06 2015, Chris Dent wrote:
Gnocchi has already started using pretty_tox.sh, so as long as there
is a recent version of subunit-trace (from tempest-lib) installed,
gnocchi test runs will tell when there has been an unexpected
success.
Are
Hello world
I recently created a VXLAN test setup with single-NIC compute nodes
(using OpenStack Juno on Fedora 20), conciously ignoring the OpenStack
advice of using nodes with at least 2 NICs ;-) .
The fact that both native and encapsulated traffic needs to pass through
the same NIC does
On 03/06/2015 01:56 AM, Rui Chen wrote:
Thank you very much for in-depth discussion about this topic, @Nikola
and @Sylvain.
I agree that we should solve the technical debt firstly, and then make
the scheduler better.
That was not necessarily my point.
I would be happy to see work on how
On Fri, 6 Mar 2015, Chris Dent wrote:
It looks like the problem is in subunit (this is with a locally
modified gabbi test):
$ for i in testtools subunit ; \
do python -m $i.run discover gnocchi.tests.gabbi /dev/null || \
echo $i catches uxsuccess as fail ; \
done
On 3/5/15, 10:56, Dr. Jens Rosenboom j.rosenb...@x-ion.de wrote:
Am 05/03/15 um 17:37 schrieb Ian Cordasco:
The clients in general do not back port patches. Someone should work
with
stable-maint to raise the cap in Icehouse and Juno. I suspect, however,
that those caps were added due to the
On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco ian.corda...@rackspace.com
wrote:
I like that idea. Can you start it out with Nova or Neutron’s guidelines?
FYI, the core reviewer guidelines for Neutron are in-tree now [1], along
with all of our other policies around operating in Neutron [2].
Announcing Gertty 1.1.0
===
Gertty is a console-based interface to the Gerrit Code Review system.
Gertty is designed to support a workflow similar to reading network
news or mail. It syncs information from Gerrit to local storage to
support disconnected operation and easy
On Fri, Mar 06, 2015 at 11:08:44AM -0500, Adam Young wrote:
No matter what we do in devstack, this is something, horizon and
keystone devs need to fix first. E.g. in Horizon, we still discover hard
coded URLs here and there. To catch that kind of things, I had a patch
up for review, to easily
I mentioned this on #openstack-neutron IRC today but it would be nice to
get more eyes on a (2 weeks old) revert here [1].
The only reasons TripleO ci has been working the last 2 weeks because we
are cherry picking this very revert/fix via our CI scripts here [2].
This issue has sort of slipped
I like that idea. Can you start it out with Nova or Neutron’s guidelines?
On 3/5/15, 17:38, Mikhail Fedosin mfedo...@mirantis.com wrote:
I think yes, it does. But I mean that now we're writing a document called
Glance Review Guidelines
Can you check is this patch does the right thing[1]:
[1] https://review.openstack.org/#/c/112523/6
- Original Message -
From: Fredy Neeser fredy.nee...@solnet.ch
To: openstack-dev@lists.openstack.org
Sent: Friday, March 6, 2015 6:01:08 PM
Subject: [openstack-dev] [neutron] VXLAN with
Heya!
So, a while ago Horizon pulled in JSHint to do javascript linting, which is
awesome, but has a rather obnoxious Do no evil licence in the codebase:
https://github.com/jshint/jshint/blob/master/src/jshint.js
StoryBoard had the same issue, and I've recently replaced JSHint with
ESlint for
Hi all,
We have been working on streamlining driver documentation for Kilo through
a specification, on the mailing lists, and in my weekly What's Up Doc
updates. Thanks for the reviews while we worked out the solutions. Here's
the final spec:
The glance_store release management team is pleased to announce:
glance_store version 0.2.0 has been released on Friday March 6th around
20:17 UTC.
For more information, please find the details at:
https://launchpad.net/glance-store/+milestone/v0.2.0
Please report the issues through
Hi...it would be good to test a bunch of the
hugepages/pinning/multi-numa-node-guests/etc. features with real hardware. The
normal testing doesn't cover much of that since it's hardware-agnostic.
Chris
On 01/07/2015 08:31 PM, yongli he wrote:
Hi,
Intel set up a Hardware based Third Part
Hello,
Today I found bug https://bugs.launchpad.net/neutron/+bug/1314614 because I
have such problem on my infra.
I saw that bug is In progress but change is abandoned quite long time ago. I
was wondering is it possible that neutron will send notification to nova that
such port was deleted in
Hi Folks,
My Juno setup does not get the console for VM started and errors out with
1006 error. I struggled for a day changing many things but does not work.
What could I be doing wrong?
The controller has nova-consoleauth and nova-novncproxy services running
and compute the nova-compute.
(Adding back the -dev ML as it was removed)
Le 06/03/2015 20:25, Jay Pipes a écrit :
On 03/06/2015 10:54 AM, Jesse Keating wrote:
On 3/6/15 10:48 AM, Jay Pipes wrote:
Have you ever done this in practice?
One way of doing this would be to enable the host after adding it to a
host aggregate
Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel!
Mike, Ian: It's a good idea to have the policy however, we need to craft one
that is custom to the Glance program. It will be a bit different to ones out
there as we've contributors who are dedicated to only
On 3/6/15, 15:04, Nikhil Komawar nikhil.koma...@rackspace.com wrote:
Thank you all for the input outside of the program: Kyle, Ihar, Thierry,
Daniel!
Mike, Ian: It's a good idea to have the policy however, we need to craft
one that is custom to the Glance program. It will be a bit different
On 06/03/15 21:09 +, Ian Cordasco wrote:
On 3/6/15, 15:04, Nikhil Komawar nikhil.koma...@rackspace.com wrote:
Thank you all for the input outside of the program: Kyle, Ihar, Thierry,
Daniel!
Mike, Ian: It's a good idea to have the policy however, we need to craft
one that is custom to
45 matches
Mail list logo
