From: Lance Bragstad [lbrags...@gmail.com]
Sent: Friday, June 03, 2016 1:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone][all] Incorporating performance feedback
into the review process
Here is a list
Agreed. A VM running Linux is the only way to really develop for OpenStack.
One could write the code on Windows and share it into the Linux VM to then be
run via tox or another test tool. Both VirtualBox and VMWare support sharing a
folder from your Windows host into the Linux guest.
This way
From: Robert Collins [robe...@robertcollins.net]
Sent: Tuesday, April 26, 2016 4:07 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] backwards compatibility followup
Here is the choice I think we're still struggling with:
- should we
The trick is to let devstack install and then switch openrc to
IDENTITY_API_VERSION=3. Both v2 and v3 endpoints are created already. The tools
just need to be told to use them.
From: kiran vemuri UH [kkvem...@uh.edu]
Sent: Monday, April 25, 2016 4:10 PM
To:
From: Fox, Kevin M [kevin@pnnl.gov]
Sent: Tuesday, April 19, 2016 12:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [devstack] openstack client slowness /
client-as-a-service
What about a plugin
A pluginless CLI that simply used REST calls rather than the
python-clientlibs should be able to launch in get to the business of
doing work in 0.2 seconds - counting time to load and parse clouds.yaml.
That time could be reduced - the time spent in occ parsing vendor json
files is not strictly
From: Ian Cordasco [sigmaviru...@gmail.com]
Sent: Tuesday, April 19, 2016 11:11 AM
To: Perry, Sean; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [devstack] openstack client slowness /
client-as-a-service
What Dan sees WRT a persistent client process, though, is a combination of
those two things: saving the Python loading and the Keystone round trips.
If I replace the import of openstack.shell with a main that just returns 0 in
the OSC entry point and time it the result floats around 0.030s on
From: Adam Young [ayo...@redhat.com]
Sent: Tuesday, April 19, 2016 7:06 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [devstack] openstack client slowness /
client-as-a-service
On 04/18/2016 09:19 AM, Daniel P. Berrange wrote:
There have
Lots and lots of choices out there :)
Github.com/stackforge/os-ansible-deployment -- this is a COMPLETE solution
using Docker. It is a good example of what is needed for a real deployment.
Github.com/lorin/devstack-vm - just a simple devstack running in Vagrant. You
could add here as needed to
-Original Message-
From: Doug Hellmann [mailto:d...@doughellmann.com]
Sent: Monday, July 13, 2015 3:41 PM
To: openstack-dev
Subject: Re: [openstack-dev] [all] Time to remove Python2.6 jobs from
master
Excerpts from Robert Collins's message of 2015-07-14 09:05:43 +1200:
On 14
According to Debian standards (which Ubuntu follows mostly) if a package ships
bash completion information that file belongs in /etc/bash_completion.d with a
file named after the package. You can look in that dir on an Ubuntu/debian box
and see the setup.
-Original Message-
From: Tony
BTW, see dh_bash-completion from the debhelper package. When in doubt about
packaging on a deb based distro look at the debhelper tools source (which is
perl).
-Original Message-
From: Perry, Sean
Sent: Wednesday, July 01, 2015 4:04 PM
To: OpenStack Development Mailing List
at 11:07:30PM +, Perry, Sean wrote:
BTW, see dh_bash-completion from the debhelper package. When in
doubt about packaging on a deb based distro look at the debhelper tools
source (which is perl).
-Original Message-
From: Perry, Sean
Sent: Wednesday, July 01, 2015 4:04 PM
14 matches
Mail list logo
