I had a look for fix that and I don't found a simple way.
The minimal MTU can be deducted by the LB agent with the value found on the
bridge and the LB agent can set it on veth interface connect to that bridge.
But there no easy way to set it on the other side of the veth in the
namespace. LB agen
Dan,
> >* If some kind soul can guide me on adding unit tests - per my question*
> >* below - then I'll add them, otherwise I'll just complete the fix for
now*
> >* and add the tests in a later change.*
>
> The change really needs to come with tests. A fix is only good if we
> know it's a fix :)
Hi,
Today we'll have the kick-off Mistral community meeting at 16.00 UTC
(#openstack-meeting). Everyone interested in things like TaskFlow, Convection,
"Workflow as a service" or whatever you call it, is very welcome to participate
and share your ideas.
The agenda can always be found at
https
On 10/20/2013 03:03 PM, Robert Collins wrote:
On 21 October 2013 07:36, Alex Gaynor wrote:
There's several issues involved in doing automated regression checking for
benchmarks:
- You need a platform which is stable. Right now all our CI runs on
virtualized instances, and I don't think there's
> As I don't see how to "keep it in the review", I'll copy to openstack-dev.
Just keep making your comments in Gerrit. That way all the discussion
related to a specific patch is preserved with proper linkage in case we
ever need to go back to it.
> OK, I think I see what I need to do to do to not
On Sun, Oct 20, 2013 at 1:31 PM, Edgar Magana wrote:
> Floren,
>
> Just just need to send a patch to gerrit.
>
> From you local repo, do the necessary fixes and be sure everything is just
> as you want.
> Then simply run:
> #git commit -a --amend
> #git review
>
>
The only "gotcha" here is that y
Is it easy ? No... it is hard, whether in an integrated test suite or on its own
Can it be solved ? Yes, we have done incredible things with the current QA
infrastructure
Should it be split off from other testing ? No, I want EVERY commit to have
this check. Performance through benchmarking at
On 21 October 2013 07:36, Alex Gaynor wrote:
> There's several issues involved in doing automated regression checking for
> benchmarks:
>
> - You need a platform which is stable. Right now all our CI runs on
> virtualized instances, and I don't think there's any particular guarantee
> it'll be the
There's several issues involved in doing automated regression checking for
benchmarks:
- You need a platform which is stable. Right now all our CI runs on
virtualized instances, and I don't think there's any particular guarantee
it'll be the same underlying hardware, further virtualized systems te
Floren,
Just just need to send a patch to gerrit.
>From you local repo, do the necessary fixes and be sure everything is just
as you want.
Then simply run:
#git commit -a --amend
#git review
Thanks,
Edgar
On 10/20/13 11:26 AM, "Floren Llanos" wrote:
>Hello,
>
>I'm a newbie contributor in Ope
>From a user perspective, I want that a gate on changes which significantly
>degrade performance to be rejected.
Tempest (and its associated CI) provide a current check on functionality. It is
inline and understood.
Let's just add a set of benchmarks to Tempest which can validate that improved
Hello,
I'm a newbie contributor in Openstack, and I'm newbie using git and gerrit too.
I committed a change to gerrit of two files but one of them is not
correct and I must to undo the change (only one of this files). I need
to remove this file from gerrit and leave only one.
I found in http://g
Hi Sean,
>> Honestly, there has been so much work done in Tempest with the stress
tests and the scenario tests in this release, and a large growing community
around those, that it doesn't make any sense to me that you put item #3 as
a non Tempest thing.
I really don't like to copy paste function
OK Dan,
On 20 October 2013 16:08, Dan Smith wrote:
> > I'm afraid I really need help now - in particular on how to add a
> > suitable test case. I've been looking at
> > /opt/stack/nova/nova/tests/compute/test_compute_api.py running
> > test_create_quota_exceeded_messages under the debugger to
OK Dan,
On 20 October 2013 16:08, Dan Smith wrote:
> > I'm afraid I really need help now - in particular on how to add a
> > suitable test case. I've been looking at
> > /opt/stack/nova/nova/tests/compute/test_compute_api.py running
> > test_create_quota_exceeded_messages under the debugger to
Notifications work great.
Actually StackTach has a web interface where you can watch the notifications
coming through in real-time. We're slowing trying to get Ceilometer to have
this functionality.
StackTach works with Nova and Glance events currently.
https://github.com/rackerlabs/stacktach
Please get more detail from https://wiki.openstack.org/wiki/SystemUsageData
Thanks,
Jay
2013/10/19 Gabriel Hurley
> The answer is “sort of”. Most projects (including Nova) publish to an
> RPC “notifications” channel (e.g. in rabbitMQ or whichever you use in your
> deployment). This is how Ce
It might be worth both documenting this limitation on the admin guide and
provide a fix which we should backport to havana too.
It sounds like the fix should not be too extensive, so the backport should
be easily feasible.
Regards,
Salvatore
On 18 October 2013 21:50, Édouard Thuleau wrote:
> H
two questions here:
1. whther '--all-tenants' should be with '--tenant' or not.
2. can admin see other tenant's server using its name instead of id?
2013/10/16 Robert Collins
> I think that would be fine: --tenant FOO implying 'show me results
> from FOO if I have access to that' makes total se
On 2013-10-20 13:00:31 + (+), Jeremy Stanley wrote:
[...]
> automated job which proposes changes to a copyright holders list
> in each project by running a query with the author and date of
> each commit looking for new affiliations
[...]
Though the more I think about this, it would be com
On 2013-10-20 20:57:56 +0800 (+0800), Thomas Goirand wrote:
> Well, good luck finding all the copyright holders for such a large and
> old project. It's not really practical in this case, unfortunately.
To a great extent, the same goes for projects a quarter the size and
age of the Linux kernel--d
Dave Kranz has been building a system so that we can ensure that during
a Tempest run services don't spew ERRORs in the logs. Eventually, we're
going to gate on this, because there is nothing that Tempest does to the
system that should cause any OpenStack service to ERROR or stack trace
(Errors
On 2013-10-20 22:20:25 +1300 (+1300), Robert Collins wrote:
[...]
> OTOH registering one's nominated copyright holder on the first
> patch to a repository is probably a sustainable overhead. And it's
> probably amenable to automation - a commit hook could do it locally
> and a check job can assert
On 10/20/2013 05:41 PM, Joe Gordon wrote:
> http://ftp-master.metadata.debian.org/changelogs//main/l/linux/linux_3.11.5-1_copyright
>
> Not even the kernel itself has a complete list of all the copyright owners.
>
> best,
> Joe
Well, good luck finding all the copyright holders for such a large a
On Oct 20, 2013 11:29 AM, "Robert Collins"
wrote:
>
> On 20 October 2013 02:35, Monty Taylor wrote:
>
> > However, even as a strong supporter of accurate license headers, I would
> > like to know more about the FTP masters issue. I dialog with them, as
> > folks who deal with this issue and its r
On 20 October 2013 02:35, Monty Taylor wrote:
> However, even as a strong supporter of accurate license headers, I would
> like to know more about the FTP masters issue. I dialog with them, as
> folks who deal with this issue and its repercutions WAY more than any of
> us might be really nice.
D
On 20 October 2013 04:50, Jeremy Stanley wrote:
> Well, this is still a fuzzy topic. We have a lot of contributions
> and know who the authors are, but not necessarily who the copyright
s/authors/submitters/. I've heard (though I lack direct evidence) that
some teams funnel their patches through
On 10/19/2013 11:50 PM, Jeremy Stanley wrote:
> On 2013-10-19 23:29:28 +0800 (+0800), Thomas Goirand wrote:
>> Though the Debian FTP masters seems to insist on having correct
>> copyright holders in debian/copyright, and I am a bit lost after the 2
>> rejects I just had.
>
> Well, this is still a
28 matches
Mail list logo
