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 concentra
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
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 Ly
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 wrote:
> I commented on this in your patch (
> https://review.openstack.org/#/c/161837/) and posted a patch to help you
> along - https://review.openstack.org/#/c/
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
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 run
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
+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 Messag
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 wrote:
> On Friday 06 March 2015 16:57:19 Nikolay Markov wrote:
> > Hi everybody,
> >
> > From time to time some bugs appea
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
a
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
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 n
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
ever
+1
Ihar has been made great jobs and it is a nice addition for the team.
2015年3月5日木曜日、Edgar Magana>さんは書きました:
> No doubt about it!
>
> +1 Cheers for a new extremely good core member!
>
> Thanks,
>
> Edgar
>
> From: Kyle Mestery
> Reply-To: "OpenStack Development Mailing List (not for usag
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
ever
- Original Message -
> From: "Attila Fazekas"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Friday, March 6, 2015 4:19:18 PM
> Subject: Re: [openstack-dev] [nova] blueprint about multiple workers
> supported in nova-scheduler
>
> Looks like we need
On 03/06/2015 10:44 AM, Rich Megginson wrote:
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
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 y
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
oslo.messaging.Target).
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 c
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
te
I like that idea. Can you start it out with Nova or Neutron’s guidelines?
On 3/5/15, 17:38, "Mikhail Fedosin" wrote:
>I think yes, it does. But I mean that now we're writing a document called
>Glance Review Guidelines
>
>https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5R
Can you check is this patch does the right thing[1]:
[1] https://review.openstack.org/#/c/112523/6
- Original Message -
> From: "Fredy Neeser"
> To: openstack-dev@lists.openstack.org
> Sent: Friday, March 6, 2015 6:01:08 PM
> Subject: [openstack-dev] [neutron] VXLAN with single-NIC compu
On 3/5/15, 10:56, "Dr. Jens Rosenboom" 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 client break
On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco
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].
[1]
https://github.com/ope
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 man
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
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 t
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:
http://specs.openstack.org/openstack/docs-specs/specs/k
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 la
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 j
I filed this as a bug:
https://bugs.launchpad.net/oslo.db/+bug/1429233
To hopefully summarize, the new provision stuff in oslo.db requires
testresources and the provision stuff is a public interface for other
projects to hook in DB testing (a fixture).
This moved testscenarios out of test-re
On Fri, Mar 6, 2015, at 03:28 PM, Matt Riedemann wrote:
> I filed this as a bug:
>
> https://bugs.launchpad.net/oslo.db/+bug/1429233
>
> To hopefully summarize, the new provision stuff in oslo.db requires
> testresources and the provision stuff is a public interface for other
> projects to ho
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 C
(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 t
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 subset
On 3/6/15, 15:04, "Nikhil Komawar" 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 to
>ones out there as
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 i
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.
Contro
On 06/03/15 21:09 +, Ian Cordasco wrote:
On 3/6/15, 15:04, "Nikhil Komawar" 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
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 wrote:
>
>
> On Tue, Feb 24, 2015 at 1:18 PM, melanie witt wrote:
>
>> On Feb 24, 2015, at 9:47, Sean Dague wrote:
>>
>> > I'm happy if there are other the
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
Hi stackers,
Intro (Gabbi)
-
Gabbi is amazing tool that allows you to describe in human readable way
what API requests to execute and what you are expecting as a result. It
Simplifies a lot API testing.
It's based on unittest so it can be easily run using tox/tester/nose
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 core-me
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 thi
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, who
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 Tri
2015-03-06 13:49 GMT+08:00 GHANSHYAM MANN :
> 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-
> api_samples/
>
49 matches
Mail list logo