Hi,
With [1] merged, we now have people working on creating external
plugins for devstack.
I worry about use of arbitrary external locations as plugins for gate
jobs. If a plugin is hosted externally (github, bitbucket, etc) we
are introducing a whole host of problems when it is used as a gate
On 11/27/2014 12:59 PM, Li Tianqing wrote:
I write a module to extend openstack. When install by python
setup.py develop, it always blame this
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'pbr'
warnings.warn(msg)
...
Processing dependencies for
On 12/13/2014 07:03 AM, Danny Choi (dannchoi) wrote:
I would like to use devstack to deploy OpenStack on a multi-node setup,
i.e. separate Controller, Network and Compute nodes
Did you see [1]? Contributions to make that better of course welcome.
-i
[1]
On 12/04/2014 05:41 AM, Clint Byrum wrote:
What if the patch is reworked to leave the current trace-all-the-time
mode in place, and we iterate on each script to make tracing conditional
as we add proper logging?
I have run [1] over patchset 15 to keep whatever was originally using
-x tracing
On 12/02/2014 03:46 PM, Clint Byrum wrote:
1) Conform all o-r-c scripts to the logging standards we have in
OpenStack, or write new standards for diskimage-builder and conform
them to those standards. Abolish non-conditional xtrace in any script
conforming to the standards.
Honestly in the
On 12/03/2014 09:30 AM, Clint Byrum wrote:
I for one find the idea of printing every cp, cat, echo and ls command out
rather frustratingly verbose when scanning logs from a normal run.
I for one find this ongoing discussion over a flag whose own help says
-x -- turn on tracing not doing the
Hi,
My change [1] to enable a consistent tracing mechanism for the many
scripts diskimage-builder runs during its build seems to have hit a
stalemate.
I hope we can agree that the current situation is not good. When
trying to develop with diskimage-builder, I find myself constantly
going and
On 10/29/2014 12:42 AM, Doug Hellmann wrote:
Another way to do this, which has been used in some other projects,
is to define one option for a list of “names” of things, and use
those names to make groups with each field
I've proposed that in [1]. I look forward to some -1's :)
OTOH,
On 10/14/2014 04:03 PM, Ian Wienand wrote:
Maybe it is time for a release? One thing; does the pre-release check
run over TOT devstack and ensure there are no errors? We don't want
to release and then 10 minutes later gate jobs start failing.
Just to loop back on this ...
Our main goal here
I do not want to hijack this thread with Solaris specific questions,
but this point is a major sticking point for us too. To my
knowledge, modifying devstack for anything not RHEL/Ubuntu is out of
the question (they're not interested in supporting other OSes).
I think if the question is does
Hi,
I took the liberty of rebasing and approving the fairly obvious and
already +1'd bashate changes today that had been sitting for quite a
while. What's left is minimal and fall into three categories
1) changes for auto-detection. IMO, we should drop all these and just
leave bashate as
On 09/18/2014 09:49 AM, Clark Boylan wrote:
Recent sampling of test run times shows that our tempest jobs run
against clouds using PostgreSQL are significantly slower than jobs run
against clouds using MySQL.
FYI There is a possibly relevant review out for max_connections limits
[1], although
On 09/02/2014 10:13 PM, Sean Dague wrote:
One of the things that could make it better is to add file extensions to
all shell files in devstack. This would also solve the issue of gerrit
not syntax highlighting most of the files. If people are up for that,
I'll propose a rename patch to get us
On 09/03/2014 11:32 AM, Robert Collins wrote:
if-has-bash-hashbang-and-is-versioned-then-bashate-it?
That misses library files that aren't execed and have no #!
This might be an appropriate rule for test infrastructure to generate a
list for their particular project, but IMO I don't think we
On 08/29/2014 10:42 PM, Sean Dague wrote:
I'm actually kind of convinced now that none of these approaches are
what we need, and that we should instead have a .bashateignore file in
the root dir for the project instead, which would be regex that would
match files or directories to throw out of
On 08/27/2014 08:31 PM, Karanbir Singh wrote:
If you let me know what the issues with the Rackspace images are, I can
try to reach out and help them work through those.
The main issue was a verison of cloud-init installed via pip that
conflicted with packaged python. I put a work-around in
Hi,
I would like to get centos 7 based testing working, but I am stuck
without images being provided in the HP Cloud. Rackspace has a
(slightly quirky, but workable) image and we have an experimental job
that runs fine.
I am aware that building our own custom images with disk-image-builder
is
Hi,
By its nature, devstack tends to attract new contributors proposing a
wide-range of changes to just about every project under the Open Stack
banner.
These contributors often don't yet have the context to find the right
people to help with some +1's. It's also nice for people approving
the
On 07/16/2014 11:15 PM, Alexis Lee wrote:
What do you think about allowing some text after the words recheck no
bug?
I think this is a good idea; I am often away from a change for a bit,
something happens in-between and Jenkins fails it, but chasing it down
days later is fairly pointless given
Hi,
The current heat puppet modules don't work to create the heat config
file [1]
My first attempt [2] created separate config files for each heat
component. It was pointed out that configuration had been
consolidated into a single file [3]. My second attempt [4] did this,
but consensus seems
Hi,
I proposed a change to tempest that skips tests based on a config file
directive [1]. Reviews were inconclusive and it was requested the
idea be discussed more widely.
Of course issues should go upstream first. However, sometimes test
failures are triaged to a local/platform problem and it
On Thu, Aug 08, 2013 at 10:10:09AM -0300, Monty Taylor wrote:
I don't think we will gain much by auto-generating packages.
What really is the difference between devstack auto-generating a
package and having a human basically doing the same thing and sticking
it in a repo? It just seems
On Mon, Aug 05, 2013 at 12:03:07PM -0500, Dean Troyer wrote:
* proposals to use a tool to automatically decide between package and
PyPI (harlowja, sdague): this works well on the surface, but anything
that does not take in to account the dependencies in these packages
going BOTH ways is going
101 - 123 of 123 matches
Mail list logo
