Re: [OpenStack-Infra] OpenStack Documentation for Preparing CI/CD Setup.

[Jay Pipes]

On 11/23/2016 09:17 AM, Amit Manel wrote:

However, I found few document that looks I can start with these and can
understand but these looks to be pretty outdated. Appreciate, if anyone
can share some more resources.

http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/


Yeah, as noted at the top of those articles, that information is really 
outdated at this point.


Best place to look for information is definitely 
http://docs.openstack.org/infra/system-config/third_party.html but I 
agree, it's a lot of reading.


Best,
-jay

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Zuul memory leak

[Jay Pipes]

Awesome detective work, Joshua, thank you!

-jay

On 02/03/2016 03:56 AM, Joshua Hesketh wrote:

Hey all,

So this took me a lot longer than I would have liked (the fact that I
pushed this up in the middle of a conference should be evidence), but I
believe I have managed to track this down:
https://review.openstack.org/#/c/275483/

We also have only ever been clearing our internal cache when reloading.
We should perhaps look at doing that periodically but that is a
different issue to the newly introduced leak. Although I haven't
checked, I suspect our cache is a lot larger recently (looking at cacti
and other metrics) probably due to cross-repo-dependencies so there is
more need to keep it clear. This may have contributed to the recent
larger memory use.

Cheers,
Josh

On Sat, Jan 9, 2016 at 7:20 AM, James E. Blair mailto:cor...@inaugust.com>> wrote:

Hi,

Some time before December 17th we merged a change to Zuul that causes a
memory leak.  Prior to then, the amount of used memory on OpenStack's
Zuul server consumed a very steady 5GB.  Now it continually increases.
We can see the behavior start very clearly with our December 17 restart
of Zuul.  But it had been running for quite some time (perhaps a month
or more?) before then, so that is not much use in narrowing down the
change, and several changes were merged in that time period that could
have an effect.

See this graph:


http://cacti.openstack.org/cacti/graph.php?action=zoom&local_graph_id=392&rra_id=4&view_type=&graph_start=1449499887&graph_end=1452197778&graph_height=120&graph_width=500&title_font_size=10

If anyone else running a Zuul from git master has observed increased
memory usage, would you please let us know any dates where you restarted
Zuul (with the latest commit) and either did or did not observe
increased memory usage?  That may help us quickly narrow down what we
need to look at.

Thanks,

Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra




___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev] [infra][stackalytics] some projects not visible in stackalytics now

[Jay Pipes]

Hi everyone, and happy New Year!

Ilya and a number of other Mirantis folks are currently on holiday until 
the 10th. I'm sure he will address the issues promptly upon his return.


All the best,
-jay

On 01/07/2016 09:34 AM, Michał Dulko wrote:

On 01/07/2016 02:59 PM, Shake Chen wrote:

seem some project not update many day.like

http://stackalytics.com/?project_type=openstack&module=kolla-group

the data still stay 02 Jan 2016



And I can report that for some users (like me [1]) actions are not
tracked since the beginning of 2016. I can assure that I've did quite a
few reviews and got some patches merged.

[1]
http://stackalytics.com/?metric=marks&release=mitaka&user_id=michal-dulko-f

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Thoughts on evolving Zuul

[Jay Pipes]

Jim, great stuff. A couple suggestions inline :)

On 02/26/2015 09:59 AM, James E. Blair wrote:

A tenant may optionally specify repos from which it may derive its
configuration.  In this manner, a repo may keep its Zuul configuration
within its own repo.  This would only happen if the main configuration
file specified that it is permitted::

   ### main.yaml (continued)
   - tenant:
   name: random-stackforge-project
   include:
- global_config.yaml
   repos:
- stackforge/random  # Specific project config is in-repo


Might I suggest that instead of a repos: YAML block, that instead, the 
include: YAML block allow URIs. So, to support some random Zuul config 
in a stackforge repo, you could do:


include:
 - global_config.yaml
 - https://git.openstack.org/stackforge/random/tools/zuul.yml

That would make the configuration simpler, I think.


Jobs defined in-repo may not have access to the full feature set
(including some authorization features).  They also may not override
existing jobs.

Job definitions continue to have the features in the current Zuul
layout, but they also take on some of the responsibilities currently
handled by the Jenkins (or other worker) definition::

   ### global_config.yaml
   # Every tenant in the system has access to these jobs (because their
   # tenant definition includes it).
   - job:
   name: base
   timeout: 30m
   node: precise   # Just a variable for later use
   nodes:  # The operative list of nodes
- name: controller
  image: {node}  # Substitute the variable
   auth:  # Auth may only be defined in central config, not in-repo
swift:
  - container: logs
   pre-run:  # These specify what to run before and after the job
- zuul-cloner
   post-run:
- archive-logs


++


Jobs have inheritance, and the above definition provides a base level
of functionality for all jobs.  It sets a default timeout, requests a
single node (of type precise), and requests swift credentials to
upload logs.  Further jobs may extend and override these parameters::

   ### global_config.yaml (continued)
   # The python 2.7 unit test job
   - job:
   name: python27
   parent: base
   node: trusty


Yes, this is great :)


Our use of job names specific to projects is a holdover from when we
wanted long-lived slaves on jenkins to efficiently re-use workspaces.
This hasn't been necessary for a while, though we have used this to
our advantage when collecting stats and reports.  However, job
configuration can be simplified greatly if we simply have a job that
runs the python 2.7 unit tests which can be used for any project.  To
the degree that we want to know how often this job failed on nova, we
can add that information back in when reporting statistics.  Jobs may
have multiple aspects to accomodate differences among branches, etc.::

   ### global_config.yaml (continued)
   # Version that is run for changes on stable/icehouse
   - job:
   name: python27
   parent: base
   branch: stable/icehouse
   node: precise

   # Version that is run for changes on stable/juno
   - job:
   name: python27
   parent: base
   branch: stable/juno  # Could be combined into previous with regex
   node: precise# if concept of "best match" is defined

Jobs may specify that they require more than one node::

   ### global_config.yaml (continued)
   - job:
   name: devstack-multinode
   parent: base
   node: trusty  # could do same branch mapping as above
   nodes:
- name: controller
  image: {node}
- name: compute
  image: {node}

Jobs defined centrally (i.e., not in-repo) may specify auth info::

   ### global_config.yaml (continued)
   - job:
   name: pypi-upload
   parent: base
   auth:
password:
  pypi-password: pypi-password
  # This looks up 'pypi-password' from an encrypted yaml file
  # and adds it into variables for the job

Pipeline definitions are similar to the current syntax, except that it
supports specifying additional information for jobs in the context of
a given project and pipeline.  For instance, rather than specifying
that a job is globally non-voting, you may specify that it is
non-voting for a given project in a given pipeline::

   ### openstack.yaml
   - project:
   name: openstack/nova
   gate:
queue: integrated  # Shared queues are manually built
jobs:
  - python27  # Runs version of job appropriate to branch
  - devstack
  - devstack-deprecated-feature:
  branch: stable/juno  # Only run on stable/juno changes
  voting: false  # Non-voting
   post:
jobs:
  - tarball:
  jobs:
- pypi-upload

Currently unique job names are used to build shared change queues.
Since job names will no longer be unique, shared queues must be
manually constru

Re: [OpenStack-Infra] [openstack-infra][jeepyb] Deprecating jeepyb-gerrit update_bug.py hook

[Jay Pipes]

On 12/11/2014 06:49 AM, Ricardo Carrillo Cruz wrote:

Hi there

I was writing a spec for an issue tracker agnostic update_bug.py on
Jeepyb when this Story comment from Khai came to my attention:

https://storyboard.openstack.org/#!/story/212

"
We should probably just deprecate jeepyb at this point. The Gerrit <->
Storyboard integrations should be done with a gerrit plugin and a
storyboard plugin. I'm working on the Gerrit plugin and it's currently
hosted upstream, initial change is here:
https://gerrit-review.googlesource.com/#/c/60590
"

Has this deprecation been agreed in a meeting or in the IRC channel?

Don't want to continue with the jeepyb work if we will switch to a
Gerrit-SB plugin solution.


Personally, I think jeepyb is useful in its own right, with or without 
Storyboard, so I hope by "deprecation" Khai means just not using jeepyb 
within the OpenStack CI platform, and not getting rid of jeepyb.


Best,
-jay

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [storyboard] Paging results

[Jay Pipes]

On 11/20/2014 10:38 AM, Michael Krotscheck wrote:

There is a rule in UX, which is quite simple: Always tell the user
exactly where they are.


There's also a rule in mailing list conversations... generally it's good 
to reply inline so that you can tell who you are replying to, what 
section of their response you are referring to, and generally helping 
the reader of the mailing list post figure out where they are. :)


Best,
-jay

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [storyboard] Paging results

[Jay Pipes]

On 11/19/2014 09:49 PM, Robert Collins wrote:

On 20 November 2014 13:43, Jay Pipes  wrote:

On 11/19/2014 07:32 PM, Michael Krotscheck wrote:


Jay-

My own UX tests have demonstrated a need for both page jumping, and
being able to communicate to a user where they are in their list. I'd be
happy to show you the videos if you have a few hours.



I don't have a few hours, no. :) But, what use case does jumping to page 7
of some results listing fulfill?


For one, remembering where you were and coming back to it (more or less).


Sorry, I don't get this at all. I have never, once, wanted to coming 
back to some random page of results. I often want to come back to a 
specific record, but that's not what we're talking about here.


I can think of no time in my life that I've thought to myself "Oh, you 
know, I really should go back to page 17 of my Google search results for 
'frobnozzle'". It just isn't a valid use case, IME.



Jumping by batch index is cheap compared to the proposed
clone-the-result-set-ids thing, and IME useful enough that I'd be
annoyed at a system without it.


What does "jump to page 17" give you -- usefulness-wise -- over seeing 
that there is a) X number of results in total and/or b) there are more 
results to page through?



@Michael - I suggest just using a simple stable batch marker - e.g.
the unique key of the edge of the batch - which is stable enough to
handle inserts and deletes without double-showing or skipping rows.


That's what already exists in olso.db.utils.paginate_query(). The marker 
is the unique key of the edge of the batch.


Best,
-jay

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [storyboard] Paging results

[Jay Pipes]

On 11/19/2014 07:32 PM, Michael Krotscheck wrote:

Jay-

My own UX tests have demonstrated a need for both page jumping, and
being able to communicate to a user where they are in their list. I'd be
happy to show you the videos if you have a few hours.


I don't have a few hours, no. :) But, what use case does jumping to page 
7 of some results listing fulfill?


Thanks,
-jay

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [storyboard] Paging results

[Jay Pipes]

On 11/19/2014 11:38 AM, Heald, Mike wrote:

Hello, fellow Storyboarders!

After some discussions with the folks working on oslo.db and going
over our requirements for paging with krotscheck, we came to the
conclusion that paging just based on a marker did not give us the
reliability or functionality that we need in Storyboard. I said I'd
outline the paging model I'd used before for companies whose
requirements were quite demanding (e.g. if we miss a record while
paging, we could potentially lose thousands in profits)


Pretty sure Storyboard paged results are not going to affect anyone's 
profit margin.



Goals:

1) Paged list where records do not jump from page to page, even if
the underlying data changes, so that the user never misses records
that match search criteria, and never sees the records she is dealing
with change unexpectedly


Is this use case really something to be worried about? Honestly, I don't 
think so.


> 2) Able to order the list by column

Nothing about marker/limit pagination prevents ordering by any column.

> 3) Able to jump to an arbitrary page

What about this last use case is useful? Why would I want to "jump to 
the 7th page of results"? Just being able to do something doesn't 
necessarily make it useful.



To fully satisfy (1) while having (2) and (3), we need to snapshot
the result set, and have a mechanism for notifying the user of any
new records that match the list criteria since they started
browsing.

This can be achieved by having a three column table, with a record
ID, the data used to order the results, and an ID for the result set.
This allows us to left join on the main data table (so that record
deletions do not affect paging, and the UI can show that a record was
deleted and not mess up paging). Ordering by the snapshotted data
means that if records change that data in the main data table, they
do not jump pages, and the UI can show that the data has changed.
This does require some resultset metadata too (e.g. column sorted
by)

Notifications of new records can be done with a web worker that
checks if there are records that do not appear in the search but do
match the search criteria. The user can be notified that new records
have come in, and opt to either view a list of these records, or
rerun the search to include them.

Downsides of this approach are: - It's relatively heavy. The search
table for each datatype will have lots of inserts and deletes, so
careful consideration of partitions, or use of temporary tables, or
other webscale stuff needs to happen - Housekeeping needs to be
thought about. Just viewing a list of stuff will result in a snapshot
so it can be manipulated correctly, so we need to think about if
there are situations when we *don't* want this to happen (for example
viewing a list of all stories might not warrant it, but viewing a
list of stories with a particular status, might), how to clean up
result set snapshots that are no longer in use, etc.

Upsides are: - It works. The results you are working with remain
consistent, you get notified of any data changes, and you can page
through the results easily. You could even use marker based paging
for the snapshotted results if you wanted to, and it would be
reliable (although some functionality like jumping to an arbitrary
page would be sacrified).

Hope that makes sense, what are everyone's thoughts?


I appreciate that you and others have put a lot of thought and time into 
this, but frankly, I just don't see that much benefit to the extra code 
complexity and time to deliver it.


Best,
-jay

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-infra] [third-party CI] Hardware requirements for setting up CI environment

[Jay Pipes]

Also note that you typically need at least 40G in disk space if you're 
running the tempest+devstack_gate tests...


-jay

On 10/31/2014 12:38 PM, Doug Wiegley wrote:

Some extra numbers, to explore the lower limits.  The A10/Neutron CI
uses the following VMs:

Jenkins/zuul/gearman, Ubuntu 14.04, 1 vcpu, 1GB ram (t2.micro)
Devstack-gate, Ubuntu 14.04, 1 vcpu, 4GB ram (t2.medium)

Note that 4GB doesn’t work if you enable swift; that needs 8gb and more
cores.

Since we run a subset of neutron, our test time is 18 minutes.  I need
three devstack-gate slaves to keep up with the gate crush, or about
9-10/hour total throughput.  One is plenty with the current level of
submissions.

Thanks,
doug

From: Amit Das mailto:amit@cloudbyte.com>>
Date: Friday, October 31, 2014 at 7:15 AM
To: Erlon Cruz mailto:sombra...@gmail.com>>
Cc: Marcus Vinícius Ramires do Nascimento mailto:marcus...@gmail.com>>, "openstack-infra@lists.openstack.org
"
mailto:openstack-infra@lists.openstack.org>>
Subject: Re: [OpenStack-Infra] [openstack-infra] [third-party CI]
Hardware requirements for setting up CI environment

Thanks a lot Erlon.

The document looks really good. Will update how our installation goes
through.

Regards,
Amit
/CloudByte Inc./ 

On Fri, Oct 31, 2014 at 6:25 PM, Erlon Cruz mailto:sombra...@gmail.com>> wrote:

Hi Amit, Bharat
Attached the tutorial.

On Fri, Oct 31, 2014 at 10:15 AM, Amit Das mailto:amit@cloudbyte.com>> wrote:

Thanks Erlon & Jeremy for the detailed responses.

Erlon, the configuration doc will definitely help us. Looking
forward to it.

Regards,
Amit
/CloudByte Inc./ 

On Fri, Oct 31, 2014 at 5:29 PM, Erlon Cruz mailto:sombra...@gmail.com>> wrote:

We have a CI for Cinder drivers. Currently we use 1 instance
for the master and 1 instance for each slave(we test one
driver on each slave). The configuration is the following:

Master: 2VCPUs + 8GB RAM
Slaves: 2VCPUs + 12GB RAM
Network: 4Mb Download + 4Mb Upload

Our jobs usually take 1:20h to run, but that is because of
the network. In our setup we virtualize all hosts using
VMWare, which is very handy as we can save an snapshot and
trigger a revert after the job is complete also, if you have
FC drivers, VMWare will save a lot of pain with it PCI
passthrought. We have an step by step to configure the env
with VMWare and Cinder drivers, if you need we can make it
available.


On Thu, Oct 30, 2014 at 1:24 PM, Jeremy Stanley
mailto:fu...@yuggoth.org>> wrote:

On 2014-10-30 20:28:17 +0530 (+0530), Amit Das wrote:
> This is exactly what we intend to do. Wanted to know if there 
is
> anything else that we should know before placing the requests.

In that case, if you're wanting to do devstack-gate
based jobs we
use instances with 8 VCPUs and 8 GB RAM. A typical
tempest-full run
takes somewhere in the vicinity of an hour to complete
depending on
what configuration options have been selected. Due to
the inability
to cleanly re-run DevStack or to trust that proposed
changes haven't
destroyed the usability of the worker instance, we
recycle and
replace them with fresh instances for each job.
--
Jeremy Stanley

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org


http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra







___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-infra][External CI][dsvm-tempest-full] Jenkins job failing at "Running devstack"

[Jay Pipes]

On 09/10/2014 04:19 AM, Eduard Matei wrote:

Hi guys,
I'm working on setting up a CI testing platform for the Cinder driver
we're developing.
I followed
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
and part 2, and i got both the master and the slave working, but the
dsvm-tempest-full job is failing.



2014-09-10 11:15:37.318 | error: The following untracked working tree files 
would be overwritten by checkout:



Any ideas how to fix this?


Hi Eduard,

I suspect, from looking at the above error, that you are re-using the 
slave instance on subsequent runs of Jenkins jobs. If you are doing this 
(as opposed to using something like nodepool to keep a pool of 
single-use slave VMs around for running Jenkins jobs, then you will need 
to run some sort of cleanup/reset script after the Jenkins job completes.


Akihiro Motoki has a nice repo with scripts you can use for this purpose:

https://github.com/amotoki/devstack-tools

(see the devstack-cleaner.sh script)

For best results, however, the upstream infrastructure team has 
definitely found that using single-use slave VMs, managed by nodepool, 
is the safest and cleanest way to handle Jenkins jobs that involve 
devstack-gate (like the jobs detailed in my joinfu.com posts).


All the best,
-jay

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] mysqlconnector and pypi vs oracle

[Jay Pipes]

On 07/11/2014 05:54 AM, Angus Lees wrote:

Given that mysql-connector is shipped by the official mysql devs (ie:
Oracle), I'm not much looking forward to convincing Oracle to ship their
software through another repo.   How important is this?  Do we have
other avenues available to us?


A number of us go way back at MySQL and know the maintainers of the 
connectors (Python and otherwise) as ex-colleagues. I'm pretty sure any 
of the connector maintainers would be happy to work with the community 
in the most effective ways possible, especially with a little assistance 
from our end.


If you need me to reach out to anyone there, I'd be happy to do so. Same 
goes for Percona and Monty Program AB (MariaDB folks), since both those 
companies also have old colleagues working there. I don't want to speak 
for Monty Taylor, but I'm pretty sure he wouldn't have a problem 
reaching out either, if he hasn't done so already.


Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev] [infra] Basic zuul merger startup

[Jay Pipes]

On Wed, 2014-04-23 at 20:40 +, Dane Leblanc (leblancd) wrote:
> Jay:
> 
> Thanks, your merger-logging.conf file helped me get further... the Jenkins 
> jobs are now being called after the merge.

Awesome news :)

> For the Jenkins job script... Is there a way to run DevStack and tell it to 
> clone one project (openstack/neutron, in my case) from the local merged repo, 
> but to clone all other projects from the usual github?  Is there a localrc 
> setting (e.g. NEUTRON_BRANCH) which can be used for this?

Yup, there is. There are environment variables (ZUUL_REF, ZUUL_PROJECT,
ZUUL_BRANCH, etc) that are passed by Gerrit to Zuul and may be used by
scripts to set up your environment.

Unless there's a *really* good reason not to, I would advise using the
upstream devstack-gate setup scripts to construct your environment.
These scripts understand the ZUUL_XXX variables and call devstack's
stack.sh script and set up all the plumbing for you to point the
Zuul-controlled Git repositories to either the SHA1 of the commit being
tested, or the HEAD of the master branches of other projects.

You can control the devstack-gate scripts with a dizzying array of
environment variables as well.

I'd recommend giving these articles a read. They will walk you through
devstack-gate and their integration with Zuul.

http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system/
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/

You can always find me on IRC #openstack-nova or #openstack-neutron. I'm
happy to help you.

Best,
-jay

> Thanks again,
> Dane
> 
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com] 
> Sent: Tuesday, April 22, 2014 6:22 PM
> To: Dane Leblanc (leblancd)
> Cc: openstack-infra@lists.openstack.org
> Subject: Re: [OpenStack-Infra] [openstack-dev] [infra] Basic zuul merger 
> startup
> 
> On Tue, 2014-04-22 at 20:05 +, Dane Leblanc (leblancd) wrote:
> > Jay:
> > 
> > Thanks for your help! I manually started the zuul-merger service, and 
> > things are progressing further, but with merge errors.
> > 
> > I'm not seeing a /var/log/zuul/zuul-merger.log, but I'm don't have the 
> > merger logging set up correctly in the zuul.conf. The zuul documentation 
> > suggests:
> > 
> > [merger]
> > log_config=/etc/zuul/logging.yaml
> > 
> > Do you know where I might find a sample logging.yaml?  (There's a 
> > logging.conf in the zuul repo, but that doesn't have anything that's 
> > zuul-merger specific).
> 
> Hmm, actually no, I'm not familiar with a logging.yaml file.
> 
> So, I checked out the upstream puppet module installation and I see this in 
> their zuul.conf [1]:
> 
> log_config=/etc/zuul/merger-logging.conf
> 
> You can see the merger-logging.conf file here:
> 
> https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/merger-logging.conf
> 
> I'd just go ahead and copy that to /etc/zuul/merger-logging.conf
> 
> Best,
> -jay
> 
> [1]
> https://git.openstack.org/cgit/openstack-infra/config/tree/modules/zuul/templates/zuul.conf.erb
> 
> 
> 



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev] [infra] Basic zuul merger startup

[Jay Pipes]

On Tue, 2014-04-22 at 20:05 +, Dane Leblanc (leblancd) wrote:
> Jay:
> 
> Thanks for your help! I manually started the zuul-merger service, and things 
> are progressing further, but with merge errors.
> 
> I'm not seeing a /var/log/zuul/zuul-merger.log, but I'm don't have the merger 
> logging set up correctly in the zuul.conf. The zuul documentation suggests:
> 
> [merger]
> log_config=/etc/zuul/logging.yaml
> 
> Do you know where I might find a sample logging.yaml?  (There's a 
> logging.conf in the zuul repo, but that doesn't have anything that's 
> zuul-merger specific).

Hmm, actually no, I'm not familiar with a logging.yaml file.

So, I checked out the upstream puppet module installation and I see this
in their zuul.conf [1]:

log_config=/etc/zuul/merger-logging.conf

You can see the merger-logging.conf file here:

https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/merger-logging.conf

I'd just go ahead and copy that to /etc/zuul/merger-logging.conf

Best,
-jay

[1]
https://git.openstack.org/cgit/openstack-infra/config/tree/modules/zuul/templates/zuul.conf.erb




___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [openstack-dev] [infra] Basic zuul merger startup

[Jay Pipes]

On Tue, 2014-04-22 at 16:49 +, Dane Leblanc (leblancd) wrote:
> I’m trying to get zuul running on a 3rd party  test setup, but the
> merge does not seem to be happening. I suspect that I’m just not
> configuring the zuul merger correctly, or I’m missing some basic
> startup step.
> 
> In my setup, it’s a single node on which I’m trying to run zuul,
> Jenkins, gearman, etc. (everything co-located).  I’m using the
> “IndependentPipelineManager” since this is for (not yet approved) code
> reviews.  The zuul debug logs show that jobs are being submitted to
> merger, but those jobs are never submitted to Jenkins.

What is in /var/log/zuul/zuul-merger.log? Could you pastebin it?

> The nc (netcat) utility shows that merger has messages in its queue,
> but there’s no worker for merger: 
> 
> neutronpluginsci:/var/log/zuul$ echo status | nc -q 3 localhost 4730
> 
> build:neutron   0   0   2
> merger:merge53  0   0 < = = = No worker
> zuul:get_running_jobs   0   0   1
> set_description:172.24.4.1  0   0   1
> build:neutron_sandbox   0   0   2
> stop:172.24.4.1 0   0   1
> zuul:enqueue0   0   1
> zuul:promote0   0   1 
> 
> Some beginner questions:

> (Likewise, should I be using ‘git_user_name=zuul’ here, or the git
> user for our 3rd party gerrit account?

Your 3rd party gerrit account.

> (2)  Given that I’m using IndependentPipelineManager, is there a way I
> can bypass the merger process?

No.

> (3)  Is the merger/merge process automatically started by zuul or
> gearman, and if so, how to debug its startup?

No, you need to start it with something like:

 sudo service zuul-merger start

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Third Party Testing!

[Jay Pipes]

On Sat, 2014-04-12 at 15:37 +0800, Longgeek wrote:
> How to apply for third party testing account?

Hi :) Please see here for instructions:

http://ci.openstack.org/third_party.html#requesting-a-service-account

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB release?

[Jay Pipes]

On Wed, 2014-03-12 at 09:01 -0700, James E. Blair wrote:
> Khai suggested it's time (or past time) for a JJB release.  Antoine
> points out that before merging thread and pbr support might be a good
> time for a release too.  I note that we just fixed python 2.6 support as
> well.  So how about I tag:
> 
> 6e72dc3781fcaed1526317c27762fba44cd8a43e
> 
> as 0.7.0?

++


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [3rd party testing] Q&A meeting today at 14:00 EST / 18:00 UTC

[Jay Pipes]

Hi Stackers,

We'll be having our second weekly Q&A/workshop session around third
party testing today at 14:00 EST / 18:00 UTC in #openstack-meeting on
Freenode IRC. See you all there.

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Unable to connect to puppetdb server!

[Jay Pipes]

On Wed, 2014-03-05 at 23:19 +0530, Vinay Mahuli wrote:
> My requirement is to set-up my own ci infra for a open source product
> (This product sits on top of openstack).
> The first thing which we did is to
> go-through http://ci.openstack.org/running-your-own.html
> The "initial step" in this link contains
> http://ci.openstack.org/puppet.html#id2

OK.

> I have set-up 6 hosts(puppetmaster, review, jenkins-master,
> jenkins-slave, zuul, puppetdashboard) in my infrastructure.
> 1. Can you suggest me the right approach?

There are multiple right approaches. The one I took was to use the
upstream openstack-infra/config puppet modules and bash scripts as much
as possible, since those are what the infra team knows well and has
experience with.

> 2. Can you give me some more info on using the install_master.sh
> script from the os-ext-testing
> repository?

Please see my blog articles here for information about this:

http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system/
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/

Best
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Unable to connect to puppetdb server!

[Jay Pipes]

On Wed, 2014-03-05 at 17:10 +0530, Vinay Mahuli wrote:
> Hi,
> 
> From the link,  http://ci.openstack.org/puppet.html#id2, 
> 
> The command "puppet apply
> --modulepath='/opt/config/production/modules:/etc/puppet/modules' -e
> 'include openstack_project::puppetmaster' " doesn't work.

You do not need to run puppetmaster.

Are you using the install_master.sh script from the os-ext-testing
repository? If not, I'd recommend it. It runs scripts to install puppet,
Jenkins, Gearman, Jenkins Job Builder and other stuff you need.

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [Third Party CI] Reminder: Workshop/Q&A meeting on #openstack-meeting today at 13:00EST/18:00 UTC

[Jay Pipes]

On Mon, 2014-03-03 at 16:53 +, trinath.soman...@freescale.com wrote:
> Hi Jay-
> 
> I have the following doubts with my CI setup.
> 
> Hope presenting them before the meeting might help me with some more 
> guidance. 
> 
> [1] sandbox-dvsm-tempest-full runs all the test cases where few fail, causing 
> the completed build to fail. 
> How to restrict the testcases?
> Please find the errors.txt as an attachment to this email. This time VM 
> (cirros) failed. 
> 
> [2] After the build is failed, still services like nova, swift are running. 
> Does Jenkins using devstack unstack the stack.
> 
> [3] For some tempest test cases, I get the message "Neutron skipped" but in 
> the devstack logs, neutron is installed from git. Do I need to configure 
> something more for neutron.
> 
> [4] For services like Neutron, do we need to test cinder, nova, heat, swift 
> etc.. too ??

All: For reference, we answered the above questions on an etherpad here:

https://etherpad.openstack.org/p/third-party-ci-workshop

We will continue to add information to the above etherpad in the coming
weeks.

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [Third Party CI] Reminder: Workshop/Q&A meeting on #openstack-meeting today at 13:00EST/18:00 UTC

[Jay Pipes]

Hi all,

Just a friendly reminder we will have a workshop and Q&A meeting on
Freeonde #openstack-meeting channel today at 18:00 UTC (13:00 EST) for
folks interested in setting up or debugging third party CI platforms.

See you there!

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [third-party-ci] Proposing a regular workshop/meeting to help folks set up CI environments

[Jay Pipes]

On Wed, 2014-02-26 at 12:09 +, trinath.soman...@freescale.com wrote:
> Hi Jay-
> 
> Rather than March 3rd 
> 
> Can you kindly make it on Feb 28th if possible.

Unfortunately, Trinath, I can't make it tomorrow during that time. I can
try and be on IRC earlier in the day, though, to help you?

> I'm interested in attending the meeting. 
> 
> I have doubts to get clarified regarding setp, configuration and CI system.

Please let me know what your issues are and I'll try to answer you asap.

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [third-party-ci] Proposing a regular workshop/meeting to help folks set up CI environments

[Jay Pipes]

On Tue, 2014-02-25 at 20:02 -0300, Arx Cruz wrote:
> Hello,
> 
> Great Idea, I'm very interested!
> 
> I wasn't able to see the Google Hangout Event, is the url correct?

Hi Arx!

We changed from Google Hangout to using IRC. See here for more info:

http://lists.openstack.org/pipermail/openstack-dev/2014-February/028124.html

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [third-party-testing] CHANGED TIME and VENUE: Workshop/Q&A session on third party testing will be on IRC now!

[Jay Pipes]

Hi again Stackers,

After discussions with folks on the infrastructure team, I'm making some
changes to the proposed workshop venue and time. As was rightly pointed
out by Jim B and others, we want to encourage folks that are setting up
their CI systems to use the standard communication tools to interact
with the OpenStack community. That standard tool is IRC, with meetings
on Freenode. In addition, Google Hangout is not a free/libre piece of
software, and we want to encourage free and open source contribution and
participation.

Alright, with that said, we will conduct the first 3rd party OpenStack
CI workshop/Q&A session on Freenode IRC, #openstack-meeting on Monday,
March 3rd, at 13:00 EST (18:00 UTC):

https://wiki.openstack.org/wiki/Meetings#Third_Party_OpenStack_CI_Workshop_and_Q.26A_Meetings

Unlike regular OpenStack team meetings on IRC, there will not be a set
agenda. Instead, the IRC channel will be reserved for folks eager to get
questions about their CI installation answered and are looking for some
debugging assistance with Jenkins, Zuul, Nodepool et al.

I look forward to seeing you there!

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [third-party-ci] Proposing a regular workshop/meeting to help folks set up CI environments

[Jay Pipes]

Hi Stackers,

I've been contacted by a number of folks with questions about setting up
a third-party CI system, and while I'm very happy to help anyone who
contacts me, I figured it would be a good idea to have a regular meeting
on Google Hangouts that would be used as a Q&A session or workshop for
folks struggling to set up their own environments.

I think Google Hangouts are ideal because we can share our screens (yes,
even on Linux systems) and get real-time feedback to the folks who have
questions.

I propose we have the first weekly meeting this coming Monday, March
3rd, at 10:00 EST (07:00 PST, 15:00 UTC).

I created a Googe Hangout Event here:

http://bit.ly/1cLVnkv

Feel free to sign up for the event by selecting "Yes" in the "Are you
going?" dropdown.

If Google Hangouts works well for this first week, we'll use it again.

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] External Testing :: install-master.sh errors

[Jay Pipes]

On Wed, 2014-02-19 at 13:36 +, trinath.soman...@freescale.com wrote:
> Hi Jay-
> 
>  
> 
> Its resolved,
> 
> It’s a Capital letters issue with the node hostname.

OK, good :)
> 
>  But then, I have found the following.

> Duplicate declaration: A2mod[proxy_http] is already declared in
> file /root/os-ext-testing/puppet/modules/os_ext_testing/manifests/master.pp 
> at line 40; cannot redeclare at 
> /root/config/modules/zuul/manifests/init.pp:242 on node 
> freescale-openstack-ci.ap.freescale.net

Yup, it's a bug in upstream openstack-infra/config. I've submitted a
patch here:

https://review.openstack.org/#/c/74443/

Feel free to apply that patch to the /root/config source tree on your
master node.

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] [third party testing] Article series on setting up an external CI system

[Jay Pipes]

Hi all,

There have been efforts recently by lots of folks, particularly in the
Nova, Neutron, and Cinder contributor communities, trying to set up a
third-party testing platform that can get notified by the upstream
OpenStack CI system, run tests, and post votes on code reviews upstream.

Partly in response to these efforts, and partly due to the
recently-announced Mirantis push to "open source" driver certification
procedures [1], I wrote a series of blog articles that describe both how
the upstream CI system works, as well as provide some instructions on
setting up an external CI system yourself in a (mostly) automated
fashion.

http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/

I hope that folks find these articles useful. Feedback, criticism, and
error corrections are very much welcomed. Please do let me know, either
on the ML or on blog comments, if there are specific things or examples
you would like me to cover further.

Best,
-jay

[1]
http://www.mirantis.com/blog/openstack-will-open-source-vendor-certifications/



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Error with install_master

[Jay Pipes]

On Mon, 2014-02-17 at 15:41 +, trinath.soman...@freescale.com wrote:
> Hi Jay
> 
> Okay, let me frame this way.
> 
> The configuration is intended for sandbox project. for cinder project do I 
> need to change it to cinder or leave it to sandbox as it is.

Ah, I see now what you are referring to.

You can do whatever you'd like to the example Jenkins jobs configs I put
in my example data repository. Copy them, delete them, change them,
whatever you want.

If, for example, you wanted to run the sandbox-dsvm-tempest-full job
against cinder (instead of openstack-dev/sandbox project), you would
change the etc/jenkins_jobs/config/projects.yaml in your data repository
from this:

- project:
name: sandbox
github-org: openstack-dev
node: master

jobs:
- sandbox-noop-check-communication
- sandbox-dsvm-tempest-full:
node: devstack_slave

to this:

- project:
name: cinder
github-org: openstack
node: master

jobs:
- sandbox-dsvm-tempest-full:
node: devstack_slave

(you can change the name of the sandbox-dsvm-tempest-full job to
something else as well if you like).

In the etc/zuul/layout.yaml file, you would add the Cinder project  to
the projects section like this:

- project:
name: cinder
github-org: openstack
node: master

jobs:
- sandbox-noop-check-communication
- sandbox-dsvm-tempest-full:
node: devstack_slave

Due to the confusion around this, I think I might change the example
data repository and change sandbox.yaml to just tests.yaml, and remove
the sandbox- prefix from those job names (since they can clearly be run
for any project).

I will update the latest article accordingly. Thanks for your patience,
Trinath!

-jay




___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Error with install_master

[Jay Pipes]

On Mon, 2014-02-17 at 12:35 +, trinath.soman...@freescale.com wrote:
> Hi Jay-
> 
> From the blog,  the following lines suggest the configuration of
> sanbox
> 
> Set Your Vendor Name in the Test Jenkins Job
> 
> Next, open up the file etc/jenkins_jobs/config/sandbox.yaml in your
> data repository. Change the following line in it:
> 
> echo "Hello world, this is MyVendor's Testing System"
> 
> Change MyVendor to your organization’s name.
> 
> But then , Will vary for other openstack projects like cinder, neutron
> etc..

Not sure I understand you... you need to change "MyVendor" to your
organization's name, not the name of the project.

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Running devstack in a Jenkins job within an LXC container

[Jay Pipes]

On Mon, 2014-02-17 at 08:16 +1300, Robert Collins wrote:
> On 15 February 2014 14:43, Jeremy Stanley  wrote:
> > On 2014-02-14 20:31:38 -0500 (-0500), Jay Pipes wrote:
> > [...]
> >> At the end you will note something about leaked file descriptors. I'm
> >> not sure if this is actually the cause of the failure of the job or not,
> > [...]
> >
> > That's typical. Jenkins thinks it should warn you if your job
> > creates any files outside the workspace since it assumes anything
> > leaking out of that sandboxed area might be unintended. Pretty much
> > all of DevStack operates outside the workspace, so it's just
> > something we generally ignore in the output.
> >
> > Chances are something returned a nonzero, probably the apt-get
> > install command. Note that open-iscsi failed to start, resulting in
> > "dpkg: error processing open-iscsi (--configure): subprocess
> > installed post-installation script returned error exit status 1". In
> > cases like these, apt-get will continue to process the remaining
> > packages but then return with a nonzero exit code once it's done.
> 
> This may be of interest:
> https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855
> 
> tl;dr - it's currently impossible to run a bunch of necessary commands
> in a full lxc container - you need to expose non-namespaced things.

Thanks, Rob (and Chuck Short) for your links to LXC-related oddities. I
will read through those links and see if I can make progress. If not, no
probs, I'll just switch to a non-shared-kernel VM.

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Running devstack in a Jenkins job within an LXC container

[Jay Pipes]

Hi Dean, Infra-team,

I've been trying to get full Tempest test runs on Jenkins slave nodes in
an external testing system [1]

The slave nodes are running in LXC containers on my workstation, but I
am getting odd errors about halfway through the execution of stack.sh
during the job run.

Here is the console output from the Jenkins job in question [2]:

http://paste.openstack.org/show/65632/

At the end you will note something about leaked file descriptors. I'm
not sure if this is actually the cause of the failure of the job or not,
and I'm hoping you might have seen this before and have some ideas on
workarounds?

All the best, and thanks in advance for any thoughts,
-jay

[1]
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
[2] Job definition:
https://github.com/jaypipes/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/sandbox.yaml#L14


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing

[Jay Pipes]

On Fri, 2014-02-14 at 08:54 +0900, Akihiro Motoki wrote:
> Hi,
> 
> I wrote a blog post about how to setup Zuul manually.
> http://ritchey98.blogspot.jp/2014/02/openstack-third-party-testing-how-to.html
> 
> It covers how to migrate from Gerrit Trigger plugin to Zuul and
> some tips including a way to define vendor-specific recheck trigger
> in addition to the setup procedure.
> 
> Jay's puppet manifest is nice, but I hope the manual installation step
> is also helpful to set up 3rd party testing.

Thanks Akihiro-san,

I just put up the second article in the series that walks through
installation of a Jenkins master, Zuul, and Jenkins Job Builder and
testing communication with upstream:

http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/

Feedback very much welcomed. Working on the slave setup article now...

Best,
-jay

> On Fri, Feb 14, 2014 at 5:39 AM, Jay Pipes  wrote:
> > On Thu, 2014-02-13 at 12:34 -0800, Sukhdev Kapur wrote:
> >> Jay,
> >>
> >> Just an FYI. We have modified the Gerrit plugin it accept/match regex
> >> to generate notifications of for "receck no bug/bug ###". It turned
> >> out to be very simple fix and we (Arista Testing) is now triggering on
> >> recheck comments as well.
> >
> > Thanks for the update, Sukhdev! Is this updated Gerrit plugin somewhere
> > where other folks can use it?
> >
> > I've got Zuul actually working pretty well in my os-ext-testing repo
> > now. Only problem remaining is with the Jenkins slave trigger (not
> > related to Gerrit...)
> >
> > Best,
> > -jay
> >
> >
> >
> > ___
> > OpenStack-Infra mailing list
> > OpenStack-Infra@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Error with install_master

[Jay Pipes]

On Fri, 2014-02-14 at 04:59 +, trinath.soman...@freescale.com wrote:
> Hi Jay-
> 
> For third party setup, do we need to have master and slave setup?

Yes. The reason is because you cannot run devstack-based tests on the
same node that you are running your Jenkins master. Devstack interferes
with way too much stuff with regards to networking and makes it
impossible to run on something other than a separate slave node.

Note that you don't need to have two separate physical machines. A VM or
LXC container should work just fine.

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing

[Jay Pipes]

On Thu, 2014-02-13 at 12:34 -0800, Sukhdev Kapur wrote:
> Jay, 
> 
> Just an FYI. We have modified the Gerrit plugin it accept/match regex
> to generate notifications of for "receck no bug/bug ###". It turned
> out to be very simple fix and we (Arista Testing) is now triggering on
> recheck comments as well.

Thanks for the update, Sukhdev! Is this updated Gerrit plugin somewhere
where other folks can use it?

I've got Zuul actually working pretty well in my os-ext-testing repo
now. Only problem remaining is with the Jenkins slave trigger (not
related to Gerrit...)

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] 3rd Party Testing

[Jay Pipes]

On Thu, 2014-02-13 at 16:08 +1100, Joshua Hesketh wrote:
> Hi Trinath,
> 
> Have you read up on these documents?
> 
> http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
> http://ci.openstack.org/third_party.html
> https://github.com/jaypipes/os-ext-testing

Thanks, Josh. Follow up article coming soon that goes over the
os-ext-testing repo usage. I'm still working on fixing issues with the
Jenkins slave setup.

Also, there is an example "data repo" here with instructions on the
README.md:

https://github.com/jaypipes/os-ext-testing-data

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Error with install_master

[Jay Pipes]

On Thu, 2014-02-13 at 11:11 +, trinath.soman...@freescale.com wrote:
> Hi Jay-
> 
> I’m working on 3rd party test setup using your github blog.

Ah, cool. Good to get some feedback. I'm still working on that repo,
though... having some issues getting the connectivity between master and
slave set up right now...

> I get this error when I run install_master.
> 
> root@Freescale-CI:~# ./install_master.sh 
> 
> Using data repository: https://github.com/jaypipes/os-ext-testing-data
> 
> Using upstream Gerrit user: freescale-ci
> 
> Puppet::Parser::AST::Resource failed with error ArgumentError: Could
> not find declared class os_ext_testing::master at line 88 on node
> freescale-ci.ap.freescale.net

You just need to git pull the latest code from the os-ext-testing
repo...

Best,
-jay



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Questions about Nodepool integration

[Jay Pipes]

On Mon, 2014-02-10 at 14:40 -0600, devdatta kulkarni wrote:
> Hi,
> 
> In the Solum project we are looking at various options for running
> a pool of worker nodes that will build images (deployment units (DUs) in 
> Solum terms) from user code.
> 
> For code managing aspects, we are in the process of extending Zuul with a 
> 'messaging' trigger.
> Once this trigger is received, we will kick off gearman workers to build the 
> DUs -- at least
> that is the high-level idea.
> 
> In this regards, I have following questions:
> 
> I was told that nodepool is the system that manages such worker nodes for 
> Zuul. I briefly looked at
> the nodepool repository (https://github.com/openstack-infra/nodepool) but did 
> not find
> any information about its integration points with Zuul and/or gearman. Where 
> should I look to find this
> information? 

You might want to read an article I wrote about the internals of the
upstream CI system:

http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/

There is a section [1] that covers Nodepool:

http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/#Assignment_of_a_Node_to_Run_a_Job

You can see the configuration of Nodepool nodes by the upstream CI
system in the openstack-infra/config project here:

https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/templates/nodepool/nodepool.yaml.erb

> Is it possible to use a different node management system instead of nodepool 
> with Zuul?

Probably would be best to improve Nodepool if you find something lacking
there, rather than develop a new node management system...

Just my suggestion.

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] External testing account

[Jay Pipes]

On Mon, 2014-02-10 at 01:00 +, Jeremy Stanley wrote:
> On 2014-02-07 11:17:05 -0500 (-0500), Jay Pipes wrote:
> [...]
> > That said, I don't want to clutter any OpenStack project's code reviews
> > with test comments. Is there a test project somewhere that is used for
> > this type of testing that I could use to test out the deployment modules
> > from the repo above? Perhaps we can create a Gerrit project that is
> > specifically used for parties to test their external test platforms?
> 
> Yes, you can create and comment on changes in the
> openstack-dev/sandbox repository on review.openstack.org all you
> like. That's one of the reasons it exists.

Awesomesauce. That's perfect :)

> > Here is information about the testing account:
> > 
> > public SSH key:
> [...]
> > username: jaypipes-testing
> > email: jpi...@mirantis.com
> [...]
> 
> I've created the account as requested. It can place VRFY votes in
> the -1/+1 range on openstack-dev/sandbox for testing purposes.
> 
> Note that the ACL to let the new "Third-Party CI" group vote
> exclusively on openstack-dev/sandbox just merged, so if you run into
> any trouble it's entirely possible I did something wrong... let me
> know if so!

Will do. Very much appreciated, sir!

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] External testing account

[Jay Pipes]

On Sat, 2014-02-08 at 10:40 +, Monty Taylor wrote:
> We have a test repo, but also have a whole Dev gerrit ... Perhaps we should 
> just make you a repo there?

Sure, whatever makes sense and is easiest for infra folks to do. I don't
want to be a bother, but also don't want to be posting test comments
into Cinder and Neutron code reviews ;)

Best,
-jay

> On Feb 7, 2014 4:17 PM, Jay Pipes  wrote:
> >
> > Hi Infra tream, 
> >
> > I've been working on a set of Puppet modules (and soon to be Ansible 
> > playbooks) for deploying a 3rd party testing platform: 
> >
> > https://github.com/jaypipes/os-ext-testing 
> >
> > I'm almost done with it, but I need to complete end-to-end testing of 
> > everything, and to do that, I need a testing account that can post 
> > reviews to the OpenStack Gerrit system. 
> >
> > That said, I don't want to clutter any OpenStack project's code reviews 
> > with test comments. Is there a test project somewhere that is used for 
> > this type of testing that I could use to test out the deployment modules 
> > from the repo above? Perhaps we can create a Gerrit project that is 
> > specifically used for parties to test their external test platforms? 
> >
> > Here is information about the testing account: 
> >
> > public SSH key: 
> >
> > > ssh-rsa 
> > > B3NzaC1yc2EDAQABAAABAQC1FXfMiOhHcxg3VKSkzesEg1AKxXo7NlIl+Xhv7bB9SHuVp+biy+1HNzbxQQq69+4Lg137Qvta/r+a4tbBtkExFLdRT313t6mkJ1M7644lH5tzXJDOe0vPakbz63d3ZF9+I6r/sV4wU+f9bQc5kEX8YG7HZDSwe9XJU6zrjqd7M902q4mYny7Bi0RX1PmXIOUYtThjLDmOtP5VYp2lJ2D9LeIPBpmlj5d6M8qTqqe5fIKctdeihWql0oqJ79aLbY4aTqk8cni4ncrnGyCyMcsuokFefYRYlso0iKJ41tH8/xE7d5l1tfLyK37WICBzWwzWUS8xvwgvA29wOEZ4a9I9
> > >  jpipes@uberbox 
> >
> > username: 
> >
> > jaypipes-testing 
> >
> > email: 
> >
> > jpi...@mirantis.com 
> >
> > Thanks much in advance, I'm hoping these deployment modules will be 
> > handy for all the vendors currently trying to set up external testing 
> > systems that are liked with upstream. 
> >
> > Best, 
> > -jay 
> >
> >
> > ___ 
> > OpenStack-Infra mailing list 
> > OpenStack-Infra@lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra 
> >



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] External testing account

[Jay Pipes]

On Fri, 2014-02-07 at 17:57 +, Octavian Ciuhandu wrote:
> Hi Jay,
> 
> Thanks for the great work, we’ve just been going through the process of 
> setting up the Hyper-V CI and this would have helped a lot. I have also left 
> a couple of comments on the git repo.

Thank you Octavian,

I responded to your comment on the last patch. Basically, that patch
(and the problem you highlight) was the reason I wrote this email :)

I have hard-coded the openstack/cinder project in the layout.yaml file
for Zuul right now, but I am going to make this into either a Puppet
template or put the layout.yaml file in the examples/files/ directory
like the projects.yaml file...

Just trying to figure out a way to make the os-ext-testing repo as easy
as possible for folks to get the testing platform up and running,
without any hardcoding of projects, but with some sensible defaults.

Best,
-jay

> 
> Thanks,
> 
> Octavian.
> 
> 
> On 7 Feb 2014, at 18:17, Jay Pipes  wrote:
> 
> > Hi Infra tream,
> > 
> > I've been working on a set of Puppet modules (and soon to be Ansible
> > playbooks) for deploying a 3rd party testing platform:
> > 
> > https://github.com/jaypipes/os-ext-testing
> > 
> > I'm almost done with it, but I need to complete end-to-end testing of
> > everything, and to do that, I need a testing account that can post
> > reviews to the OpenStack Gerrit system.
> > 
> > That said, I don't want to clutter any OpenStack project's code reviews
> > with test comments. Is there a test project somewhere that is used for
> > this type of testing that I could use to test out the deployment modules
> > from the repo above? Perhaps we can create a Gerrit project that is
> > specifically used for parties to test their external test platforms?
> > 
> > Here is information about the testing account:
> > 
> > public SSH key: 
> > 
> >> ssh-rsa 
> >> B3NzaC1yc2EDAQABAAABAQC1FXfMiOhHcxg3VKSkzesEg1AKxXo7NlIl+Xhv7bB9SHuVp+biy+1HNzbxQQq69+4Lg137Qvta/r+a4tbBtkExFLdRT313t6mkJ1M7644lH5tzXJDOe0vPakbz63d3ZF9+I6r/sV4wU+f9bQc5kEX8YG7HZDSwe9XJU6zrjqd7M902q4mYny7Bi0RX1PmXIOUYtThjLDmOtP5VYp2lJ2D9LeIPBpmlj5d6M8qTqqe5fIKctdeihWql0oqJ79aLbY4aTqk8cni4ncrnGyCyMcsuokFefYRYlso0iKJ41tH8/xE7d5l1tfLyK37WICBzWwzWUS8xvwgvA29wOEZ4a9I9
> >>  jpipes@uberbox
> > 
> > username:
> > 
> > jaypipes-testing
> > 
> > email:
> > 
> > jpi...@mirantis.com
> > 
> > Thanks much in advance, I'm hoping these deployment modules will be
> > handy for all the vendors currently trying to set up external testing
> > systems that are liked with upstream.
> > 
> > Best,
> > -jay
> > 
> > 
> > ___
> > OpenStack-Infra mailing list
> > OpenStack-Infra@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] External testing account

[Jay Pipes]

Hi Infra tream,

I've been working on a set of Puppet modules (and soon to be Ansible
playbooks) for deploying a 3rd party testing platform:

https://github.com/jaypipes/os-ext-testing

I'm almost done with it, but I need to complete end-to-end testing of
everything, and to do that, I need a testing account that can post
reviews to the OpenStack Gerrit system.

That said, I don't want to clutter any OpenStack project's code reviews
with test comments. Is there a test project somewhere that is used for
this type of testing that I could use to test out the deployment modules
from the repo above? Perhaps we can create a Gerrit project that is
specifically used for parties to test their external test platforms?

Here is information about the testing account:

public SSH key: 

> ssh-rsa 
> B3NzaC1yc2EDAQABAAABAQC1FXfMiOhHcxg3VKSkzesEg1AKxXo7NlIl+Xhv7bB9SHuVp+biy+1HNzbxQQq69+4Lg137Qvta/r+a4tbBtkExFLdRT313t6mkJ1M7644lH5tzXJDOe0vPakbz63d3ZF9+I6r/sV4wU+f9bQc5kEX8YG7HZDSwe9XJU6zrjqd7M902q4mYny7Bi0RX1PmXIOUYtThjLDmOtP5VYp2lJ2D9LeIPBpmlj5d6M8qTqqe5fIKctdeihWql0oqJ79aLbY4aTqk8cni4ncrnGyCyMcsuokFefYRYlso0iKJ41tH8/xE7d5l1tfLyK37WICBzWwzWUS8xvwgvA29wOEZ4a9I9
>  jpipes@uberbox

username:

jaypipes-testing

email:

jpi...@mirantis.com

Thanks much in advance, I'm hoping these deployment modules will be
handy for all the vendors currently trying to set up external testing
systems that are liked with upstream.

Best,
-jay


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing

[Jay Pipes]

On Wed, 2014-02-05 at 15:50 +0400, Sergey Lukjanov wrote:
> Hi Jay,
> 
> it's really very easy to setup Zuul for it (we're using one for
> Savanna CI).

Yes, I set up Zuul for AT&T's gate system, thx.

> There are some useful links:
> 
> * check pipeline as an example of zuul layout configuration
> - 
> https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/zuul/layout.yaml#L5
> * zuul docs - http://ci.openstack.org/zuul/
> * zuul config sample
> - https://github.com/openstack-infra/zuul/blob/master/etc/zuul.conf-sample
> 
> So, I think that it could be easy enough to setup Zuul for 3rd party
> testing, but it'll be better to have some doc about it.

Yeah, I proposed in my email that I would do the documentation for using
Zuul as the trigger from Gerrit (see below). However, I didn't think I'd
get the docs done in a timely fashion and proposed relaxing the
requirement for "recheck" triggers until that documentation was complete
(since most of the vendors I have spoken with have used the Jenkins
Gerrit plugin and not Zuul as their triggering agent)

Best,
-jay

> 
> On Wed, Feb 5, 2014 at 3:55 AM, Jay Pipes  wrote:
> Sorry for cross-posting to both mailing lists, but there's
> lots of folks
> working on setting up third-party testing platforms that are
> not members
> of the openstack-infra ML...
> 
> tl;dr
> -
> 
> The third party testing documentation [1] has requirements [2]
> that
> include the ability to trigger a recheck based on a gerrit
> comment.
> 
> Unfortunately, the Gerrit Jenkins Trigger plugin [3] does not
> have the
> ability to trigger job runs based on a regex-filtered comment
> (only on
> the existence of any new comment to the code review).
> 
> Therefore, we either should:
> 
> a) Relax the requirement that the third party system trigger
> test
> re-runs when a comment including the word "recheck" appears in
> the
> Gerrit event stream
> 
> b) Modify the Jenkins Gerrit plugin to support regex filtering
> on the
> comment text (in the same way that it currently supports regex
> filtering
> on the project name)
> 
> or
> 
> c) Add documentation to the third party testing pages that
> explains how
> to use Zuul as a replacement for the Jenkins Gerrit plugin.
> 
> I propose we do a) for the short term, and I'll work on c)
> long term.
> However, I'm throwing this out there just in case there are
> some Java
> and Jenkins whizzes out there that could get b) done in a
> jiffy.
> 
> details
> ---
> 
> OK, so I've been putting together documentation on how to set
> up an
> external Jenkins platform that is "linked" [4] with the
> upstream
> OpenStack CI system.
> 
> Recently, I wrote an article detailing how the upstream CI
> system
> worked, including a lot of the gory details from the
> openstack-infra/config project's files. [5]
> 
> I've been working on a follow-up article that goes through how
> to set up
> a Jenkins system, and in writing that article, I created a
> source
> repository [6] that contains scripts, instructions and Puppet
> modules
> that set up a Jenkins system, the Jenkins Job Builder tool,
> and
> installs/configures the Jenkins Gerrit plugin [7].
> 
> I planned to use the Jenkins Gerrit plugin as the mechanism
> that
> triggers Jenkins jobs on the external system based on gerrit
> events
> published by the OpenStack review.openstack.org Gerrit
> service. In
> addition to being mentioned in the third party documentation,
> Jenkins
> Job Builder has the ability to construct Jenkins jobs that are
> triggered
> by the Jenkins Gerrit plugin [8].
> 
> Unforunately, I've run into a bit of a snag.
> 
> The third party testing documentation has requirements that
> include the
> ability to trigger a recheck based on a gerrit comment:
> 
> 
> Support recheck to request re-running a test.
>  * 

[OpenStack-Infra] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing

[Jay Pipes]

Sorry for cross-posting to both mailing lists, but there's lots of folks
working on setting up third-party testing platforms that are not members
of the openstack-infra ML...

tl;dr
-

The third party testing documentation [1] has requirements [2] that
include the ability to trigger a recheck based on a gerrit comment.

Unfortunately, the Gerrit Jenkins Trigger plugin [3] does not have the
ability to trigger job runs based on a regex-filtered comment (only on
the existence of any new comment to the code review).

Therefore, we either should:

a) Relax the requirement that the third party system trigger test
re-runs when a comment including the word "recheck" appears in the
Gerrit event stream

b) Modify the Jenkins Gerrit plugin to support regex filtering on the
comment text (in the same way that it currently supports regex filtering
on the project name)

or

c) Add documentation to the third party testing pages that explains how
to use Zuul as a replacement for the Jenkins Gerrit plugin.

I propose we do a) for the short term, and I'll work on c) long term.
However, I'm throwing this out there just in case there are some Java
and Jenkins whizzes out there that could get b) done in a jiffy.

details
---

OK, so I've been putting together documentation on how to set up an
external Jenkins platform that is "linked" [4] with the upstream
OpenStack CI system.

Recently, I wrote an article detailing how the upstream CI system
worked, including a lot of the gory details from the
openstack-infra/config project's files. [5]

I've been working on a follow-up article that goes through how to set up
a Jenkins system, and in writing that article, I created a source
repository [6] that contains scripts, instructions and Puppet modules
that set up a Jenkins system, the Jenkins Job Builder tool, and
installs/configures the Jenkins Gerrit plugin [7].

I planned to use the Jenkins Gerrit plugin as the mechanism that
triggers Jenkins jobs on the external system based on gerrit events
published by the OpenStack review.openstack.org Gerrit service. In
addition to being mentioned in the third party documentation, Jenkins
Job Builder has the ability to construct Jenkins jobs that are triggered
by the Jenkins Gerrit plugin [8].

Unforunately, I've run into a bit of a snag.

The third party testing documentation has requirements that include the
ability to trigger a recheck based on a gerrit comment:


Support recheck to request re-running a test.
 * Support the following syntaxes recheck no bug and recheck bug ###.
 * Recheck means recheck everything. A single recheck comment should
re-trigger all testing systems.


The documentation has a section on using the Gerrit Jenkins Trigger
plugin [3] to accept notifications from the upstream OpenStack Gerrit
instance.

But unfortunately, the Jenkins Gerrit plugin does not support the
ability to trigger a re-run of a job given a regex match of the word
"recheck". :(

So, we either need to a) change the requirements of third party testers,
b) enhance the Jenkins Gerrit plugin with the missing functionality, or
c) add documentation on how to set up Zuul as the triggering system
instead of the Jenkins Gerrit plugin.

I'm happy to work on c), but I think relaxing the restriction (a) is
probably needed short-term.

Best,
-jay

[1] http://ci.openstack.org/third_party.html
[2] http://ci.openstack.org/third_party.html#requirements
[3]
http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way
[4] By "linked" I mean it both reads from the OpenStack Gerrit system
and writes (adds comments) to it
[5] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
[6] http://github.com/jaypipes/os-ext-testing
[7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger
[8]
https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/triggers.py#L121



___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra