> -Original Message-
> From: Vishvananda Ishaya [mailto:[email protected]]
> Sent: Friday, January 17, 2014 1:01 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: Jinbo (Justin)
> Subject: Re: [openstack-dev] question of vcpu-memory-hotplug progress
> Can you
On 17 Jan 2014, at 19:53, Jay Pipes wrote:
> On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote:
>> On 17 Jan 2014, at 16:10, Jay Pipes wrote:
>>
>>> On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote:
Hi all,
I've been looking at Neutron default LBaaS provider using
Hello Julien,
maybe my blog post helps you with some more details:
http://telekomcloud.github.io/2013/09/11/new-ways-of-tempest-stress-testing.html
You can run single test if you add a new json file with the test function you
want to test. Like:
https://github.com/openstack/tempest/blob/master/
Hi,
I haven’t read through those (need to go spend time with family so replying
quickly) but given the dates the planning phases for Quantum/Neutron LBaaS and
Libra LBaaS were at the same time.
There was an internal evaluation of the current LBaaS solutions done at the
time and it was believed
On Fri, Jan 17, 2014 at 11:03 PM, John Utz wrote:
> Outlook Web MUA, forgive the top post. :-(
>
> While a single import line that brings all the good stuff in at one shot
> is very convenient for the creation of an application, it would muddy the
> security picture *substantially* for the exact
I like the idea of a fresh start, but I don't think that's incompatible
with the other work to clean up the existing clients. That cleanup work
could help with creating the backwards compatibility layer, if a new
library needs to include one, for example.
As far as namespace packages and separate
On Jan 17, 2014, at 10:03 PM, John Utz wrote:
> Outlook Web MUA, forgive the top post. :-(
>
> While a single import line that brings all the good stuff in at one shot is
> very convenient for the creation of an application, it would muddy the
> security picture *substantially* for the exact
On Jan 18, 2014, at 8:13 AM, Doug Hellmann
mailto:[email protected]>> wrote:
I like the idea of a fresh start, but I don't think that's incompatible with
the other work to clean up the existing clients. That cleanup work could help
with creating the backwards compatibility layer, if
On Jan 18, 2014, at 12:00 AM, Jamie Lennox wrote:
> I can't see any reason that all of these situations can't be met.
>
> We can finally take the openstack pypi namespace, move keystoneclient ->
> openstack.keystone and similar for the other projects. Have them all based
> upon openstack.bas
On 01/18/2014 01:06 AM, Robert Collins wrote:
> On 17 January 2014 09:22, Renat Akhmerov wrote:
>> Since it’s pretty easy to get lost among all the opinions I’d like to
>> clarify/ask a couple of things:
>>
>> Keeping all the clients physically separate/combining them in to a single
>> library. Tw
Rob,
Please contact me, You have completely misunderstood the Solum project.
Thanks,
Adrian
On Jan 17, 2014, at 9:31 PM, "Raymond, Rob"
wrote:
>
> Hi Raj
>
> As I see it, Solum is a set of utilities aimed at developers to use
> OpenStack clouds but will not be part of OpenStack proper.
> W
On Jan 18, 2014, at 12:58 AM, Robert Collins wrote:
> Out of interest - whats the overhead of running tls compression
> against compressed data? Is it really noticable?
The overhead doesn’t really matter much as you want TLS
Compression disabled because of CRIME anyways. Most Linux
distros and
On Jan 18, 2014, at 9:58 AM, Jesse Noller wrote:
>
> On Jan 18, 2014, at 12:00 AM, Jamie Lennox wrote:
>
>> I can't see any reason that all of these situations can't be met.
>>
>> We can finally take the openstack pypi namespace, move keystoneclient ->
>> openstack.keystone and similar for
On Sat, 2014-01-18 at 03:31 +, Raymond, Rob wrote:
> I would like to gauge interest in a new project named Diesel.
>
> https://wiki.openstack.org/wiki/Diesel
>
> If you are already familiar with Savanna, the best way to describe it is:
> Savanna is to map reduce applications as Diesel is to w
On Sat, 2014-01-18 at 09:06 +, Andrew Hutchings wrote:
>
> On 17 Jan 2014, at 19:53, Jay Pipes wrote:
>
> > On Fri, 2014-01-17 at 17:03 +, Andrew Hutchings wrote:
> > > On 17 Jan 2014, at 16:10, Jay Pipes wrote:
> > >
> > > > On Fri, 2014-01-17 at 14:34 +0100, Thomas Herve wrote:
> > >
Hi,
Following-up on this thread (although late), I have detailed the steps
allowing to have Keystone with multiple domains properly set:
http://www.florentflament.com/blog/setting-keystone-v3-domains.html
I hope that it may be useful for people willing to play with the
Identity v3 API and domains
On Fri, 2014-01-17 at 13:12 -0800, Alex Freedland wrote:
> Andrew, Jay and all,
>
> Thank you for bringing this topic up. Incidentally, just a month ago
> at OpenStack Israel I spoke to Monty and other HP folks about getting
> the Libra initiatives integrated into LBaaS. I am happy that this
> di
On 01/15/2014 02:42 PM, Alexei Kornienko wrote:
> If you are working on linux system following can help you:
>
> dd if=/dev/urandom of=/dev/sda bs=4k
That's going to be slow.
The shred tool should be already installed on most Linux systems,
and uses an internal PRNG to write either zeros or rando
On 19 January 2014 04:48, Sean Dague wrote:
> On 01/18/2014 01:06 AM, Robert Collins wrote:
>> Launchpadlib which builds on wadllib did *exactly* that. It worked
>> fairly well with the one caveat that it fell into the ORM trap - just
>> in time lookups for everything with crippling roundtrips.
>
Hi all.
I might be a little out of context, but isn't that thing deployed on some
kind of cloud?
> * "cluster" -- is too generic, but also has connotations in HPC and
> various other technologies (databases, MQs, etc).
>
> * "installation" -- reminds me of a piece of performance art ;)
>
> * "in
Excerpts from Jay Pipes's message of 2014-01-18 11:02:12 -0800:
> Cutting to the chase... have there been any discussions about the
> long-term direction of Libra and Neutron LBaaS. I see little point
> having two OpenStack endpoints that implement the same basic load
> balancing functionality.
>
On Tue, Jan 14, 2014 at 6:09 PM, Doug Hellmann
wrote:
>
> On Mon, Jan 13, 2014 at 9:36 PM, Jamie Lennox wrote:
>
>> On Mon, 2014-01-13 at 10:05 -0500, Doug Hellmann wrote:
>> > What requirement(s) led to keystone supporting this feature?
>>
>> I've got no idea where the requirement came from howeve
Yes, this feature is used in real deployments just as Yuriy described. I
really want to avoid a new API version since we're just now getting solidly
into V3 being used more extensively. Is it unreasonable to have wsme allow
"extra values" in some manner? (I think that is the crux, is it something
jon,
please confirm a suspicion of mine.
the neutron-private-net-provisioning bp impl added a sock= parameter to
the ssh.connect call in remote.py
(https://github.com/openstack/savanna/commit/9afb5f60).
we currently require paramiko >= 1.8.0, but it looks like the sock param
was only added
MT:"Is your issue here that it's just called basic ops and you don't think
that's
reflective of what is being tested in that file anymore"
No.
My issue is, that the current scenario is, in fact, at least 2 separate
scenarios:
1. original basic_ops
2. reassociate_floating_ip
to which I would like
Hi Robert, Yonhong,
Although network XML solution (option 1) is very elegant, it has one major
disadvantage. As Robert mentioned, the disadvantage of the network XML is the
inability to know what SR-IOV PCI device was actually allocated. When neutron
is responsible to set networking configuratio
Yuriy, the idea is to choose something more or less general. 'Overcloud'
would be very specific to my taste. It could also create confusion for
users who want to depoy tests targets with other tools, like Fuel or
Devstack.
--
Best regards,
Oleg Gelbukh
On Sun, Jan 19, 2014 at 1:17 AM, Yuriy Tara
27 matches
Mail list logo
