[openstack-dev] [release] git-upstream 0.11.0 release

[Bailey, Darragh]

Pleased to announce the 0.11.0 release of git-upstream.


With source available at:

http://git.openstack.org/cgit/openstack/git-upstream

Please report any issues through launchpad:

https://bugs.launchpad.net/git-upstream


git-upstream is an open source Python application that can be used to
keep in sync with upstream open source projects, mainly OpenStack.

For more info on what git-upstream is for:

https://pypi.python.org/pypi/git-upstream



For more details see below.

Changes in git-upstream 0.10.1..0.11.0
--

b271750 Changelog for 0.11.0 Release
227be23 Ask rev-parse for shortest unique SHA1
a4342f4 Remove upstream branch requirement from '--finish'
394a9b7 Move logging setup earlier
f0f03b4 Support a finalize method for argument parsing
f41f3f9 Fix order of commits from previous imports
3d641bc Convert strategy tests to use scenarios
60aac04 Have pbr update AUTHORS but not changelog
ba47733 Fix manpage building
126feca Remove '\' from multiline strings
c13695d Improve detection of the previous import merge
5c523d6 Begin conversion to testscenarios
dcffac3 Include node 'name' in commit subject
0414e5f Update typos
2e45b55 Add more complex usage summary for import command
1621091 Tidy up fixture usage
7158716 Use standard library for text generation
49e87a2 Update ChangeLog with missing releases
795abb7 tests: Switch to use list as stack
ea9b4af Capture log messages for test failures
2631be6 Add option to perform finish only
33007ad Grammar fixes
be2bb18 Allow direct execution of main module
8f7f2f9 Change repository from stackforge to openstack
ada3917 Update .gitreview for new namespace
dc9567b Update the read-tree command in USAGE.md
3fb410c Re-factor and split code
ca9eefd Restructure subcommands parser creation
7e9436f Mask broken versions of mock
3384eb5 Sample jobs for mirroring upstream repositories
66004d0 Find additional missing commit scenarios
be0d8d6 Use DFS reverse topological sort to allow unordered inputs
0e6416d Make function private and replace boolean with function result
dfe55f6 Update hacking, enable some checks and fix style issues
964d5c7 Catch BadName exceptions from newer GitPython
e9bf6db Additional scenarios that result in missed commits
77e560f Add test for obsolete approach to track upstream
d4eeebc Refactor code used to build tree into helpers
589948b Add test support for creating carried changes
14122e2 Include graph of git log and node info on error
ed82333 Fix typo
80e1741 Workflow documentation is now in infra-manual

Diffstat (except docs and test files)
-

.gitchangelog.rc | 104 
.gitreview   |   2 +-
.mailmap |   2 +
AUTHORS  |  15 +-
ChangeLog| 281 +++
DESCRIPTION  |  12 +-
README.md|   4 +-
USAGE.md |   6 +-
build_manpage.py |   4 +-
contrib/jjb/defaults.yaml|   5 +
contrib/jjb/macros.yaml  |  74 +++
contrib/jjb/mirror.yaml  |  57 +++
contrib/jjb/projects.yaml|  11 +
contrib/jjb/scripts/mirror-upstream.bash |  64 +++
git_upstream/commands/__init__.py|  79 ++-
git_upstream/commands/drop.py| 130 +
git_upstream/commands/help.py|  40 ++
git_upstream/commands/import.py  | 796
+++
git_upstream/commands/supersede.py   | 215 ++---
git_upstream/lib/drop.py | 122 +
git_upstream/lib/importupstream.py   | 406 
git_upstream/lib/note.py |   3 +-
git_upstream/lib/pygitcompat.py  |   9 +-
git_upstream/lib/rebaseeditor.py |  27 +-
git_upstream/lib/searchers.py| 277 +++
git_upstream/lib/strategies.py   | 128 +
git_upstream/lib/supersede.py| 167 +++
git_upstream/log.py  |   6 +-
git_upstream/main.py |  64 +--
git_upstream/rebase_editor.py|  15 +-
git_upstream/subcommand.py   |  26 -
setup.cfg|   3 +
test-requirements.txt|   7 +-
tox.ini  |   3 +-
34 files changed, 1914 insertions(+), 1250 deletions(-)


Requirements updates


diff --git a/test-requirements.txt b/test-requirements.txt
index f2efc91..6db383b 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -1,2 +1,3 @@
-hacking>=0.5.6,<0.8
-mock
+hacking>=0.9,<=0.10.0
+loremipsum
+mock!=1.1.1,<=1.3.0
@@ -7,0 +9 @@ testrepository>=0.0.17
+testscenarios>=0.4
@@ -9,0 +12 @@ sphinxcontrib-programoutput
+PyYAML>=3.1.0

-- 
Regards,
Darragh Bailey
IRC: electrofelix
"Nothing is foolproof to a sufficiently talented fool" - Unknown
___

Re: [openstack-dev] Call for papers talk gone astray?

[Bailey, Darragh]

In case anyone else is looking at this:

On 16/02/16 17:43, Bailey, Darragh wrote:
> Anyone able to help out locate where the talk disappeared to as well as
> fixing my profile before the voting closes?

Jimmy McArthur has been kind enough to step in and take care of the
problem, much appreciated.


Appears it happens to a small number of talks each cycle, and I will be
taking care in the future to ensure that I both have exact copies of
what I've submited saved somewhere I can easily find them, and have
access to check immediately when they available for voting that they
have made it.

Lesson learnt... ;-)


Guess many have already voted and may not be planning to check again so
if the title "Practical Ansible hacks used to deploy an OpenStack
solution" peaks your interest 


--

Regards,
Darragh Bailey
IRC: electrofelix
"Nothing is foolproof to a sufficiently talented fool" - Unknown



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Call for papers talk gone astray?

[Bailey, Darragh]

Hi,


Submitted a talk for the upcoming summit (or at least I thought did
everything required for it to be included), however it appears to have
not appeared in the voting process. Title was "Practical Ansible hacks
used to deploy an OpenStack solution"

Looking around I've discovered that there is a problem with my profile
on the Openstack site, in that the public profile link,
https://www.openstack.org/community/members/profile/867, returns a 404
for me. Occam's razor suggests the two are related.


Anyone able to help out locate where the talk disappeared to as well as
fixing my profile before the voting closes?

-- 
Regards,
Darragh Bailey
IRC: electrofelix
"Nothing is foolproof to a sufficiently talented fool" - Unknown




signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Announcing a simple new tool: git-restack

[Bailey, Darragh]

I've got some git aliases that handle this, so I did a quick review to
see what might be useful additions to the tool.

  * Looks like passing of the branch should change the branch used for a
.gitreview file to parse
  o This looks to be unnecessary with newer git-review anyway, but
is probably a reasonable fallback for a while
  * Defaulting to looking for an explicit upstream using the
'@{u}' notation first looks like it would allow this tool to
work in any repo
  o newer git-review already sets this from 1.25


The aliases in case they help:

diverge-commit = !f() { git merge-base $(git show-upstream $@)
${1:-HEAD}; }; f
review-branch = !f() { git show ${1:-HEAD}:.gitreview | git config --get
--file - gerrit.defaultbranch || echo master;}; f
rework = !git rebase -i $(git diverge-commit $@)
show-upstream = !f() { git rev-parse --symbolic-full-name --abbrev-ref
${1}@{u} 2>/dev/null || git rev-parse --symbolic-full-name --abbrev-ref
$(git review-branch)@{u}; }; f

Regards,
Darragh Bailey
IRC: electrofelix
"Nothing is foolproof to a sufficiently talented fool" - Unknown

On 02/02/16 23:50, James E. Blair wrote:
> Paul Michali  writes:
>
>> Sounds interesting... the link
>> https://docs.openstack.org/infra/git-restack/ referenced
>> as the home page in PyPI is a broken link.
> I'm clearly getting ahead of things.  The correct link is:
>
>   http://docs.openstack.org/infra/git-restack/
>
> Thanks,
>
> Jim
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?

[Bailey, Darragh]

Hi Kevin,


At the moment don't think I'll be able to make it, however a number of
my colleagues will be there, so definitely an opportunity.


Be happy to start the discussion here so anyone not attending can get an
idea of where things are going.


My initial thoughts are that the first 2 places to focus for alignment
(assuming people agree with the idea of life cycle phases) would be:

a) abstract the different life cycle phases we have for HLM to be
controlled by a role var. (I'll elaborate more below)

b) Move the current var access in the defaults.yml that has knowledge of
config-processor output structure to be abstracted at the site level so
you can use the same roles whether it's with data from the hlm config
processor or another source (reusability is key). I guess could use
wrapper roles, but I think that's less desirable except for handling
edge cases or transition.


---

So what do I mean about the life cycle phases. As part of HLM, the idea
is to install and configure as much as possible across the entire cloud
and then perform the deploy/upgrade as a series of rolling service
starts/restarts at the same point. This differs from a normal
application of roles to nodes where the configure/install/start/restart
is done to each service on the node in sequence.

I'll leave debate of the pros/cons of each approach to another email. I
think the level of control is needed, and also roles should abstract the
information on how it is accomplished. Needing to know whether to
include a specific file from a role to perform a set of actions is
probably not desirable, seems to break the idea of abstraction behind
roles. Provide an interface and entry point with the main.yml, and try
not to care about it being implemented in a specific manner beyond this.

This is more about how we get from having plays that need to know which
file from each role to include to exact a specific phase in the life
cycle (install, configure, start, stop, upgrade, etc), to where if you
include the role by default it goes through all the needed phases, and
if you want to only enact a subset you set a role variable such as:

# play to just install/configure
  roles:
- { role: myrole, run_mode: [install, configure] }

# play to start
  roles:
   - { role: myrole, run_mode: [start] }

... etc.


I think we already suggested this to the monasca project to facilitate
the separation of applying the lifecycles for HLM while the default
behaviour of just executing all the needed tasks by default to bring the
service up without needing to fork the code. See
https://github.com/hpcloud-mon/ansible-monasca-agent/blob/master/tasks/main.yml


I would modify it to allow a list of phases to be applied by default, so
that the checks could be:

- include: stop.yml
  when: 'Stop' in run_mode


Thoughts?


Regards,
Darragh Bailey
IRC: electrofelix
"Nothing is foolproof to a sufficiently talented fool" - Unknown

On 29/01/16 23:42, Kevin Carter wrote:
> Thanks Bailey for the update. I intend to look over more of what you 
> folks have published really soon. Thanks again for putting all of this 
> out there and I hope to work with you and the team soon on more of the 
> convergence pieces.
> 
> I don't know if you or any of your team are headed to the OPS and or 
> OpenStack-Ansible midcycles in February but I'll be there and would love 
> the opportunity to work with folks while we're all in person.
> 
> Thanks again for publishing and have a good weekend.
> 



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?

[Bailey, Darragh]

Hi,


Those present at some of the Ansible collaboration sessions at Tokyo may
recall a mention about Helion Lifecycle Manager (HLM), which constituted
a collection of ansible playbooks and particular patterns used by the
HPE Helion OS 2.0 release to deploy clouds.

We promised at the time that we'd get the code out there to start some
discussions on where we could collaborate better with openstack-ansible.

I've already mentioned it to a few folks in IRC, however I think it's
worth sharing out a bit further.

The initial code for the difference ansible components has been uploaded
to GitHub under https://github.com/hpe-helion-os earlier this month.


https://github.com/hpe-helion-os/helion-input-model
Defines a cloud though a combination of service input definitions
(relatively static) and a topology that controls how network and the
services are laid out control the shape and size of the cloud desired.


https://github.com/hpe-helion-os/helion-configuration-processor
The processing engine that consumes the desired cloud topology
configuration from the input model, and generates all the hosts and
variables that are consumed by the ansible playbooks/roles to deploy the
requested cloud.


https://github.com/hpe-helion-os/helion-ansible
Contains all the ansible playbooks/roles used to deploy HPE's HOS 2.0.
This is run against the output of the helion-configuration-processor to
execute the build/upgrade of the cloud specification.


Obviously lots of discussions to be had and work to be done, and
hopefully with some help we should have a good idea by Austin as to what
will be needed to integrate some of the concepts into the existing
openstack-ansible project.


Enjoy the weekend :-)

-- 
Regards,
Darragh Bailey

"Nothing is foolproof to a sufficiently talented fool" - Unknown



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] How to do once off/infrequent meetings?

[Bailey, Darragh]

I was looking at using the meetings service
(https://wiki.openstack.org/wiki/Meetings) to run and log a meeting on a
stackforge project (git-upstream -
http://git.openstack.org/cgit/stackforge/git-upstream), which seems to
focus on reoccurring meetings.

So I'm wondering how best to register an adhoc meeting, I'm sure there
may be others in the future, but the project isn't at the point where it
would be useful to run a regular meeting.


I'm happy enough to just run this through the standard IRC channel in
this case, but I figured it might be better if I found out if it was
possible to use the meetings service?


btw, if anyone is interested in the project git-upstream the
discussion/meeting is happening tomorrow in the #git-upstream IRC
channel @5pm UTC.

-- 
Regards,
Darragh Bailey

Systems Software Engineer
Hewlett Packard Galway Ltd.
+353 91 75-4674

Postal Address:Hewlett Packard Galway Limited, Ballybrit Business Park, 
Galway 
Registered Office: Hewlett Packard Galway Limited, 63-74 Sir John Rogerson's 
Quay Dublin 2
Registered Number: 361933

___
The contents of this message and any attachments to it are confidential and may 
be legally privileged. If you have received this message in error you should 
delete it from your system immediately and advise the sender.
To any recipient of this message within HP, unless otherwise stated you should 
consider this message and attachments as "HP CONFIDENTIAL".




smime.p7s
Description: S/MIME Cryptographic Signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[Bailey, Darragh]

You may find the code for pip-compile
https://github.com/nvie/pip-tools/tree/future of interest for this, as I
think they may already have a solution for the deep dependency analysis.


I've started experimenting with it for git-upstream cause GitPython have
a habbit of breaking stuff through a couple of releases now :-(


What I like is:
* Doesn't require an extra tool before using 'pip install'
** Some may want to regen the dependencies, but it's optional and the
common python dev approach is retained
* Stable releases are guaranteed to use the versions of dependencies
they were released and verified against
* Improves on the guarantee of gated branch CI
** The idea that if you sync with upstream any test failures are due to
your local changes
** Which is not always true if updated deps can break stuff


On the flip side:
* You remain exposed to security issues in python code until you
manually update
* Development cycle doesn't move forward automatically, may not see
compatibility issues until late when forced to move forward one of the deps


Think the cons can be handled by some additional CI jobs to update the
pins on a regular basis and pass it through the standard gates and
potentially to auto approve during development cycles if they pass
(already getting the latest matching ones so no big diff here). Some
decisions on trade off around whether this should be done for stable
releases automatically or periodically requiring manual approval would
have to be made.


Did I say how much I like the fact that it doesn't require another tool
before just being able to use 'pip install'?


To experiment with it:
virtualenv .venv/pip-tools
source .venv/pip-tools/bin/activate
pip install git+https://github.com/nvie/pip-tools.git@future

Regards,
Darragh Bailey

"Nothing is foolproof to a sufficiently talented fool" - Unknown

On 22/01/15 03:45, Joshua Harlow wrote:
> A slightly better version that starts to go deeper (and downloads
> dependencies of dependencies and extracts there egg_info to get at
> these dependencies...)
>
> https://gist.github.com/harlowja/555ea019aef4e901897b
>
> Output @ http://paste.ubuntu.com/9813919/
>
> When ran on the same 'test.txt' mentioned below...
>
> Happy hacking!
>
> -Josh
>
> Joshua Harlow wrote:
>> A run that shows more of the happy/desired path:
>>
>> $ cat test.txt
>> six>1
>> taskflow<0.5
>> $ python pippin.py -r test.txt
>> Initial package set:
>> - six ['>1']
>> - taskflow ['<0.5']
>> Deep package set:
>> - six ['==1.9.0']
>> - taskflow ['==0.4.0']
>>
>> -Josh
>>
>> Joshua Harlow wrote:
>>> Another thing that I just started whipping together:
>>>
>>> https://gist.github.com/harlowja/5e39ec5ca9e3f0d9a21f
>>>
>>> The idea for the above is to use pip to download dependencies, but
>>> figure out what versions will work using our own resolver (and our own
>>> querying of 'http://pypi.python.org/pypi/%s/json') that just does a
>>> very
>>> deep search of all requirements (and requirements of requirements...).
>>>
>>> The idea for that is that the probe() function in that gist will
>>> 'freeze' a single requirement then dive down into further requirements
>>> and ensure compatibility while that 'diving' (aka, recursion into
>>> further requirements) is underway. If a incompatibility is found then
>>> the recursion will back-track and try a to freeze a different
>>> version of
>>> a desired package (and repeat...).
>>>
>>> To me this kind of deep finding would be a potential way of making this
>>> work in a way that basically only uses pip for downloading (and does
>>> the
>>> deep matching/probing) on our own since once the algorithm above
>>> doesn't
>>> backtrack and finds a matching set of requirements that will all work
>>> together the program can exit (and this set can then be used as the
>>> master set for openstack; at that point we might have to tell people to
>>> not use pip, or to only use pip --download to fetch the compatible
>>> versions).
>>>
>>> It's not completed but it could be complementary to what others are
>>> working on; feel free to hack away :)
>>>
>>> So far the following works:
>>>
>>> $ cat test.txt
>>> six>1
>>> taskflow>1
>>>
>>> $ python pippin.py -r test.txt
>>> Initial package set:
>>> - six ['>1']
>>> - taskflow ['>1']
>>> Traceback (most recent call last):
>>> File "pippin.py", line 168, in 
>>> main()
>>> File "pippin.py", line 162, in main
>>> matches = probe(initial, {})
>>> File "pippin.py", line 139, in probe
>>> result = probe(requirements, gathered)
>>> File "pippin.py", line 129, in probe
>>> m = find_match(pkg_name, req)
>>> File "pippin.py", line 112, in find_match
>>> return match_available(req.req, find_versions(pkg_name))
>>> File "pippin.py", line 108, in match_available
>>> " matches '%s' (tried %s)" % (req, looked_in))
>>> __main__.NotFoundException: No requirement found that matches
>>> 'taskflow>1' (tried ['0.6.1', '0.6.0', '0.5.0', '0.4.0', '0.3.21',
>>> '0.2', '0.1.3', '0.1.2', '0.1.1', '0.1'])
>>>
>>> I suspect all tha

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

[Bailey, Darragh]

On 15/01/15 23:41, Sean Dague wrote:
> On 01/15/2015 06:25 PM, Joe Gordon wrote:
>> We can side step the dependency graphing and ordering issue by looking
>> at the list of curently installed packages via pip freeze and not
>> installing dependencies (pip install --no-deps)
>>
>> After looking into this further here are the known issues:
>>
>> * Partial capping won't work [0], so we need to pin all dependencies, we
>> can generate this list per file via "pip install -r" and "pip freeze",
>> but this doesn't address the issue of apt-get vs pip install. For
>> example in the stable gate we use suds 0.4.1 but only suds 0.4.0 is
>> available via pip.
>> * Not all packages are installed in are standard dsvm-tempest env, so
>> using pip-freeze from that isn't enough
>> * We need to run this per requirements file and move to using pip
>> install --no-deps everywhere. As the global-requirements sync wouldn't
>> work the first time since files don't list all transient dependencies yet.
> So that's basically writing our own dependency system entirely, and
> skipping pip's (vs. fudging around pip's issues). I expect that's going
> to go poorly in the OpenStack ecosystem realm because a lot of very
> repetitive manual analysis will need to be done on each project. And if
> we want to bump a cap, regenerating all the graphs becomes another
> manual process.

Pip's loose dependency processing where each entry is treated as an
entirely separate resolution with no consideration of previous or later
constraints came up recently in a discussion at work.

Looking around I discovered someone had already started working on a
solution, which involves moving the current requirements to a
'requirements.in' file and then compiling that to requirements.txt,
which would contain only fully pinned packages in the correct order for
pip to install them without needing to add any special options.

Might be worth seeing if that could be developed further:
http://nvie.com/posts/better-package-management/
https://github.com/nvie/pip-tools/tree/future



>> * We can still break if a package version is removed from pypi
>> * in pip-freeze we sometimes install versions lower then our minimum
>> version (python-libvirt!)
> That's because python-libvirt is not in any requirements.txt file, so
> we're taking the system version.
>
>   -Sean
>

Regards,
Darragh Bailey

"Nothing is foolproof to a sufficiently talented fool" - Unknown


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

[Bailey, Darragh]

Hi Eduard,


I would check the trigger settings in the job, particularly which "type"
of pattern matching is being used for the branches. Found it tends to be
the spot that catches most people out when configuring jobs with the
Gerrit Trigger plugin. If you're looking to trigger against all branches
then you would want "Type: Path" and "Pattern: **" appearing in the UI.

If you have sufficient access using the 'Query and Trigger Gerrit
Patches' page accessible from the main view will make it easier to
confirm that your Jenkins instance can actually see changes in gerrit
for the given project (which should mean that it can see the
corresponding events as well). Can also use the same page to re-trigger
for PatchsetCreated events to see if you've set the patterns on the job
correctly.

Regards,
Darragh Bailey

"Nothing is foolproof to a sufficiently talented fool" - Unknown

On 08/12/14 14:33, Eduard Matei wrote:
> Resending this to dev ML as it seems i get quicker response :)
>
> I created a job in Jenkins, added as Build Trigger: "Gerrit Event:
> Patchset Created", chose as server the configured Gerrit server that
> was previously tested, then added the project openstack-dev/sandbox
> and saved.
> I made a change on dev sandbox repo but couldn't trigger my job.
>
> Any ideas?
>
> Thanks,
> Eduard
>
> On Fri, Dec 5, 2014 at 10:32 AM, Eduard Matei
>  > wrote:
>
> Hello everyone,
>
> Thanks to the latest changes to the creation of service accounts
> process we're one step closer to setting up our own CI platform
> for Cinder.
>
> So far we've got:
> - Jenkins master (with Gerrit plugin) and slave (with DevStack and
> our storage solution)
> - Service account configured and tested (can manually connect to
> review.openstack.org  and get events
> and publish comments)
>
> Next step would be to set up a job to do the actual testing, this
> is where we're stuck.
> Can someone please point us to a clear example on how a job should
> look like (preferably for testing Cinder on Kilo)? Most links
> we've found are broken, or tools/scripts are no longer working.
> Also, we cannot change the Jenkins master too much (it's owned by
> Ops team and they need a list of tools/scripts to review before
> installing/running so we're not allowed to experiment).
>
> Thanks,
> Eduard
>
> -- 
>
> *Eduard Biceri Matei, Senior Software Developer*
> www.cloudfounders.com
>  | eduard.ma...@cloudfounders.com
> 
>  
>
>  
> *CloudFounders, The Private Cloud Software Company*
>  
> Disclaimer:
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom
> they are addressed.If you are not the named addressee or an
> employee or agent responsible for delivering this message to the
> named addressee, you are hereby notified that you are not
> authorized to read, print, retain, copy or disseminate this
> message or any part of it. If you have received this email in
> error we request you to notify us by reply e-mail and to delete
> all electronic files of the message. If you are not the intended
> recipient you are notified that disclosing, copying, distributing
> or taking any action in reliance on the contents of this
> information is strictly prohibited.  E-mail transmission cannot be
> guaranteed to be secure or error free as information could be
> intercepted, corrupted, lost, destroyed, arrive late or
> incomplete, or contain viruses. The sender therefore does not
> accept liability for any errors or omissions in the content of
> this message, and shall have no liability for any loss or damage
> suffered by the user, which arise as a result of e-mail transmission.
>
>
>
>
> -- 
> *Eduard Biceri Matei, Senior Software Developer*
> www.cloudfounders.com
>  | eduard.ma...@cloudfounders.com
> 
>  
>
>  
> *CloudFounders, The Private Cloud Software Company*
>  
> Disclaimer:
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed.If you are not the named addressee or an employee or
> agent responsible for delivering this message to the named addressee,
> you are hereby notified that you are not authorized to read, print,
> retain, copy or disseminate this message or any part of it. If you
> have received this email in error we request you to notify us by reply
> e-mail and to delete all electronic files of the message. If you are
> not the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> informa