Re: [openstack-dev] [qa][tempest-plugins][release][tc][ptl]: Coordinated Release Model proposal for Tempest & Tempest Plugins

[Andrea Frittoli]

On Tue, 26 Jun 2018, 1:08 pm Thierry Carrez,  wrote:

> Dmitry Tantsur wrote:
> > [...]
> > My suggestion: tempest has to be compatible with all supported releases
> > (of both services and plugins) OR be branched.
> > [...]
> I tend to agree with Dmitry... We have a model for things that need
> release alignment, and that's the cycle-bound series. The reason tempest
> is branchless was because there was no compatibility issue. If the split
> of tempest plugins introduces a potential incompatibility, then I would
> prefer aligning tempest to the existing model rather than introduce a
> parallel tempest-specific cycle just so that tempest can stay
> release-independent...
>
> I seem to remember there were drawbacks in branching tempest, though...
> Can someone with functioning memory brain cells summarize them again ?
>


Branchless Tempest enforces api stability across branches.

For the same reason tempest plug ins should be branchless, which is one of
the reasons that having them in the same repo as a service was an issue:
services are branched but api/integration tests should be branchless.

Andrea


> --
> Thierry Carrez (ttx)
>
> __
> 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

[openstack-dev] [qa][integrated] Multinode base job

[Andrea Frittoli]

Dear all,

the Tempest / devstack multinode integration base job in it's Zuulv3 native
incarnation is finally working, and the patch [0] to making it voting on
Tempest is approved.

The name of the new job is "tempest-multinode-full". This effectively
replaces the legacy "neutron-tempest-multinode-full".
Since "neutron-tempest-multinode-full" is used as non-voting by all
projects that use the "integrated-gate" job template, I'd propose to:
- add "tempest-multinode-full" as non-voting to the integrated gate for
master, queens and pike
- fix any issue that may show up on queens/pike
- remove neutron-tempest-multinode-full legacy job

I would also like to make the multinode job voting, at least on devstack,
possibly on all integrated gate repos.

Please let me know if anyone as any concern with this plan.

Andrea
__
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] [tempest] Proposing Felipe Monteiro for Tempest core

[Andrea Frittoli]

+1!!



On Sat, 28 Apr 2018, 11:29 am Ghanshyam Mann, 
wrote:

> Hi Tempest Team,
>
> I would like to propose  Felipe Monteiro (irc: felipemonteiro) to Tempest
> core.
>
> Felipe has been an active contributor to the Tempest  since the Pike
> cycle. He has been doing lot of review and commits since then. Filling
> the gaps on service clients side and their testing and lot other
> areas. He has demonstrated the good quality and feedback while his
> review.
>
> He has good understanding of Tempest source code and project missions
> & goal. IMO his efforts are highly valuable and it will be great to
> have him in team.
>
>
> As per usual practice, please vote +1 or -1 to the nomination. I will
> keep this nomination open for a week or until everyone voted.
>
> Felipe Reviews and Commit -
>
> https://review.openstack.org/#/q/reviewer:felipe.monte...@att.com+project:openstack/tempest
>
> https://review.openstack.org/#/q/owner:felipe.monte...@att.com+project:openstack/tempest
>
> -gmann
>
> __
> 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

[openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Andrea Frittoli]

Dear all,

a quick update on the current status.

Zuul has been fixed to use the correct branch for roles coming from
different repositories [1].
The backport of the devstack patches to support multinode jobs is almost
complete. All stable/queens patches are merged, stable/pike patches are
almost all approved and going through the gate [2].

The two facts above mean that now the "devstack-tempest" base job defined
in Tempest can be switched to use the "orchestrate-devstack" role and thus
function as a base for multinode jobs [3].
It also means that work on writing grenade jobs in zuulv3 native format can
now be resumed [4].

Kind regards

Andrea Frittoli

[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-April/129217.html
[2]
https://review.openstack.org/#/q/topic:multinode_zuulv3+(status:open+OR+status:merged
)
[3] https://review.openstack.org/#/c/545724/
[4]
https://review.openstack.org/#/q/status:open+branch:master+topic:grenade_zuulv3


On Mon, Mar 12, 2018 at 2:08 PM Andrea Frittoli 
wrote:

> Dear all,
>
> post-PTG updates:
>
> - the devstack patches for multinode support are now merged on master. You
> can now build your multinode zuulv3 native devstack/tempest test jobs using
> the same base jobs as for single node, and setting a multinode nodeset.
> Documentation landed as well, so you can now find docs on roles [0], jobs
> [1] and a migration guide [2] which will show you which base jobs to start
> with and how to migrate those devstack-gate flags from legacy jobs to the
> zuul v3 jobs.
>
> - the multinode patches including switching of test-matrix (on master) and
> start including the list of devstack services in the base jobs. In doing so
> I used the new neutron service names. That may be causing issues to
> devstack-plugins looking for old service names, so if you encounter an
> issue please reach out in the openstack-qa / openstack-infra rooms. We
> could still roll back to the old names, however the beginning of the cycle
> is probably the best time to sort out issues related to the new names and
> new logic in the neutron - devstack code.
>
> Coming up next:
>
> - backport of devstack patches to stable (queens and pike), so we can
> switch the Tempest job devstack multinode mode and develop grenade zuulv3
> native jobs. I do not plan on backporting the new neutron names to any
> stable branch, let me know if there is any reason to do otherwise.
> - work on grenade is at very early stages [3], so far I got devstack
> running successfully on stable/queens from the /opt/stack/old folder using
> the zuulv3 roles. Next up is actually doing the migration and running all
> relevant checks.
>
> Andrea Frittoli (andreaf)
>
> [0] https://docs.openstack.org/devstack/latest/zuul_roles.html
> [1] https://docs.openstack.org/devstack/latest/zuul_jobs.html
> [2] https://docs.openstack.org/devstack/latest/zuul_ci_jobs_migration.html
>
> [3]
> https://review.openstack.org/#/q/status:open+branch:master+topic:grenade_zuulv3
>
>
>
> On Tue, Feb 20, 2018 at 9:22 PM Andrea Frittoli 
> wrote:
>
>> Dear all,
>>
>> updates:
>>
>> - host/group vars: zuul now supports declaring host and group vars in the
>> job definition [0][1] - thanks corvus and infra team!
>>   This is a great help towards writing the devstack and tempest base
>> multinode jobs [2][3]
>>   * NOTE: zuul merges dict variables through job inheritance. Variables
>> in host/group_vars override global ones. I will write some examples further
>> clarify this.
>>
>> - stable/pike: devstack ansible changes have been backported to
>> stable/pike, so we can now run zuulv3 jobs against stable/pike too - thank
>> you tosky!
>>   next change in progress related to pike is to provide tempest-full-pike
>> for branchless repositories [4]
>>
>> - documentation: devstack now publishes documentation on its ansible
>> roles [5].
>>   More devstack documentation patches are in progress to provide jobs
>> reference, examples and a job migration how-to [6].
>>
>>
>> Andrea Frittoli (andreaf)
>>
>> [0]
>> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.host_vars
>>
>> [1]
>> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.group_vars
>>
>> [2] https://review.openstack.org/#/c/545696/
>> [3] https://review.openstack.org/#/c/545724/
>> [4] https://review.openstack.org/#/c/546196/
>> [5] https://docs.openstack.org/devstack/latest/roles.html
>> [6] https://review.openstack.org/#/c/545992/
>>
>>
>> On Mon, Feb 19, 2018 at 2:46 PM Andrea Frittoli <
>> andrea.fritt...@gmail.com> wrote:
>>
>>> Dear all,
>>>
&

Re: [openstack-dev] [all] Changes to Zuul role checkouts

[Andrea Frittoli]

On Mon, Apr 9, 2018 at 5:55 PM James E. Blair  wrote:

> Hi,
>
> We recently fixed a subtle but important bug related to how Zuul checks
> out repositories it uses to find Ansible roles for jobs.
>

\o/


>
> This may result in a behavior change, or even an error, for jobs which
> use roles defined in projects with multiple branches.
>
> Previously, Zuul would (with some exceptions) generally check out the
> 'master' branch of any repository which appeared in the 'roles:' stanza
> in the job definition.  Now Zuul will follow its usual procedure of
> trying to find the most appropriate branch to check out.  That means it
> tries the project override-checkout branch first, then the job
> override-checkout branch, then the branch of the change, and finally the
> default branch of the project.
>
> This should produce more predictable behavior which matches the
> checkouts of all other projects involved in a job.
>
> If you find that the wrong branch of a role is being checked out,
> depending on circumstances, you may need to set a job or project
> override-checkout value to force the correct one, or you may need to
> backport a role to an older branch.
>
> If you encounter any problems related to this, please chat with us in
> #openstack-infra.
>
>
Thanks a lot Jim for fixing this!

With this in place I can now continue the work on devstack, tempest and
grenade base roles and jobs for zuul v3.
Next steps (in order of dependency):
- backport ansible devstack changes to queens and pike
- start using the "orchestrate-devstack" role in the "devstack-tempest" base
  job - so that it can be used for multinode jobs as well
- continue the work on setting up a grenade zuulv3 job

Andrea Frittoli (andreaf)



> 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] [infra][qa][requirements] Pip 10 is on the way

[Andrea Frittoli]

On Thu, Apr 5, 2018 at 9:27 PM Clark Boylan  wrote:

> On Mon, Apr 2, 2018, at 9:13 AM, Clark Boylan wrote:
> > On Mon, Apr 2, 2018, at 8:06 AM, Matthew Thode wrote:
> > > On 18-03-31 15:00:27, Jeremy Stanley wrote:
> > > > According to a notice[1] posted to the pypa-announce and
> > > > distutils-sig mailing lists, pip 10.0.0.b1 is on PyPI now and 10.0.0
> > > > is expected to be released in two weeks (over the April 14/15
> > > > weekend). We know it's at least going to start breaking[2] DevStack
> > > > and we need to come up with a plan for addressing that, but we don't
> > > > know how much more widespread the problem might end up being so
> > > > encourage everyone to try it out now where they can.
> > > >
> > >
> > > I'd like to suggest locking down pip/setuptools/wheel like openstack
> > > ansible is doing in
> > >
> https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt
> > >
> > > We could maintain it as a separate constraints file (or infra could
> > > maintian it, doesn't mater).  The file would only be used for the
> > > initial get-pip install.
> >
> > In the past we've done our best to avoid pinning these tools because 1)
> > we've told people they should use latest for openstack to work and 2) it
> > is really difficult to actually control what versions of these tools end
> > up on your systems if not latest.
> >
> > I would strongly push towards addressing the distutils package deletion
> > problem that we've run into with pip10 instead. One of the approaches
> > thrown out that pabelanger is working on is to use a common virtualenv
> > for devstack and avoid the system package conflict entirely.
>
> I was mistaken and pabelanger was working to get devstack's USE_VENV
> option working which installs each service (if the service supports it)
> into its own virtualenv. There are two big drawbacks to this. This first is
> that we would lose coinstallation of all the openstack services which is
> one way we ensure they all work together at the end of the day. The second
> is that not all services in "base" devstack support USE_VENV and I doubt
> many plugins do either (neutron apparently doesn't?).
>
> I've since worked out a change that passes tempest using a global
> virtualenv installed devstack at https://review.openstack.org/#/c/558930/.
> This needs to be cleaned up so that we only check for and install the
> virtualenv(s) once and we need to handle mixed python2 and python3
> environments better (so that you can run a python2 swift and python3
> everything else).
>
> The other major issue we've run into is that nova file injection (which is
> tested by tempest) seems to require either libguestfs or nbd. libguestfs
> bindings for python aren't available on pypi and instead we get them from
> system packaging. This means if we want libguestfs support we have to
> enable system site packages when using virtualenvs. The alternative is to
> use nbd which apparently isn't preferred by nova and doesn't work under
> current devstack anyways.
>
> Why is this a problem? Well the new pip10 behavior that breaks devstack is
> pip10's refusable to remove distutils installed packages. Distro packages
> by and large are distutils packaged which means if you mix system packages
> and pip installed packages there is a good chance something will break (and
> it does break for current devstack). I'm not sure that using a virtualenv
> with system site packages enabled will sufficiently protect us from this
> case (but we should test it further). Also it feels wrong to enable system
> packages in a virtualenv if the entire point is avoiding system python
> packages.
>
> I'm not sure what the best option is here but if we can show that system
> site packages with virtualenvs is viable with pip10 and people want to move
> forward with devstack using a global virtualenv we can work to clean up
> this change and make it mergeable.
>

Thanks Clark for looking into this.

One of the things that will break using a global virtual env is the
"all-plugin" Tempest tox environment, which is still used in a few places
[0].
The "all-plugin" tox environment is deprecated anyways, so this may
actually push things moving in the right direction.

Some background the "all-plugin": Tempest plugins used to live in tree for
many projects - for Tempest to discover those plugins, "all-plugin"
installs Tempest in a virtual environment with system site-packages
enabled. After the Tempest plugin community 

Re: [openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Andrea Frittoli]

Dear all,

post-PTG updates:

- the devstack patches for multinode support are now merged on master. You
can now build your multinode zuulv3 native devstack/tempest test jobs using
the same base jobs as for single node, and setting a multinode nodeset.
Documentation landed as well, so you can now find docs on roles [0], jobs
[1] and a migration guide [2] which will show you which base jobs to start
with and how to migrate those devstack-gate flags from legacy jobs to the
zuul v3 jobs.

- the multinode patches including switching of test-matrix (on master) and
start including the list of devstack services in the base jobs. In doing so
I used the new neutron service names. That may be causing issues to
devstack-plugins looking for old service names, so if you encounter an
issue please reach out in the openstack-qa / openstack-infra rooms. We
could still roll back to the old names, however the beginning of the cycle
is probably the best time to sort out issues related to the new names and
new logic in the neutron - devstack code.

Coming up next:

- backport of devstack patches to stable (queens and pike), so we can
switch the Tempest job devstack multinode mode and develop grenade zuulv3
native jobs. I do not plan on backporting the new neutron names to any
stable branch, let me know if there is any reason to do otherwise.
- work on grenade is at very early stages [3], so far I got devstack
running successfully on stable/queens from the /opt/stack/old folder using
the zuulv3 roles. Next up is actually doing the migration and running all
relevant checks.

Andrea Frittoli (andreaf)

[0] https://docs.openstack.org/devstack/latest/zuul_roles.html
[1] https://docs.openstack.org/devstack/latest/zuul_jobs.html
[2] https://docs.openstack.org/devstack/latest/zuul_ci_jobs_migration.html
[3]
https://review.openstack.org/#/q/status:open+branch:master+topic:grenade_zuulv3



On Tue, Feb 20, 2018 at 9:22 PM Andrea Frittoli 
wrote:

> Dear all,
>
> updates:
>
> - host/group vars: zuul now supports declaring host and group vars in the
> job definition [0][1] - thanks corvus and infra team!
>   This is a great help towards writing the devstack and tempest base
> multinode jobs [2][3]
>   * NOTE: zuul merges dict variables through job inheritance. Variables in
> host/group_vars override global ones. I will write some examples further
> clarify this.
>
> - stable/pike: devstack ansible changes have been backported to
> stable/pike, so we can now run zuulv3 jobs against stable/pike too - thank
> you tosky!
>   next change in progress related to pike is to provide tempest-full-pike
> for branchless repositories [4]
>
> - documentation: devstack now publishes documentation on its ansible roles
> [5].
>   More devstack documentation patches are in progress to provide jobs
> reference, examples and a job migration how-to [6].
>
>
> Andrea Frittoli (andreaf)
>
> [0]
> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.host_vars
> [1]
> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.group_vars
>
> [2] https://review.openstack.org/#/c/545696/
> [3] https://review.openstack.org/#/c/545724/
> [4] https://review.openstack.org/#/c/546196/
> [5] https://docs.openstack.org/devstack/latest/roles.html
> [6] https://review.openstack.org/#/c/545992/
>
>
> On Mon, Feb 19, 2018 at 2:46 PM Andrea Frittoli 
> wrote:
>
>> Dear all,
>>
>> updates:
>> - tempest-full-queens and tempest-full-py3-queens are now available for
>> testing of branchless repositories [0]. They are used for tempest and
>> devstack-gate. If you own a tempest plugin in a branchless repo, you may
>> consider adding similar jobs to your plugin if you use it for tests on
>> stable/queen as well.
>> - if you have migrated jobs based on devstack-tempest please let me know,
>> I'm building reference docs and I'd like to include as many examples as
>> possible
>> - work on multi-node is in progress, but not ready still - you can follow
>> the patches in the multinode branch [1]
>> - updates on some of the points from my previous email are inline below
>>
>> Andrea Frittoli (andreaf)
>>
>> [0] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n73
>> [1]
>> https://review.openstack.org/#/q/status:open++branch:master+topic:multinode
>>
>>
>>
>> On Thu, Feb 15, 2018 at 11:31 PM Andrea Frittoli <
>> andrea.fritt...@gmail.com> wrote:
>>
>>> Dear all,
>>>
>>> this is the first or a series of ~regular updates on the migration of
>>> Tempest / Grenade jobs to  Zuul v3 native.
>>>
>>> The QA team together with the infra team are working on providing the
>>> OpenStack community with a set of base Temp

Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

[Andrea Frittoli]

On Wed, Mar 7, 2018 at 12:42 PM Ghanshyam Mann 
wrote:

>  Hi All,
>
> QA had discussion in Dublin PTG about interop adds-on tests location.
> First of all thanks all (specially markvoelker, dhellmann, mugsie) for
> joining the sessions. and I am glad we conclude the things and agreed on
> solution.
>
> Discussion was carry forward from the ML discussion [1] and to get the
> agreement about interop adds-on program tests location.
>
> Till now only 2 projects (heat and designate) are in list of adds-on
> program from interop side. After discussion and points from all stack
> holders, QA team agreed to host these 2 projects interop tests.  Tests from
> both projects are not much as of now and QA team can accommodate to host
> their interop tests.
>
> Along with that agreement we had few more technical points to consider
> while moving designate and heat interop tests in Tempest repo. All the
> interop tests going to be added in Tempest must to be Tempest like tests.
> Tempest like tests here means tests written using Tempest interfaces and
> guidelines. For example, heat has their tests in heat-tempest-plugin based
> on gabbi and to move heat interop tests to Tempest those have to be written
> as Tempest like test. This is because if we accept non-tempest like tests
> in Tempest then, it will be too difficult to maintain by Tempest team.
>
> Projects (designate and heat) and QA team will work closely to move
> interop tests to Tempest repo which might needs some extra work of
> standardizing their tests and interface used by them like service clients
> etc.
>
> In future, if there are more new interop adds-on program proposal then, we
> need to analyse the situation again regarding QA team bandwidth. TC or QA
> or interop team needs to raise the resource requirement to Board of
> Directors before any more new adds-on program is being proposed. If QA team
> has less resource and less review bandwitdh then we cannot accept the more
> interop programs till QA get more resource to maintain new interop tests.
>
> Overall Summary:
> - QA team agreed to host the interop tests for heat and designate in
> Tempest repo.
> - Existing TC resolution needs to be adjust about the QA team resource
> bandwidth requirement. If there is going to be more adds-on program
> proposal then, QA team will not accept the new interop tests if QA team
> bandwidth issue still exist that time also.
> - Tempest will document the clear process about interop tests addition and
> other more care items etc.
> - Projects team to make their tests and interface as Tempest like tests
> and stable interfaces standards. Tempest team will closely work and help
> Designate and Heat on this.
>
> Thanks for the summary Ghanshyam!

We had some follow up discussion on Friday about this, after the Heat team
expressed their concern about proceeding with the plan we discussed during
the session on Wednesday.
A group of representatives of the Heat, Designate and Interop teams met
with the TC and agreed on reviving the resolution started by mugsie in
https://review.openstack.org/#/c/521602 to add an alternative to hosting
tests in the Tempest repo. Unfortunately I was only there for the last few
minutes of the meeting, but I understand that the proposal drafted there
was to allow team to have interop-specific Tempest plugins co-owned by
QA/Interop/add-on project team. mugsie has updated the resolution
accordingly and I think the discussion on that can continue in gerrit
directly.

Just to clarify, nothing has been decided yet, but at least the new
proposal was received positively by all parties involved in the discussion
on Friday.

Action Items:
> - mugsie to abandon https://review.openstack.org/#/c/521602 with quick
> summary of discussion here at PTG
>
This is not valid anymore, we should discuss this further and hopefully
reach an agreement.


> - markvoelker to write up clarification to InteropWG process stating that
> tests should be moved into Tempest before being proposed to the BoD
> - markvoelker to work with gmann before next InteropWG+BoD discussion to
> frame up a note about resourcing testing for add-on/vertical programs
> - dhellmann to adjust the TC resolution for resource requirement in QA
> when new adds-on program is being proposed
> - project teams to convert  interop test and  framework as per tempest
> like tests and propose to add to tempest repo.
>
If the new resolution is agreed on, this will become one of the options.


> - gmann to define process in QA about interop tests addition and
> maintainance
>
This is still an option so you may still want to do it.

Andrea Frittoli (andreaf)

>
> We have added this as one of the monitoring/helping item for QA to make
> sure it is done without delay.  Let's work together to fi

Re: [openstack-dev] [devstack] Jens Harbott added to core

[Andrea Frittoli]

On Mon, 5 Mar 2018, 1:02 am Ian Wienand,  wrote:

> Hello,
>
> Jens Harbott (frickler) has agreed to take on core responsibilities in
> devstack, so feel free to bug him about reviews :)
>

Yay +1

>
> We have also added the members of qa-release in directly to
> devstack-core, just for visibility (they already had permissions via
> qa-release -> devstack-release -> devstack-core).
>
> We have also added devstack-core as grenade core to hopefully expand
> coverage there.
>

Thanks, this helps indeed.
I started working on the zuulv3 native grenade jobs, hopefully this will
help getting a bit more speed on that.


> ---
>
> Always feel free to give a gentle ping on reviews that don't seem have
> received sufficient attention.
>
> But please also take a few minutes to compose a commit message!  I
> think sometimes devs have been deep in the weeds with their cool
> change and devstack requires just a few tweaks.  It's easy to forget
> not all reviewers may have this same context.  A couple of
> well-crafted sentences can avoid pulling projects and "git blame"
> archaeological digs, which gets everything going faster!
>


+1000

Andrea Frittoli (andreaf)

>
> Thanks,
>
> -i
>
> __
> 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] [gate][devstack][neutron][qa][release] Switch to lib/neutron in gate

[Andrea Frittoli]

On Fri, Jan 19, 2018 at 8:36 PM Ihar Hrachyshka  wrote:

> Hi Andrea,
>
> thanks for taking time to reply. I left some answers inline.
>
> On Fri, Jan 19, 2018 at 9:08 AM, Andrea Frittoli
>  wrote:
> >
> >
> > On Wed, Jan 17, 2018 at 7:27 PM Ihar Hrachyshka 
> wrote:
> >>
> >> Hi all,
> >
> >
> > Hi!
> >>
> >>
> >> tl;dr I propose to switch to lib/neutron devstack library in Queens. I
> >> ask for buy-in to the plan from release and QA teams, something that
> >> infra asked me to do.
>

Hello Ihar,

I'm coming back to this thread after a while, since I'm writing zuulv3
native devstack jobs,
and I think this is the perfect opportunity for starting to using
lib/neutron, since we easily
decide to limit the change to the branches we want, e.g. start with master
and then
go back to stable/queens if we want to.

Zuulv3 native jobs run on master, queens and they're being ported to Pike.
Starting from Queens on I plan to stop using the test-matrix from
devstack-gate, and define
the list of required services in jobs instead. This is made possible by the
job inheritance
capability introduced by Zuul v3. For the single node job I proposed a
change already [0],
and I'm working on the same for multinode. I would like if possible to
start using new service
and variable names as part of [0] but I need some help on that.

This change in the zuulv3 jobs should replace the existing in progress
devstack-gate patch [1].

If you are at the PTG I would be happy to chat / hack on this topic there.

Andrea Frittoli (andreaf)

[0] https://review.openstack.org/#/c/545633/
[1] https://review.openstack.org/#/c/436798


> >>
> >> ===
> >>
> >> Last several cycles we were working on getting lib/neutron - the new
> >> in-tree devstack library to deploy neutron services - ready to deploy
> >> configurations we may need in our gates.
> >
> >
> > May I ask the reason for hosting this in the neutron tree?
>
> Sorry for wording it in a misleading way. The lib/neutron library is
> in *devstack* tree:
> https://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron
> So in terms of deployment dependencies, there are no new repositories
> to fetch from or gate against.
>
> >
> >>
> >> Some pieces of the work
> >> involved can be found in:
> >>
> >> https://review.openstack.org/#/q/topic:new-neutron-devstack-in-gate
> >>
> >> I am happy to announce that the work finally got to the point where we
> >> can consistently pass both devstack-gate and neutron gates:
> >>
> >> (devstack-gate) https://review.openstack.org/436798
> >
> >
> > Both legacy and new style (zuulv3) jobs rely on the same test matrix
> code,
> > so your change would impact both worlds consistently, which is good.
> >
> >>
> >>
> >> (neutron) https://review.openstack.org/441579
> >>
> >> One major difference between the old lib/neutron-legacy library and
> >> the new lib/neutron one is that service names for neutron are
> >> different. For example, q-svc is now neutron-api, q-dhcp is now
> >> neutron-dhcp, etc. (In case you wonder, this q- prefix links us back
> >> to times when Neutron was called Quantum.) The way lib/neutron is
> >> designed is that whenever a single q-* service name is present in
> >> ENABLED_SERVICES, the old lib/neutron-legacy code is triggered to
> >> deploy services.
> >>
> >> Service name changes are a large part of the work. The way the
> >> devstack-gate change linked above is designed is that it changes names
> >> for deployed neutron services starting from Queens (current master),
> >> so old branches and grenade jobs are not affected by the change.
> >
> >
> > Any other change worth mentioning?
> >
>
> The new library is a lot more simplified and opinionated and has fewer
> knobs and branching that is not very useful for majority of users.
> lib/neutron-legacy was always known for its complicated configuration.
> We hope that adopting the new library will unify and simplify neutron
> configuration across different jobs and setups.
>
> From consumer perspective, nothing should change expect service names.
> Some localrc files may need adoption if they rely on old arcane knobs.
> It can be done during transition phase since old service names are
> expected to work.
>
> >>
> >>
> >> While we validated the change switching to new names against both
> >> devstack-gate and neutron gates that should cover 90% of our neutron
> >> config

Re: [openstack-dev] [k8s] SIG-K8s Scheduling for Dublin PTG

[Andrea Frittoli]

On Wed, Feb 21, 2018 at 7:41 PM Chris Hoge  wrote:

> SIG-K8s has a planning etherpad available for the Dublin PTG. We have
> space scheduled for Tuesday, with approximately eight forty-minute work
> blocks. For the K8s on OpenStack side of things, we've identified a core
> set of priorities that we'll be working on that day, including:
>
> * Moving openstack-cloud-controller-manager into OpenStack git repo.
> * Enabling and improving testing across multiple platforms.
> * Identifying documentation gaps.
>
> Some of these items have some collaboration points with the Infra and
> QA teams. If members of those teams could help us identify when they
> would be available to work on repository creation and enabling testing,
> that would help us to schedule the appropriate times for those topics.
>

I'm interested in participating. It's a bit unfortunate that Tuesday
overlaps with
the QA/infra help room, but as long as the current discussion is published
via PTG bot I should be able to switch rooms when needed.

Andrea Frittoli (andreaf)


>
> The work of the SIG-K8s groups also covers other Kubernetes and OpenStack
> integrations, including deploying OpenStack on top of Kubernetes. If
> anyone from the Kolla, OpenStack-Helm, Loci, Magnum, Kuryr, or Zun
> teams would like to schedule cross-project work sessions, please add your
> requests and preferred times to the planning etherpad. Additionally, I
> can be available to attend work sessions for any of those projects.
>
> https://etherpad.openstack.org/p/sig-k8s-2018-dublin-ptg
>
> Thanks!
> Chris
>
>
> __
> 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

[openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Andrea Frittoli]

Dear all,

updates:

- host/group vars: zuul now supports declaring host and group vars in the
job definition [0][1] - thanks corvus and infra team!
  This is a great help towards writing the devstack and tempest base
multinode jobs [2][3]
  * NOTE: zuul merges dict variables through job inheritance. Variables in
host/group_vars override global ones. I will write some examples further
clarify this.

- stable/pike: devstack ansible changes have been backported to
stable/pike, so we can now run zuulv3 jobs against stable/pike too - thank
you tosky!
  next change in progress related to pike is to provide tempest-full-pike
for branchless repositories [4]

- documentation: devstack now publishes documentation on its ansible roles
[5].
  More devstack documentation patches are in progress to provide jobs
reference, examples and a job migration how-to [6].


Andrea Frittoli (andreaf)

[0]
https://docs.openstack.org/infra/zuul/user/config.html#attr-job.host_vars
[1]
https://docs.openstack.org/infra/zuul/user/config.html#attr-job.group_vars
[2] https://review.openstack.org/#/c/545696/
[3] https://review.openstack.org/#/c/545724/
[4] https://review.openstack.org/#/c/546196/
[5] https://docs.openstack.org/devstack/latest/roles.html
[6] https://review.openstack.org/#/c/545992/

On Mon, Feb 19, 2018 at 2:46 PM Andrea Frittoli 
wrote:

> Dear all,
>
> updates:
> - tempest-full-queens and tempest-full-py3-queens are now available for
> testing of branchless repositories [0]. They are used for tempest and
> devstack-gate. If you own a tempest plugin in a branchless repo, you may
> consider adding similar jobs to your plugin if you use it for tests on
> stable/queen as well.
> - if you have migrated jobs based on devstack-tempest please let me know,
> I'm building reference docs and I'd like to include as many examples as
> possible
> - work on multi-node is in progress, but not ready still - you can follow
> the patches in the multinode branch [1]
> - updates on some of the points from my previous email are inline below
>
> Andrea Frittoli (andreaf)
>
> [0] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n73
> [1]
> https://review.openstack.org/#/q/status:open++branch:master+topic:multinode
>
>
>
> On Thu, Feb 15, 2018 at 11:31 PM Andrea Frittoli <
> andrea.fritt...@gmail.com> wrote:
>
>> Dear all,
>>
>> this is the first or a series of ~regular updates on the migration of
>> Tempest / Grenade jobs to  Zuul v3 native.
>>
>> The QA team together with the infra team are working on providing the
>> OpenStack community with a set of base Tempest / Grenade jobs that can be
>> used as a basis to write new CI jobs / migrate existing legacy ones with a
>> minimal effort and very little or no Ansible knowledge as a precondition.
>>
>> The effort is tracked in an etherpad [0]; I'm trying to keep the
>> etherpad up to date but it may not always be a source of truth.
>>
>> Useful jobs available so far:
>> - devstack-tempest [0] is a simple tempest/devstack job that runs
>> keystone glance nova cinder neutron swift and tempest *smoke* filter
>> - tempest-full [1] is similar but runs a full test run - it replaces the
>> legacy tempest-dsvm-neutron-full from the integrated gate
>> - tempest-full-py3 [2] runs a full test run on python3 - it replaces the
>> legacy tempest-dsvm-py35
>>
>
> Some more details on this topic: what I did not mention in my previous
> email is that the autogenerated Tempest / Grenade CI jobs (legacy-*
> playbooks) are not meant to be used as a basis for Zuul V3 native jobs. To
> create Zuul V3 Tempest / Grenade native jobs for your projects you need to
> through away the legacy playbooks and defined new jobs in .zuul.yaml, as
> documented in the zuul v3 docs [2].
> The parent job for a single node Tempest job will usually be
> devstack-tempest. Example migrated jobs are avilable, for instance: [3] [4].
>
> [2]
> https://docs.openstack.org/infra/manual/zuulv3.html#howto-update-legacy-jobs
>
> [3]
> http://git.openstack.org/cgit/openstack/sahara-tests/tree/.zuul.yaml#n21
> [4] https://review.openstack.org/#/c/543048/5
>
>
>>
>> Both tempest-full and tempest-full-py3 are part of integrated-gate
>> templates, starting from stable/queens on.
>> The other stable branches still run the legacy jobs, since
>> devstack ansible changes have not been backported (yet). If we do backport
>> it will be up to pike maximum.
>>
>> Those jobs work in single node mode only at the moment. Enabling
>> multinode via job configuration only require a new Zuul feature [4][5] that
>> should be available soon; the new feature allows defining host/group
>> variables in the job de

Re: [openstack-dev] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Andrea Frittoli]

Dear all,

updates:
- tempest-full-queens and tempest-full-py3-queens are now available for
testing of branchless repositories [0]. They are used for tempest and
devstack-gate. If you own a tempest plugin in a branchless repo, you may
consider adding similar jobs to your plugin if you use it for tests on
stable/queen as well.
- if you have migrated jobs based on devstack-tempest please let me know,
I'm building reference docs and I'd like to include as many examples as
possible
- work on multi-node is in progress, but not ready still - you can follow
the patches in the multinode branch [1]
- updates on some of the points from my previous email are inline below

Andrea Frittoli (andreaf)

[0] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n73
[1]
https://review.openstack.org/#/q/status:open++branch:master+topic:multinode


On Thu, Feb 15, 2018 at 11:31 PM Andrea Frittoli 
wrote:

> Dear all,
>
> this is the first or a series of ~regular updates on the migration of
> Tempest / Grenade jobs to  Zuul v3 native.
>
> The QA team together with the infra team are working on providing the
> OpenStack community with a set of base Tempest / Grenade jobs that can be
> used as a basis to write new CI jobs / migrate existing legacy ones with a
> minimal effort and very little or no Ansible knowledge as a precondition.
>
> The effort is tracked in an etherpad [0]; I'm trying to keep the
> etherpad up to date but it may not always be a source of truth.
>
> Useful jobs available so far:
> - devstack-tempest [0] is a simple tempest/devstack job that runs keystone
> glance nova cinder neutron swift and tempest *smoke* filter
> - tempest-full [1] is similar but runs a full test run - it replaces the
> legacy tempest-dsvm-neutron-full from the integrated gate
> - tempest-full-py3 [2] runs a full test run on python3 - it replaces the
> legacy tempest-dsvm-py35
>

Some more details on this topic: what I did not mention in my previous
email is that the autogenerated Tempest / Grenade CI jobs (legacy-*
playbooks) are not meant to be used as a basis for Zuul V3 native jobs. To
create Zuul V3 Tempest / Grenade native jobs for your projects you need to
through away the legacy playbooks and defined new jobs in .zuul.yaml, as
documented in the zuul v3 docs [2].
The parent job for a single node Tempest job will usually be
devstack-tempest. Example migrated jobs are avilable, for instance: [3] [4].

[2]
https://docs.openstack.org/infra/manual/zuulv3.html#howto-update-legacy-jobs

[3] http://git.openstack.org/cgit/openstack/sahara-tests/tree/.zuul.yaml#n21

[4] https://review.openstack.org/#/c/543048/5


>
> Both tempest-full and tempest-full-py3 are part of integrated-gate
> templates, starting from stable/queens on.
> The other stable branches still run the legacy jobs, since
> devstack ansible changes have not been backported (yet). If we do backport
> it will be up to pike maximum.
>
> Those jobs work in single node mode only at the moment. Enabling multinode
> via job configuration only require a new Zuul feature [4][5] that should be
> available soon; the new feature allows defining host/group variables in the
> job definition, which means setting variables which are specific to one
> host or a group of hosts.
> Multinode DVR and Ironic jobs will require migration of the ovs-* roles
> form devstack-gate to devstack as well.
>
> Grenade jobs (single and multinode) are still legacy, even if the *legacy*
> word has been removed from the name.
> They are currently temporarily hosted in the neutron repository. They are
> going to be implemented as Zuul v3 native in the grenade repository.
>
> Roles are documented, and a couple of migration tips for DEVSTACK_GATE
> flags is available in the etherpad [0]; more comprehensive examples /
> docs will be available as soon as possible.
>
> Please let me know if you find this update useful and / or if you would
> like to see different information in it.
> I will send further updates as soon as significant changes / new features
> become available.
>
> Andrea Frittoli (andreaf)
>
> [0] https://etherpad.openstack.org/p/zuulv3-native-devstack-tempest-jobs
> [1] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n1
> [2] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n29
> [3] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n47
> [4] https://etherpad.openstack.org/p/zuulv3-group-variables
> [5] https://review.openstack.org/#/c/544562/
>
__
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] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Andrea Frittoli]

Dear all,

this is the first or a series of ~regular updates on the migration of
Tempest / Grenade jobs to  Zuul v3 native.

The QA team together with the infra team are working on providing the
OpenStack community with a set of base Tempest / Grenade jobs that can be
used as a basis to write new CI jobs / migrate existing legacy ones with a
minimal effort and very little or no Ansible knowledge as a precondition.

The effort is tracked in an etherpad [0]; I'm trying to keep the
etherpad up to date but it may not always be a source of truth.

Useful jobs available so far:
- devstack-tempest [0] is a simple tempest/devstack job that runs keystone
glance nova cinder neutron swift and tempest *smoke* filter
- tempest-full [1] is similar but runs a full test run - it replaces the
legacy tempest-dsvm-neutron-full from the integrated gate
- tempest-full-py3 [2] runs a full test run on python3 - it replaces the
legacy tempest-dsvm-py35

Both tempest-full and tempest-full-py3 are part of integrated-gate
templates, starting from stable/queens on.
The other stable branches still run the legacy jobs, since devstack ansible
changes have not been backported (yet). If we do backport it will be up to
pike maximum.

Those jobs work in single node mode only at the moment. Enabling multinode
via job configuration only require a new Zuul feature [4][5] that should be
available soon; the new feature allows defining host/group variables in the
job definition, which means setting variables which are specific to one
host or a group of hosts.
Multinode DVR and Ironic jobs will require migration of the ovs-* roles
form devstack-gate to devstack as well.

Grenade jobs (single and multinode) are still legacy, even if the *legacy*
word has been removed from the name.
They are currently temporarily hosted in the neutron repository. They are
going to be implemented as Zuul v3 native in the grenade repository.

Roles are documented, and a couple of migration tips for DEVSTACK_GATE
flags is available in the etherpad [0]; more comprehensive examples /
docs will be available as soon as possible.

Please let me know if you find this update useful and / or if you would
like to see different information in it.
I will send further updates as soon as significant changes / new features
become available.

Andrea Frittoli (andreaf)

[0] https://etherpad.openstack.org/p/zuulv3-native-devstack-tempest-jobs
[1] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n1
[2] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n29
[3] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n47
[4] https://etherpad.openstack.org/p/zuulv3-group-variables
[5] https://review.openstack.org/#/c/544562/
__
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] [PTL][SIG][PTG]Team Photos

[Andrea Frittoli]

I set Thursday 12:00-12:10 for the QA team.

Andrea Frittoli (andreaf)

On Thu, Feb 15, 2018 at 9:56 PM Kendall Nelson 
wrote:

> Updates!
>
> So, we have gotten permission to do photos down on the pitch at the
> stadium which is awesome!
>
> The only issue is that we need to condense into a more dense blocks
> (Tuesday afternoon or Thursday morning) so looking at the schedule we have
> to move some teams. If the following teams could move their times so that
> we can make this happen:
>
>- QA
>- SIG K8s
>- Cyborg
>- Neutron
>- Octavia
>- Requirements
>- Release Mgmt
>- OpenStack Ansible
>- Cinder
>
> I'm really sorry to make you guys move, but since we need to pay for an
> escort (with a 4 hour minimum) and don't want to conflict with lunch, we
> need to shift.
>
> We will have your team meet at registration at your selected time. Because
> we get to go on the pitch and this requires an escort, you NEED TO BE AT
> REG ON TIME OR EARLY. If you aren't, you will miss your chance to be in the
> photo.
>
> I will send out a reminder on Monday of PTG week.
>
> -Kendall (diablo_rojo)
>
> On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson 
> wrote:
>
>> This link might work better for everyone:
>>
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>
>> -Kendall (diablo_rojo)
>>
>>
>> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson 
>> wrote:
>>
>>> Hello PTLs and SIG Chairs!
>>>
>>> So here's the deal, we have 50 spots that are first come, first
>>> served. We have slots available before and after lunch both Tuesday and
>>> Thursday.
>>>
>>> The google sheet here[1] should be set up so you have access to edit,
>>> but if you can't for some reason just reply directly to me and I can add
>>> your team to the list (I need team/sig name and contact email).
>>>
>>> I will be locking the google sheet on *Monday February 26th so I need
>>> to know if your team is interested by then. *
>>>
>>> See you soon!
>>>
>>> - Kendall Nelson (diablo_rojo)
>>>
>>> [1]
>>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>>
>>>
>>>
>>>
>>>
__
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] [QA][stable] Py3 integration jobs on stable

[Andrea Frittoli]

Dear all,

since it's now RC1 time, C1 we're setting up CI jobs for stable branches
and periodic-stable jobs for stable/queens.

In the past, we used to run the py27 based tempest-full integration job
(legacy-tempest-dsvm-neutron-full).
With all the effort that went into py3 support, I think it's time to start
running the py3 integration job as well against stable branches.

The integrated-gate-py35 [1] already includes stable/queens.
I proposed a patch for the periodic-stable pipeline [2].

Please let me know if you have any concern.

Andrea Frittoli (andreaf)

[1]
https://github.com/openstack-infra/openstack-zuul-jobs/blob/master/zuul.d/project-templates.yaml#L1008

[2] https://review.openstack.org/#/c/521888/
__
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][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

[Andrea Frittoli]

On Wed, Feb 14, 2018 at 4:05 PM James E. Blair  wrote:

> Andrea Frittoli  writes:
>
> >> That has no irrelevant-files matches, and so matches everything.  If you
> >> drop the use of that template, it will work as expected.  Or, if you can
> >> say with some certainty that nova's irrelevant-files set is not
> >> over-broad, you could move the irrelevant-files from nova's invocation
> >> into the template, or even the job, and drop nova's individual
> >> invocation.
> >>
> > I don't think projects in the integrated gate should remove themselves
> > from the
> > template, it really helps keeping consistency.
> >
> > The pattern I've seen is that most projects repeat the same list of
> > irrelevant files
> > over and over again in all of their integration tests, It would be handy
> in
> > future to
> > be able to set irrelevant-files on a template when it's consumed.
> > So we could have shared irrelevant files defined in the template, and
> > custom ones
> > added by each project when consuming the template. I don't this is is
> > possible today.
> > Does it sound like a reasonable feature request?
>
> A template may specify many jobs, so if we added something like that
> feature, what would the project-pipeline template application's
> irrelevant files apply to?  All of the jobs in the template?  We could
> do that.


That's what I was thinking about,


> But it only takes one exception for this approach to fall
> short, and while a lot of irrelevant-files stanzas for a project are
> similar, I don't think having exceptions will be unusual.  The only way
> to handle exceptions like that is to specify them with jobs, and we're
> back in the same situation.
>
> Also, combining irrelevant-files is very difficult to think about.
> Because it's two inverse matches, combining them ends up being the
> intersection, not the union.  So if we implemented this, I don't think
> we should have any irrelevant-files in the template, only on template
> application.
>
> I still tend to think that irrelevant-files are almost invariably
> project-specific, so we should avoid using them in templates and job
> definitions (unless absolutely certain they are universally applicable),
> and we should only define them in one place -- in the project-pipeline
> definition for individual jobs.
>

I agree with your concerns, but the problem is that the current
implementation
renders job templates rather useless. Each project has to re-add each job
in a
template in its pipeline content definition to be able to apply irrelevant
files, and
that will turn stale if a template is modified.

With the migration to zuulv3 native jobs there is a lot of job renaming and
adding/
removing jobs going on, so for instance if a job is removed what used to be
a setting
irrelevant files may become running an extra job.

I don't really have a solution for this, but perhaps someone has an idea?

Andrea Frittoli (andreaf)


> -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

Re: [openstack-dev] [nova][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

[Andrea Frittoli]

On Fri, Jan 26, 2018 at 5:57 PM James E. Blair  wrote:

> Balázs Gibizer  writes:
>
> > Hi,
> >
> > I'm getting more and more confused how the zuul job hierarchy works or
> > is supposed to work.
>
> Hi!
>
> First, you (or others) may or may not have seen this already -- some of
> it didn't exist when we first rolled out v3, and some of it has changed
> -- but here are the relevant bits of the documentation that should help
> explain what's going on.  It helps to understand freezing:
>
>   https://docs.openstack.org/infra/zuul/user/config.html#job
>
> and matching:
>
>   https://docs.openstack.org/infra/zuul/user/config.html#matchers
>
> > First there was a bug in nova that some functional tests are not
> > triggered although the job (re-)definition in the nova part of the
> > project-config should not prevent it to run [1].
> >
> > There we figured out that irrelevant-files parameter of the jobs are
> > not something that can be overriden during re-definition or through
> > parent-child relationship. The base job openstack-tox-functional has
> > an irrelevant-files attribute that lists '^doc/.*$' as a path to be
> > ignored [2]. In the other hand the nova part of the project-config
> > tries to make this ignore less broad by adding only '^doc/source/.*$'
> > . This does not work as we expected and the job did not run on changes
> > that only affected ./doc/notification_samples path. We are fixing it
> > by defining our own functional job in nova tree [4].
> >
> > [1] https://bugs.launchpad.net/nova/+bug/1742962
> > [2]
> >
> https://github.com/openstack-infra/openstack-zuul-jobs/blob/1823e3ea20e6dfaf37786a6ff79c56cb786bf12c/zuul.d/jobs.yaml#L380
> > [3]
> >
> https://github.com/openstack-infra/project-config/blob/1145ab1293f5fa4d34c026856403c22b091e673c/zuul.d/projects.yaml#L10509
> > [4] https://review.openstack.org/#/c/533210/
>
> This is correct.  The issue here is that the irrelevant-files definition
> on openstack-tox-functional is too broad.  We need to be *extremely*
> careful applying matchers to jobs like that.  Generally I think that
> irrelevant-files should be reserved for the project-pipeline invocations
> only.  That's how they were effectively used in Zuul v2, after all.
>
> Essentially, when someone puts an irrelevant-files section on a job like
> that, they are saying "this job will never apply to these files, ever."
> That's clearly not correct in this case.
>
> So our solutions are to acknowledge that it's over-broad, and reduce or
> eliminate the list in [2] and expand it elsewhere (as in [3]).  Or we
> can say "we were generally correct, but nova is extra special so it
> needs its own job".  If that's the choice, then I think [4] is a fine
> solution.
>
> > Then I started looking into other jobs to see if we made similar
> > mistakes. I found two other examples in the nova related jobs where
> > redefining the irrelevant-files of a job caused problems. In these
> > examples nova tried to ignore more paths during the override than what
> > was originally ignored in the job definition but that did not work
> > [5][6].
> >
> > [5] https://bugs.launchpad.net/nova/+bug/1745405 (temptest-full)
>
> As noted in that bug, the tempest-full job is invoked on nova via this
> stanza:
>
>
> https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10674-L10688
>
> As expected, that did not match.  There is a second invocation of
> tempest-full on nova here:
>
>
> http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/zuul-legacy-project-templates.yaml#n126


I guess the line number changed since so this has moved to L101 [1] now :).
tempest-full is part of the integrated-gate, so all projects in it run it
through there.

[1]
http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/zuul.d/zuul-legacy-project-templates.yaml#n101


>
>
> That has no irrelevant-files matches, and so matches everything.  If you
> drop the use of that template, it will work as expected.  Or, if you can
> say with some certainty that nova's irrelevant-files set is not
> over-broad, you could move the irrelevant-files from nova's invocation
> into the template, or even the job, and drop nova's individual
> invocation.
>
> I don't think projects in the integrated gate should remove themselves
from the
template, it really helps keeping consistency.

The pattern I've seen is that most projects repeat the same list of
irrelevant files
over and over again in all of their inte

Re: [openstack-dev] [nova][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

[Andrea Frittoli]

On Fri, Jan 26, 2018 at 2:05 PM Balázs Gibizer 
wrote:

> Hi,
>
> I'm getting more and more confused how the zuul job hierarchy works or is
> supposed to work.
>
> First there was a bug in nova that some functional tests are not triggered
> although the job (re-)definition in the nova part of the project-config
> should not prevent it to run [1].
>
> There we figured out that irrelevant-files parameter of the jobs are not
> something that can be overriden during re-definition or through
> parent-child relationship. The base job openstack-tox-functional has an
> irrelevant-files attribute that lists '^doc/.*$' as a path to be ignored
> [2]. In the other hand the nova part of the project-config tries to make
> this ignore less broad by adding only '^doc/source/.*$' . This does not
> work as we expected and the job did not run on changes that only affected
> ./doc/notification_samples path. We are fixing it by defining our own
> functional job in nova tree [4].
>
> [1] https://bugs.launchpad.net/nova/+bug/1742962
> [2]
> https://github.com/openstack-infra/openstack-zuul-jobs/blob/1823e3ea20e6dfaf37786a6ff79c56cb786bf12c/zuul.d/jobs.yaml#L380
> [3]
> https://github.com/openstack-infra/project-config/blob/1145ab1293f5fa4d34c026856403c22b091e673c/zuul.d/projects.yaml#L10509
> [4] https://review.openstack.org/#/c/533210/
>
> Then I started looking into other jobs to see if we made similar mistakes.
> I found two other examples in the nova related jobs where redefining the
> irrelevant-files of a job caused problems. In these examples nova tried to
> ignore more paths during the override than what was originally ignored in
> the job definition but that did not work [5][6].
>
> [5] https://bugs.launchpad.net/nova/+bug/1745405 (temptest-full)
> [6] https://bugs.launchpad.net/nova/+bug/1745431 (neutron-grenade)
>
> So far the problem seemed to be consistent (i.e. override does not work).
> But then I looked into neutron-grenade-multinode. That job is defined in
> neutron tree (like neutron-grenade)
>

That is wrong and it should not have happened.
Grenade jobs that are shared by all the repos in the integrated gate should
live in repos owned by QA/infra - it was never the plan for them to end up
in the neutron repo.
We're working on making grenade and multinode zuulv3 native jobs. Grenade
jobs will leave in the grenade repo, once they're ready we will remove the
legacy one from neutron side and add the new ones defined in grenade.
Changes will be done to the job template accordingly which means that for
teams that are consuming those jobs via the template only there'll be no
action.

Andrea Frittoli (andreaf)


> but nova also refers to it in nova section of the project-config with
> different irrelevant-files than their original definition. So I assumed
> that this will lead to similar problem than in case of neutron-grenade, but
> it doesn't.
>
> The neutron-grenade-multinode original definition [1] does not try to
> ignore the 'nova/tests' path but the nova side of the definition in the
> project config does try to ignore that path [8]. Interestingly a patch in
> nova that only changes under the path: nova/tests/ does not trigger the job
> [9]. So in this case overriding the irrelevant-files of a job works. (It
> seems that overriding neutron-tempest-linuxbridge irrelevant-files works
> too).
>
> [7]
> https://github.com/openstack/neutron/blob/7e3d6a18fb928bcd303a44c1736d0d6ca9c7f0ab/.zuul.yaml#L140-L159
> [8]
> https://github.com/openstack-infra/project-config/blob/5ddbd62a46e17dd2fdee07bec32aa65e3b637ff3/zuul.d/projects.yaml#L10516-L10530
> [9] https://review.openstack.org/#/c/537936/
>
> I don't see what is the difference between neutron-grenade and
> neutron-grenade-multinode jobs definitions from this perspective but it
> seems that the irrelevent-files attribute behaves  inconsistently in these
> two jobs. Could you please help me undestand how irrelevant-files in
> overriden jobs supposed to work?
>
> cheers,
> gibi
>
>
>
> __
> 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] [all][infra] PTG Infra Helproom Info and Signup

[Andrea Frittoli]

On Wed, Feb 14, 2018 at 10:42 AM Thierry Carrez 
wrote:

> Clark Boylan wrote:
> > Last PTG the infra helproom seemed to work out for projects that knew
> about it. The biggest problem seemed to be that other projects either just
> weren't aware that there is/was an Infra helproom or didn't know when an
> appropriate time to show up would be. We are going to try a couple things
> this time around to try and address those issues.
> >
> > First of all the Infra team is hosting a helproom at the Dublin PTG. Now
> you should all know :) The idea is that if projects or individuals have
> questions for the infra team or problems that we can help you with there is
> time set aside specifically for this. I'm not sure what room we will be in,
> you will have to look at the map, but we have the entirety of Monday and
> Tuesday set aside for this.
>
> Also worth noting that it is a "project infrastructure" helproom, in the
> largest sense. It goes beyond the "Infra" team: you can bring any
> question around project support from horizontal support teams like QA,
>

Indeed, thanks for pointing that out.

A lot of us from the QA team will be in Dublin, available during the help
ours for questions or topics you may want to discuss.
There's usually enough time to sit down and hack a few things on the
spot... and there are enough infra/qa cores around to get things reviewed
and merged during the week.

On the QA side we don't have an ethercalc (yet?) but if there are topics
you would like to discuss / develop please add something to the etherpad.

Andrea Frittoli (andreaf)

[1] https://etherpad.openstack.org/p/qa-rocky-ptg


> release management, requirements, stable team...
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [infra] [all] project pipeline definition should stay in project-config or project side ?

[Andrea Frittoli]

On Tue, Feb 13, 2018 at 3:06 PM Paul Belanger  wrote:

> On Tue, Feb 13, 2018 at 11:05:34PM +0900, gmann wrote:
> > Hi Infra Team,
> >
> > I have 1 quick question on zuulv3 jobs and their migration part. From
> > zuulv3 doc [1], it is clear about migrating the job definition and use
> > those among cross repo pipeline etc.
> >
> > But I did not find clear recommendation that whether project's
> > pipeline definition should stay in project-config or we should move
> > that to project side.
> >
> > IMO,
> > 'template' part(which has system level jobs) can stay in
> > project-config. For example below part-


I think there are pros and cons in both cases, but I lean more towards
having everything
in tree.

If everything moves into the project then the configuration of what runs
for a project is more
or less in one place, so it's a bit more readable and projects are in
control.

On the other side adding a template maintained by infra/qa to a number of
projects transforms
into a potentially very large set of changes. But I don't think adding a
new template happens
so often, and it would still be possible for infra/qa to define usage of
that template in project-config
and then for projects to move that in tree over time.

Andrea Frittoli (andreaf)

>
> >
> https://github.com/openstack-infra/project-config/blob/e2b82623a4ab60261b37a91e38301927b9b6/zuul.d/projects.yaml#L10507-L10523
> >
> > Other pipeline definition- 'check', 'gate', 'experimental' etc should
> > be move to project repo, mainly this list-
> >
> https://github.com/openstack-infra/project-config/blob/master/zuul.d/projects.yaml#L10524-L11019
> >
> > If we move those past as mentioned above then, we can have a
> > consolidated place to control the project pipeline for
> > 'irrelevant-files', specific branch etc
> >
> > ..1 https://docs.openstack.org/infra/manual/zuulv3.html
> >
> As it works today, pipeline stanza needs to be in a config project[1]
> (project-config) repo. So what you are suggestion will not work. This was
> done
> to allow zuul admins to control which pipelines are setup / configured.
>

I think gmann referred to the list of jobs defined in each pipeline by a
project
as opposed to the definition of the pipeline itself.


>
> I am mostly curious why a project would need to modify a pipeline
> configuration
> or duplicate it into all projects, over having it central located in
> project-config.
>
> [1] https://docs.openstack.org/infra/zuul/user/config.html#pipeline
> >
> > -gmann
> >
> >
> __
> > 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
>
__
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-sigs] [PTL][SIG][PTG]Team Photos

[Andrea Frittoli]

On Thu, Feb 8, 2018 at 6:21 PM Kendall Nelson  wrote:

> This link might work better for everyone:
>
> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>

+1 thanks this is editable

>
> -Kendall (diablo_rojo)
>
>
> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson 
> wrote:
>
>> Hello PTLs and SIG Chairs!
>>
>> So here's the deal, we have 50 spots that are first come, first
>> served. We have slots available before and after lunch both Tuesday and
>> Thursday.
>>
>> The google sheet here[1] should be set up so you have access to edit, but
>> if you can't for some reason just reply directly to me and I can add your
>> team to the list (I need team/sig name and contact email).
>>
>> I will be locking the google sheet on *Monday February 26th so I need to
>> know if your team is interested by then. *
>>
>> See you soon!
>>
>> - Kendall Nelson (diablo_rojo)
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>
>>
>>
>>
>> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
__
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] [PTL][SIG][PTG]Team Photos

[Andrea Frittoli]

Hello Kendall,

QA Team Tue at 11:00 please :)

Andrea

On Thu, Feb 8, 2018 at 5:37 PM Kendall Nelson  wrote:

> Done!
>
> On Thu, 8 Feb 2018, 8:56 am Miguel Lavalle,  wrote:
>
>> Hi Kendall,
>>
>> Can you add Neutron on Thursday at 2pm. If that is not available, then
>> anytime Wednesday or Thursday. I am the contact: mig...@mlavalle.com
>>
>> Thanks
>>
>> On Wed, Feb 7, 2018 at 11:15 PM, Kendall Nelson 
>> wrote:
>>
>>> Hello PTLs and SIG Chairs!
>>>
>>> So here's the deal, we have 50 spots that are first come, first
>>> served. We have slots available before and after lunch both Tuesday and
>>> Thursday.
>>>
>>> The google sheet here[1] should be set up so you have access to edit,
>>> but if you can't for some reason just reply directly to me and I can add
>>> your team to the list (I need team/sig name and contact email).
>>>
>>> I will be locking the google sheet on *Monday February 26th so I need
>>> to know if your team is interested by then. *
>>>
>>> See you soon!
>>>
>>> - Kendall Nelson (diablo_rojo)
>>>
>>> [1]
>>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>>
>>>
>>>
>>>
>>>
>>>
>>> __
>>> 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
>>
> __
> 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

[openstack-dev] [QA] Rocky QA PTL candidacy

[Andrea Frittoli]

Dear all,

I’d like to announce my candidacy [1] for PTL of the QA Program for the
Rocky cycle.

I served as PTL for QA during the Pike and Queens cycles, and I would be
honoured to continue to do so in the next six months.

After a few years working with the OpenStack community, I continue to find
it an exceptional experience and a great opportunity for meeting and working
with great people, learning and innovating.

In the past cycle, we focused on providing good and stable interfaces in
QA projects for everyone to use. Meanwhile, we supported the OpenStack
community in the implementation of the Tempest plugin community goal.

This should mean fewer headaches for everyone with Tempest plugins,
and a bit more time for the QA team to focus on key areas like the gate
stability and bug triage.

Outside of those key areas, my priority always remains serving the
community,
by providing tools, support and advice. There are a few specific topics I
care particularly about for the Rocky cycle:

- Migration to Zuul v3: my key objective is for project teams to be able
  to migrate as effortless as possible, enjoy the benefits of Zuul v3 and
  focus on the things they want to work on.
  To achieve this the QA team will provide a good set of base jobs and
  ansible roles for everyone to re-use.
  During Queens we implemented base devstack and devstack-tempest jobs
  already; next up are multinode support and grenade, which cover most
  of the things that we do in Tempest legacy jobs today.

- Interoperability testing: with the new add-on programs, I expect that
  the teams involved will need prompt support and test reviews from the
  QA team.

- QA beyond the gate: there is a lot of quality engineering happening on
  OpenStack beyond the testing we do in the gate and I strive to ensure
  that those efforts do not happen in isolation. There is opportunity
  for sharing of ideas, tools, experiences - even beyond the OpenStack
  community, through initiatives like OpenLab and OPNVF. A QA SIG may be
  a good forum to make this happen.

- Supporting teams working on the cold upgrade goal along with the goal
  champion.

Thank you!

Andrea Frittoli (andreaf)

[1] https://review.openstack.org/#/c/540542/
__
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] [all][tc] Clarifying testing recommendation for interop programs

[Andrea Frittoli]

On Mon, Jan 22, 2018 at 3:05 PM Graham Hayes  wrote:

>
>
> On 19/01/18 16:27, Andrea Frittoli wrote:
> >
> > Thanks for the summary!
> >
> > To be honest I don't see why this decision has to be difficult to take.
>
> I think the confusion comes from one thing being decided already, and
> now conflicting direction is being given to teams, without anyone
> updating the Governance repo.
>
> (It is not as if there was not plenty of warning, I have been raising it
> as an issue for over a year)
>
> > Nothing we decide today is written in stone and the main risk ahead of
> > us is to take
> > a decision that requires a lot of upfront work and that it ends up
> > providing no
> > significant benefit, or even making things worst in some aspect. So we
> > may try one way
> > today and if we hit some significant issue we can still change.
> >
> > TL;DR my preferred option would be number (2) - it's the least initial
> > effort, so the
> > least risk, and deciding for (2) now won't make it any difficult in the
> > future to switch
> > to option (1) or option (3). I'm not pushing back on (2), I just think
> > (1) is more convenient.
> > Details below each option.
> >
> >
> >
> > So far the patch proposes three options:
> >
> > 1) All trademark-related tests should go in the tempest repo, in
> > accordance
> >with the original resolution. This would mean that even projects
> > that have
> >never had tests in tempest would now have to add at least some of
> > their
> >black-box tests to tempest.
> >
> >
> > This option is a valid one, but I think it introduces too much extra
> > work and
> > testing complications for too little benefit.
>
> What it does do is *guarantee* that the InterOp suite will work, as it
> will be CI'd. I see these programs as important enough that we should CI
> the tooling used for them, but I seem to be in a minority.
>

Add-ons intreoperability tests will be CI'd for every change in Tempest as
long
as they are executed in a job that runs on every change in Tempest.

This can be achieve regardless of the location of the tests and having the
tests
in the Tempest tree is not by itself a guarantee that they will be executed
against
every change.



>
> >
> >
> > The value of this option is that centralizes tests used for the
> > Interop program
> > in a location where interop-minded folks from the QA team can
> > control them.
> >
> >
> > There are other ways this can be achieved - it is possible to mark tests
> > so that
> > team may require a +1 from interop/qa when specific tests are modified.
>
> Is there? AFAIK gerrit does not do per file path permissions, so unless
> we have a job that just checks the votes on a patch, and passes or fails
> if a test changes (which would be awful for the teams) we cannot do
> that.
>

If we really want to enforce having a vote from someone it may be tricky,
yes, but I don't think enforcement is what we need, rather awareness,
For governance and project-config patches reviewed always ask for a +1
from the project PTL where relevant, and add-on project reviewers could
do the same.

To help building awareness we could have automation in place to post a
comment to Gerrit, like we do for elastic recheck. We could do that
on every change to the plugin in the beginning and include  a link to the
interoperability recommendation to help reviewers in their job.


>
> >
> >
> > The
> > downside is that projects that so far have avoided having a
> > dependency on
> > tempest will now lose some control over the black-box tests that
> > they use for
> > functional and integration that would now also be used for trademark
> > certification.
> > There's also concern for the review bandwidth of the QA team - we
> > can't expect
> > the QA team to be continually responsible for an ever-growing list
> > of projects
> > and their trademark tests.
> >
> >
> > If we restrict to interop tests, the review bandwidth issue is probably
> > not so bad.
> > The QA team would have to request the domain knowledge required for
> proper
> > review from the respective teams anyways.
> >
> > There are other complications introduced though:
> >
> > - service clients and other common bits (config and so) would have to
> > move to
> >   Tempest since we cannot have tempest depend on plugins. But then
> modifying
> >   those 

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [QA] Proposal for a QA SIG

[Andrea Frittoli]

Hello everyone,

After a long holiday break I would like to resume work on bringing the QA
SIG to life.
I proposed a QA SIG session [0] for the next PTG, but I'm not sure the
right audience will be in Dublin.

Could you please reply if you are interested but won't be in Dublin or add
your name to the etherpad if you plan to be there and attend?
If we have enough attendance in Dublin we can kick off there - otherwise I
will setup a meeting with all interested parties (IRC meeting probably, but
other options are possible).

Thank you!

Andrea Frittoli (andreaf)

[0] https://etherpad.openstack.org/p/qa-rocky-ptg


On Mon, Nov 20, 2017 at 9:15 AM Thierry Carrez 
wrote:

> Rochelle Grober wrote:
> > Thierry Carrez wrote:
> >> One question I have is whether we'd need to keep the "QA" project team
> at
> >> all. Personally I think it would create confusion to keep it around,
> for no gain.
> >> SIGs code contributors get voting rights for the TC anyway, and SIGs
> are free
> >> to ask for space at the PTG... so there is really no reason (imho) to
> keep a
> >> "QA" project team in parallel to the SIG ?
> >
> > Well, you can get rid of the "QA Project Team" but you would then need
> to replace it with something like the Tempest Project, or perhaps the Test
> Project.  You still need a PTL and cores to write, review and merge tempest
> fixes and upgrades, along with some of the tests.  The Interop Guideline
> tests are part of Tempest because being there provides oversight on the
> style and quality of the code of those tests.  We still need that.
>
> SIGs can totally produce some code (and have review teams), but I agree
> that in this case this code is basically a part of "the product" (rather
> than a tool produced by guild of practitioners) and therefore makes
> sense to be kept in an upstream project team. Let's keep things the way
> they are, while we work out other changes that may trigger other
> organizational shuffles (like reusing our project infrastructure beyond
> just OpenStack).
>
> I wonder if we should not call the SIG under a different name to reduce
> the confusion between QA-the-project-team and QA-the-SIG. Collaborative
> Testing SIG?
>
> --
> Thierry Carrez (ttx)
>
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
__
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] [gate][devstack][neutron][qa][release] Switch to lib/neutron in gate

[Andrea Frittoli]

On Wed, Jan 17, 2018 at 7:27 PM Ihar Hrachyshka  wrote:

> Hi all,
>

Hi!

>
> tl;dr I propose to switch to lib/neutron devstack library in Queens. I
> ask for buy-in to the plan from release and QA teams, something that
> infra asked me to do.
>
> ===
>
> Last several cycles we were working on getting lib/neutron - the new
> in-tree devstack library to deploy neutron services - ready to deploy
> configurations we may need in our gates.


May I ask the reason for hosting this in the neutron tree?


> Some pieces of the work
> involved can be found in:
>
> https://review.openstack.org/#/q/topic:new-neutron-devstack-in-gate
>
> I am happy to announce that the work finally got to the point where we
> can consistently pass both devstack-gate and neutron gates:
>
> (devstack-gate) https://review.openstack.org/436798


Both legacy and new style (zuulv3) jobs rely on the same test matrix code,
so your change would impact both worlds consistently, which is good.


>
> (neutron) https://review.openstack.org/441579
>
> One major difference between the old lib/neutron-legacy library and
> the new lib/neutron one is that service names for neutron are
> different. For example, q-svc is now neutron-api, q-dhcp is now
> neutron-dhcp, etc. (In case you wonder, this q- prefix links us back
> to times when Neutron was called Quantum.) The way lib/neutron is
> designed is that whenever a single q-* service name is present in
> ENABLED_SERVICES, the old lib/neutron-legacy code is triggered to
> deploy services.
>
> Service name changes are a large part of the work. The way the
> devstack-gate change linked above is designed is that it changes names
> for deployed neutron services starting from Queens (current master),
> so old branches and grenade jobs are not affected by the change.
>

Any other change worth mentioning?


>
> While we validated the change switching to new names against both
> devstack-gate and neutron gates that should cover 90% of our neutron
> configurations, and followed up with several projects that - we
> induced - may be affected by the change - there is always a chance
> that some job in some project gate would fail because of it, and we
> would need to push a (probably rather simple) follow-up to unbreak the
> affected job. Due to the nature of the work, the span of impact, and
> the fact that infra repos are not easily gated against with Depends-On
> links, we may need to live with the risk.
>
> Of course, there are several aspects of the project life involved,
> including QA and release delivery efforts. I was advised to reach out
> to both of those teams to get a buy-in to proceed with the move. If we
> have support for the switch now, as per Clark, infra is ready to
> support the switch.
>
> Note that the effort span several cycles, partially due to low review
> velocity in several affected repos (devstack, devstack-gate),
> partially because new changes in all affected repos were pulling us
> back from the end goal. This is one of the reasons why I would like us
> to do the switch sooner rather than later, since chasing this moving
> goalpost became rather burdensome.
>
> What are QA and release team thoughts on the switch? Are we ready to
> do it in next weeks?
>

If understood properly it would still be possible to use the old names
right?
Some jobs may not rely on test matrix and just hard code the list of
services.
Such jobs would be broken otherwise.

What's the planned way forward towards removing the legacy lib?

Andrea Frittoli (andreaf)


>
> Thanks for attention,
> Ihar
>
> __
> 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] [all][tc] Clarifying testing recommendation for interop programs

[Andrea Frittoli]

 are
ready to go.

With all the plugins no in own branchless repositories, the usability
concern is
not so strong anymore really.


> The value of this option is it allows project teams to retain control over
> these tests.


Other value is given by simplicity, least changes to implement and low risk.


> The potential problem with it is that individual project teams are
> not necessarily reviewing test changes with an eye for interop concerns
> and so
> could inadvertently change the behavior of the trademark-verification
> tools.
>
> 3) All trademark-related tests should go in a single separate tempest
> plugin.
>

I definitely oppose this change. It requires a lot of up-front effort for
no value.
A variation may be to have an interop plugin where new interop tests go,
which
would reduce the initial effort to zero, but I think the result would be a
bit confusing
with interop tests being partly in Tempest, partly in project owned plugins
and
partly in the new plugin.


>
> This has the value of giving the QA and Interop teams control over
> interop-related tests while also making clear the distinction between tests
> used for trademark verification and tests used for CI. Matt's argument
> against
> this is that there actually is very little distinction between those two
> cases,
> and that a given test could have many different applications.
>

+1 on Matt's comment!

Also the CI and ACL for an interop plugin might be rather complicated.
The only way this might work would be if the interop team wrote their own
independent set of tests used only for interop purposes.
But a great advantage of using CI tests for interop purposes is that the
interop
tests are executed all the time and they just work.

Andrea Frittoli (andreaf)


>
> Other ideas that have been thrown around are:
>
> * Maintaining a branch in the tempest repo that Interop tests are pulled
> from.
>
> * Tagging Interop-related tests with decorators to make it clear that they
> need
>   to be handled carefully.
>
> At the heart of the issue is the perception that projects that keep their
> integration tests within the tempest tree are somehow blessed, maybe by
> the QA
> team or by the TC. It would be nice to try to clarify what technical
> and political
> reasons we have for why different projects have tests in different places -
> review bandwidth of the QA team, ownership/control by the project teams,
> technical interdependency between certain projects, or otherwise.
>
> Ultimately, as Jeremy said in the comments on the resolution patch, the
> recommendation should be one that works best for the QA and Interop teams.
> So
> far we've heard from Matt and Mark expressing moderate support for option
> 2.
> We'd like to hear more from those teams about how they see this working,
> especially with regard to concerns about the quality and stability
> standards
> that out-of-tree tests may be held to. We additionally need input from the
> whole community on how maintaining trademark-related tests in tempest will
> affect you if you don't already have your tests there. We'd especially
> like to
> address any perceptions of favoritism or exclusionism that stem from these
> issues.
>
> And to quickly clear up one detail before it makes it onto this thread, the
> Queens Community Goal about splitting tempest plugins out of the main
> project's
> tree[3] is entirely about addressing technical problems related to
> packaging for
> existing tempest plugins, it's not a decree about what should live
> within the tempest
> repository nor does it have anything to do with the Interop program.
>
> As I'm not deeply steeped in the history of either the Interop or QA teams
> I am
> sure I've misrepresented some details here, I'm sorry about that. But we'd
> like
> to get this resolution moving forward and we're currently stuck, so this
> thread
> is intended to gather enough community input to get unstuck and avoid
> letting
> this proposal become stale. Please respond to this thread or comment on the
> resolution proposal[1] if you have any thoughts.
>

> Colleen
>
> [1] https://review.openstack.org/#/c/521602
> [2]
> https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html
> [3]
> https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
>
> __
> 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] [all][tc] Clarifying testing recommendation for interop programs

[Andrea Frittoli]

On Thu, Jan 18, 2018 at 3:33 PM Graham Hayes  wrote:

>
>
> On 11/01/18 16:36, Colleen Murphy wrote:
> > Hi everyone,
> >
> > We have governance review under debate[1] that we need the community's
> help on.
> > The debate is over what recommendation the TC should make to the Interop
> team
> > on where the tests it uses for the OpenStack trademark program should be
> > located, specifically those for the new add-on program being introduced.
> Let me
> > badly summarize:
> >
> > A couple of years ago we issued a resolution[2] officially recommending
> that
> > the Interop team use solely tempest as its source of tests for capability
> > verification. The Interop team has always had the view that the
> developers,
> > being the people closest to the project they're creating, are the best
> people
> > to write tests verifying correct functionality, and so the Interop team
> doesn't
> > maintain its own test suite, instead selecting tests from those written
> in
> > coordination between the QA team and the other project teams. These
> tests are
> > used to validate clouds applying for the OpenStack Powered tag, and
> since all
> > of the projects included in the OpenStack Powered program already had
> tests in
> > tempest, this was a natural fit. When we consider adding new trademark
> programs
> > comprising of other projects, the test source is less obvious. Two
> examples are
> > designate, which has never had tests in the tempest repo, and heat, which
> > recently had its tests removed from the tempest repo.
> >
>
> 
>
> >
> > As I'm not deeply steeped in the history of either the Interop or QA
> teams I am
> > sure I've misrepresented some details here, I'm sorry about that. But
> we'd like
> > to get this resolution moving forward and we're currently stuck, so this
> thread
> > is intended to gather enough community input to get unstuck and avoid
> letting
> > this proposal become stale. Please respond to this thread or comment on
> the
> > resolution proposal[1] if you have any thoughts.
> >
> > Colleen
> >
> > [1] https://review.openstack.org/#/c/521602
> > [2]
> https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html
> > [3]
> https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
> >
>
> I had hoped for more of a discussion on this before I jumped back into
> this debate  - but it seams to be stalled still, so here it goes.
>
> I proposed this initially as we were unclear on where the tests should
> go - we had a resolution that said all tests go into openstack/tempest
> (with a list of reasons why), and the guidance and discussion that been
> had in various summits was that "add-ons" should stay in plugins.
>
> So right now, we (by the governance rules) should be pushing tests to
> tempest for the new programs.
>
> In the resolution that placed the tests in tempest there was a few
> reasons proposed:
>
>   For example, API and behavioral changes must be carefully managed, as
>   must mundane aspects such as test and module naming and location
>   within the test suite. Even changes that leave tests functionally
>   equivalent may cause unexpected consequences for their use in DefCore
>   processes and validation. Placing the tests in a central repository
>   will make it easier to maintain consistency and avoid breaking the
>   trademark enforcement tool.
>
> This still applies, and even more so for teams that traditionally do not
> have a strong QE contributor / reviewer base (aka projects not in
> "core").
>
>   Centralizing the tests also makes it easier for anyone running the
>   validation tool against their cloud or cloud distribution to use the
>   tests. It is easier to install the test suite and its dependencies,
>   and it is easier to read and understand a set of tests following a
>   consistent implementation pattern.
>
> Apparently users do not need central tests anymore, feedback from
> RefStack is that people who run these tests are comfortable dealing
> with extra python packages.
>
> The point about a single set of tests, in a single location and style
> still stands.
>
>   Finally, having the tests in a central location makes it easier to
>   ensure that all members of the community have equal input into what
>   the tests do and how they are implemented and maintained.
>
> Seems like a good value to strive for.
>
> One of the items that has been used to push back against adding
> "add-ons" to tempest has been that tempest has a defined scope, and
> neither of the current add-ons fit in that scope.
>
> Can someone clarify what the set of criteria is? I think it will help
> this discussion.
>
> Another push back is the "scaling" issue - adding more tests will
> overload the QA team.
>
> Right now, DNS adds 10 tests, Orchestration adds 22, to a current suite
> of 353.
>
> I do not think there is many other add-ons proposed yet, and the new
> Vertical programs will probably mainly be re-using tests in the
> openstack/tempest repos as i

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Andrea Frittoli]

On Mon, Jan 15, 2018 at 12:59 PM Erno Kuvaja  wrote:

> On Thu, Jan 11, 2018 at 4:36 PM, Colleen Murphy 
> wrote:
> > Hi everyone,
> >
> > We have governance review under debate[1] that we need the community's
> help on.
> > The debate is over what recommendation the TC should make to the Interop
> team
> > on where the tests it uses for the OpenStack trademark program should be
> > located, specifically those for the new add-on program being introduced.
> Let me
> > badly summarize:
> >
> > A couple of years ago we issued a resolution[2] officially recommending
> that
> > the Interop team use solely tempest as its source of tests for capability
> > verification. The Interop team has always had the view that the
> developers,
> > being the people closest to the project they're creating, are the best
> people
> > to write tests verifying correct functionality, and so the Interop team
> doesn't
> > maintain its own test suite, instead selecting tests from those written
> in
> > coordination between the QA team and the other project teams. These
> tests are
> > used to validate clouds applying for the OpenStack Powered tag, and
> since all
> > of the projects included in the OpenStack Powered program already had
> tests in
> > tempest, this was a natural fit. When we consider adding new trademark
> programs
> > comprising of other projects, the test source is less obvious. Two
> examples are
> > designate, which has never had tests in the tempest repo, and heat, which
> > recently had its tests removed from the tempest repo.
> >
> > So far the patch proposes three options:
> >
> > 1) All trademark-related tests should go in the tempest repo, in
> accordance
> >with the original resolution. This would mean that even projects that
> have
> >never had tests in tempest would now have to add at least some of
> their
> >black-box tests to tempest.
> >
> > The value of this option is that centralizes tests used for the Interop
> program
> > in a location where interop-minded folks from the QA team can control
> them. The
> > downside is that projects that so far have avoided having a dependency on
> > tempest will now lose some control over the black-box tests that they
> use for
> > functional and integration that would now also be used for trademark
> > certification.
> > There's also concern for the review bandwidth of the QA team - we can't
> expect
> > the QA team to be continually responsible for an ever-growing list of
> projects
> > and their trademark tests.
> >
> > 2) All trademark-related tests for *add-on projects* should be sourced
> from
> >plugins external to tempest.
> >
> > The value of this option is it allows project teams to retain control
> over
> > these tests. The potential problem with it is that individual project
> teams are
> > not necessarily reviewing test changes with an eye for interop concerns
> and so
> > could inadvertently change the behavior of the trademark-verification
> tools.
> >
> > 3) All trademark-related tests should go in a single separate tempest
> plugin.
> >
> > This has the value of giving the QA and Interop teams control over
> > interop-related tests while also making clear the distinction between
> tests
> > used for trademark verification and tests used for CI. Matt's argument
> against
> > this is that there actually is very little distinction between those two
> cases,
> > and that a given test could have many different applications.
> >
> > Other ideas that have been thrown around are:
> >
> > * Maintaining a branch in the tempest repo that Interop tests are pulled
> from.
> >
> > * Tagging Interop-related tests with decorators to make it clear that
> they need
> >   to be handled carefully.
> >
> > At the heart of the issue is the perception that projects that keep their
> > integration tests within the tempest tree are somehow blessed, maybe by
> the QA
> > team or by the TC. It would be nice to try to clarify what technical
> > and political
> > reasons we have for why different projects have tests in different
> places -
> > review bandwidth of the QA team, ownership/control by the project teams,
> > technical interdependency between certain projects, or otherwise.
> >
> As someone who has been in middle of all that already once I'd like to
> bring up bit more fundamental problem into this topic. I'm not able to
> provide one size fits all solution but hopefully some insight that
> would help the community to make the right decision.
>
> I think the biggest problem is who's fox is let to guard the chicken coop.
>
> By that I mean the basic problem of our testing still relies on what
> is tested based on which assumptions and by whom. If the tests are
> provided by the project teams, the test is more likely to cover the
> intended usecase of the feature as it's implemented and if there is
> bug found on that, the likelyhood that the test is altered is quite
> high also the individual projects might not have the best idea what
> might be the i

Re: [openstack-dev] [all][tc] Clarifying testing recommendation for interop programs

[Andrea Frittoli]

On Fri, Jan 12, 2018 at 9:50 AM Luigi Toscano  wrote:

> On Thursday, 11 January 2018 23:52:00 CET Matt Riedemann wrote:
> > On 1/11/2018 10:36 AM, Colleen Murphy wrote:
> > > 1) All trademark-related tests should go in the tempest repo, in
> > > accordance
> > >
> > > with the original resolution. This would mean that even projects
> that
> > > have
> > > never had tests in tempest would now have to add at least some of
> > > their
> > > black-box tests to tempest.
> > >
> > > The value of this option is that centralizes tests used for the Interop
> > > program in a location where interop-minded folks from the QA team can
> > > control them. The downside is that projects that so far have avoided
> > > having a dependency on tempest will now lose some control over the
> > > black-box tests that they use for functional and integration that would
> > > now also be used for trademark certification.
> > > There's also concern for the review bandwidth of the QA team - we can't
> > > expect the QA team to be continually responsible for an ever-growing
> list
> > > of projects and their trademark tests.
> >
> > How many tests are we talking about for designate and heat? Half a
> > dozen? A dozen? More?
> >
> > If it's just a couple of tests per project it doesn't seem terrible to
> > have them live in Tempest so you get the "interop eye" on reviews, as
> > noted in your email. If it's a considerable amount, then option 2 seems
> > the best for the majority of parties.
>
> I would argue that it does not scale; what if some test is taken out from
> the
> interoperability, and others are added? It would mean moving tests from one
> repository to another, with change of paths. I think that the solution 2,
> where the repository where a test belong and the functionality of a test
> are
> not linked, is better.
>

This probably does not happen too often, but it does happen, and I agree
that it
would make things easier to have interop and non-iterop tests in the same
repo.


>
> Ciao
> --
> Luigi
>
>
>
> __
> 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] [QA] [all] QA Rocky PTG Planning

[Andrea Frittoli]

and the link [1]

[1] https://etherpad.openstack.org/p/qa-rocky-ptg

On Thu, Jan 18, 2018 at 10:28 AM Andrea Frittoli 
wrote:

> Dear all,
>
> I started the etherpad for planning the QA work in Dublin.
> Please add your ideas / proposals for sessions and intention of attending.
> We have a room for the QA team for three full days Wed-Fri.
>
> This time I also included a "Request for Sessions" - if anyone would like
> to discuss a QA related topic with the QA team or do a hands-on / sprint on
> something feel free to add it in there. We can also handle them in a less
> unstructured format during the PTG - but if there are a few requests on
> similar topics we can setup a session on Mon/Tue for everyone interested to
> attend.
>
> Andrea Frittoli (andreaf)
>
__
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] [QA] [all] QA Rocky PTG Planning

[Andrea Frittoli]

Dear all,

I started the etherpad for planning the QA work in Dublin.
Please add your ideas / proposals for sessions and intention of attending.
We have a room for the QA team for three full days Wed-Fri.

This time I also included a "Request for Sessions" - if anyone would like
to discuss a QA related topic with the QA team or do a hands-on / sprint on
something feel free to add it in there. We can also handle them in a less
unstructured format during the PTG - but if there are a few requests on
similar topics we can setup a session on Mon/Tue for everyone interested to
attend.

Andrea Frittoli (andreaf)
__
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] zuulv3 log structure and format grumblings

[Andrea Frittoli]

On Wed, Jan 10, 2018 at 8:35 PM melanie witt  wrote:

> On Fri, 05 Jan 2018 10:43:59 -0800, Clark Boylan wrote:
> > To expand a bit more on that what we are attempting to do is port the
> log handling code in devstack-gate [0] to zuul v3 jobs living in tempest
> [1]. The new job in tempest itself relies on the  ansible
> process-test-results role which can be found here [2]. Chances are
> something in [1] and/or [2] will have to be updated to match the behavior
> in [0].
> >
> > [0]
> https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n524
> > [1]
> https://git.openstack.org/cgit/openstack/tempest/tree/playbooks/post-tempest.yaml#n8
> > [2]
> http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/process-test-results
>
> Thanks for the pointer. So far, I can't tell what's going wrong but I
> noticed that none of the items in post-tempest.yaml are making it to
> controller/logs/. The tempest.conf is missing under controller/logs/etc,
> the tempest.log is missing, accounts.yaml is missing, along with
> testr_results.html. The job-output shows that the post-tempest.yaml is
> being executed [1] but the results aren't making it to logs/.
>

Thanks for looking into this. The issue with the missing tempest log and
config
is related to a change in stage-dir on devstack side. The ansible user dir
is the
correct stage dir to be used, but tempest was still setting /opt/stack in
its post.
The fix for that is here [1].

In fact we should be able to stop invoking stage-output in tempest post and
only
extend the zuul_copy_output variable in the devstack-tempest job definition,
I'll look into that in the near future.

Andrea Frittoli (andreaf)

[1] https://review.openstack.org/532649



>
> [1]
>
> http://logs.openstack.org/95/523395/14/gate/tempest-full/ea04d53/job-output.txt.gz#_2018-01-10_19_15_27_228060
>
> __
> 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] zuulv3 log structure and format grumblings

[Andrea Frittoli]

On Fri, 5 Jan 2018, 7:14 pm melanie witt,  wrote:

> On Thu, 4 Jan 2018 08:46:38 -0600, Matt Riedemann wrote:
> > The main issue is for newer jobs like tempest-full, the logs are under
> > controller/logs/ and we lose the log analyze formatting for color, being
> > able to filter on log level, and being able to link directly to a line
> > in the logs.
>
> I also noticed we're missing testr_results.html.gz under
> controller/logs/, which was handy for seeing a summary of the tempest
> test results.
>

Uhm I'm pretty sure that used to be there, so something must have changed
since.
I cannot troubleshoot this on my mobile, but if you want to have a look,
the process test results role in zuul-jobs is what is supposed to produce
that.

Andrea

>
> I hope there's a way to get that back and if any infra peeps can point
> me in the right direction, I'm happy to help with it.
>
> -melanie
>
> __
> 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] zuulv3 log structure and format grumblings

[Andrea Frittoli]

On Thu, 4 Jan 2018, 11:15 pm Matt Riedemann,  wrote:

> On 1/4/2018 12:20 PM, Clark Boylan wrote:
> > I've pushed uphttps://review.openstack.org/531208  as a quick check
> that this is indeed the general problem, but for longer term fix I think we
> want to update our log publishing ansible roles to compress everything that
> isn't already compressed.
>
> Yup this fixes the log formatting/color/linking stuff, thanks!
>
> I noted that the config files still have to be downloaded, and dmsimard
> pointed out that conf/ini/filters files will have to be mapped here:
>
>
> http://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/templates/logs.vhost.erb#n24



The ansible role that stages files supports renaming files with specified
extensions to .txt, but it looks like something is not going right.

I'm on PTO until the 9th, if it's an issue still I'll look into it as soon
as I'm back.

Andrea (andreaf)

>
>
> I don't know if we can just convert everything under etc/ or not? That
> seems better to me, but I don't know anything about modifying vhost files.
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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] [QA] No QA meetings until next year

[Andrea Frittoli]

Dear all,

The first QA meeting of the year will be next week.

Andrea Frittoli

On Wed, 20 Dec 2017, 3:56 pm Andrea Frittoli, 
wrote:

> Dear all,
>
> due to the holiday season, there will be no QA meetings until 2018.
>
> Andrea Frittoli (andreaf)
>
__
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] [QA] No QA meetings until next year

[Andrea Frittoli]

Dear all,

due to the holiday season, there will be no QA meetings until 2018.

Andrea Frittoli (andreaf)
__
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] [qa] [patrole] Question regarding Patrole API coverage

[Andrea Frittoli]

On Wed, Nov 29, 2017 at 2:28 PM Peng Liu  wrote:

> Hi Team,
>
> Hi Peng


> I have a question regarding to the API coverage of Patrole. Currently,
> Patrole as a Tempest plugin heavily relys on the Tempest code. However,
> Tempest only contains the API tests for the most common APIs of the most
> common projects(Nova, Neutron, Cinder, Glance, Swift, Keystone).
>
> So I want to know if it is possible to extend Patrole to:
> 1) test the APIs of the common projects which was not yet covered in
> Tempest.
>
2) test projects which was not covered in Tempest?
>

You can use the Patrole framework to test services not covered by Tempest
by taking advantage of Tempest plugin mechanism.
Patrole itself is a Tempest plugin. If you install the plugin of a service
that includes a service client, you should be able to use it to write
Patrole tests for that service.
I believe this has not been done yet by any project though, so there may be
a few technical bits to be sorted out.

I don't think Patrole itself will have to be extended, however Patrole does
not yet include stable APIs.
If you're going to use Patrole APIs in your project you need to be aware
that there may be backward incompatible changes happening without a
deprecation period.

There are several options on where to host such tests: in a dedicated
plugin, in the Tempest plugin for the service or in Patrole itself.
The latter would probably suffer from the same scalability issues that lead
us to create the plugin mechanism to begin with.

Andrea Frittoli (andreaf)


>
> Thanks,
> --
> Peng Liu
> __
> 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

[openstack-dev] [QA] No office hours and meeting tomorrow 23/11

[Andrea Frittoli]

Dear all,

sorry about the short notice on this - tomorrow I will be travelling so I
won't be able to host the office hours in the morning and the meeting in
the evening.

Kind regards

Andrea Frittoli (andreaf)
__
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] [QA] Is forcing dynamic creds too restrictive?

[Andrea Frittoli]

On Tue, Nov 21, 2017 at 4:47 PM MCCASLAND, TREVOR  wrote:

> Hello QA Team,
>
> In many of the tempest tests there is a statement[1] that overrides the
> tempest.conf value for use_dynamic_credentials.
> In the event of an immutable user source, these test cases[2] and the
> one's inherited by them will fail.
> Can we remove or reduce the scope of the overrides? You can see my
> proposed solution for identity admin cases here[3] and my bug report here[4]
>
> What is the QA team's opinion on this?
> Is forcing dynamic creds too restrictive since it would prevent any tests
> being executed against clouds where credential creation is not allowed?
>

The reason we force dynamic credentials for identity admin tests is that
pre-provisioned credentials are generally not a good fit for admin test
cases.
Admin tests are not a concern from an interoperability point of view, so
forcing dynamic credentials on admin tests is not an issue for
interoperability testing either.

That said there are probably cases where we could allow for pre-provisioned
credentials without risking to break test isolation.
I'm fine with that in principle, I guess it has to be discussed on a test
by test basis.

Andrea Frittoli (andreaf)



> [1]
> https://github.com/openstack/tempest/blob/eed21d7a1c0b3e5620960de9878ac9df0d2907fa/tempest/api/identity/base.py#L120-L127
> [2]
> http://codesearch.openstack.org/?q=force_tenant_isolation%20%3D%20True&i=nope&files=&repos=tempest
> [3] https://review.openstack.org/#/c/499756/
> [4] https://bugs.launchpad.net/tempest/+bug/1714277
>
> __
> 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-sigs] [Openstack-operators] [QA] Proposal for a QA SIG

[Andrea Frittoli]

On Fri, Nov 17, 2017 at 12:33 PM Thierry Carrez 
wrote:

> Andrea Frittoli wrote:
> > [...]
> > during the last summit in Sydney we discussed the possibility of
> creating an
> > OpenStack quality assurance special interest group (OpenStack QA SIG).
> > The proposal was discussed during the QA feedback session [0] and it
> > received
> > positive feedback there; I would like to bring now the proposal to a
> larger
> > audience via the SIG, dev and operators mailing lists.
> > [...]
>
> I think this goes with the current trends of re-centering upstream
> "project teams" on the production of software, while using SIGs as
> communities of practice (beyond the governance boundaries), even if they
> happen to produce (some) software as the result of their work.
>
> One question I have is whether we'd need to keep the "QA" project team
> at all. Personally I think it would create confusion to keep it around,
> for no gain. SIGs code contributors get voting rights for the TC anyway,
> and SIGs are free to ask for space at the PTG... so there is really no
> reason (imho) to keep a "QA" project team in parallel to the SIG ?
>

That is a possibility indeed, but I think co-existance will be the case for
a
bit at least - we may decide to drop the QA program eventually depending
on how the experience with the SIG goes.


>
> In the same vein we are looking into turning the Security project team
> into a SIG, and could consider turning other non-purely-upstream teams
> (like I18n) in the future.
>
> --
> Thierry Carrez (ttx)
>
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
__
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] [QA] Proposal for a QA SIG

[Andrea Frittoli]

Dear all,

during the last summit in Sydney we discussed the possibility of creating an
OpenStack quality assurance special interest group (OpenStack QA SIG).
The proposal was discussed during the QA feedback session [0] and it
received
positive feedback there; I would like to bring now the proposal to a larger
audience via the SIG, dev and operators mailing lists.

The mission of the existing QA Program in OpenStack is to “develop,
maintain,
and initiate tools and plans to ensure the upstream stability and quality of
OpenStack, and its release readiness at any point during the release cycle”
[1].
While the mission statement is quite wide, the only QA that we have
visibility on
is what happens upstream, which is limited with pre-merge testing, with the
only
exception of periodic tests.

There’s a lot of engineering that goes into OpenStack QA downstream, and
there
have been several attempts in the past to share this work and let everyone
in the
community benefit from it. The QA SIG could be a forum to make this happen:
share use cases, tests, tools, best practises and ideas beyond what we test
today
in upstream; enable everyone doing QA in the OpenStack community to benefit
from the QA work that happens today.

Adjacent communities may be interested in participating to a QA SIG as well.
The opnfv community [2] performs QA on OpenStack releases today and they
are actively looking for opportunities to share tools and test cases.

Please reply to this email thread to express interest in participating /
chairing a
QA SIG, if I get enough positive feedback I’ll setup the SIG as forming
[4], and we
can then continue the conversation on the SIG mailing list and eventually
setup
an initial meeting.

Thank you,

Andrea Frittoli (andreaf)


[0] https://etherpad.openstack.org/p/SYD-forum-qa-tools-plugins
[1] https://wiki.openstack.org/wiki/QA
[2] https://www.opnfv.org
[3] https://wiki.openstack.org/wiki/Performance_Team
[4] https://wiki.openstack.org/wiki/OpenStack_SIGs
__
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] [QA] No team meeting tomorrow

[Andrea Frittoli]

Hello team,

since a few of us will either still be in Sydney or travelling back, I'm
cancelling the meeting tomorrow Nov 9 at 17UTC.

Cheers,

Andrea Frittoli (andreaf)
__
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] [QA] Sydney Summit

[Andrea Frittoli]

Dear all,

A few of us from the QA team will be in Sydney at the OpenStack summit.
We will host and on boarding session on Monday afternoon [0] as well as a
few feedback sessions on QA tools through the week [1][2][3].
A project QA update session will take place on Tuesday [4].

If your interested in OpenStack QA, please join us at one of the sessions,
we welcome all type of contributions - feedback, ideas, code, documentation.

We look forward to meeting you in Sydney!

Andrea Frittoli (andreaf)

[0]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20437/qa-project-onboarding

[1]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20443/missing-features-and-making-improvements-to-openstack-health

[2]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20459/the-state-of-test-runners-and-moving-to-stestr

[3]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20505/users-operators-adoption-of-qa-tools-plugins

[4]
https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20385/qa-project-update
__
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] [QA] Office Hours report 2017-10-26

[Andrea Frittoli]

Dear all,

today we had our QA office hours.
We will have the next office hours in two weeks from now.

The IRC report [0] and full log [1] are available through meetbot.

Below a details of the bugs we triaged today.

Kind regards,

Andrea Frittoli (andreaf)


Bug #1715859 in tempest: "After upgrade to stestr cannot access
.testrepository"
https://bugs.launchpad.net/tempest/+bug/1715859
Discussed, invalid/incomplete

Bug #1724543 in devstack: "devstack fails while installing with monasca-api
in queens "
https://bugs.launchpad.net/devstack/+bug/1724543
Triaged, not a devstack bug

Bug #1724746 in devstack: "devstack fail at monasca-api plugin installation
in pike"
https://bugs.launchpad.net/devstack/+bug/1724746
Triaged, not a devstack bug

Bug #1724747 in devstack: "cleaning of devstack using ./clean.sh is not
preoperly done for monasca schema"
https://bugs.launchpad.net/devstack/+bug/1724747
Triaged, not a devstack bug


[0]
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-10-26-09.00.html

[1]
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-10-26-09.00.log.html
__
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] [QA} No QA team meeting on 26/10

[Andrea Frittoli]

Deal all,

I'm cancelling the QA meeting next Thursday as I will be travelling.
For any urgent thing, please find us in the #openstack-qa room.

Andrea Frittoli (andreaf)
__
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] [qa] Proposing changes to 17UTC team meeting

[Andrea Frittoli]

On Mon, Oct 23, 2017 at 2:22 AM Ghanshyam Mann 
wrote:

> 1 typo correction, All current meeting and office hours are on
> Thursday (not Tuesday).
>
> Week1:
> - *Thu* 9:00 UTC Office hours in #openstack-qa
> - *Thu* 17:00 UTC Meeting in #openstack-meeting
> Week2:
> - *Thu* 8:00 UTC Meeting in #openstack-meeting
>

Thanks! :)


>
> -gmann
>
>
> On Sat, Oct 21, 2017 at 5:43 AM, Andrea Frittoli
>  wrote:
> > Dear all,
> >
> > The current schedule for QA meetings and office hours is as follows
> > (alternating weeks):
> >
> > Week1:
> > - Tue 9:00 UTC Office hours in #openstack-qa
> > - Tue 17:00 UTC Meeting in #openstack-meeting
> > Week2:
> > - Tue 8:00 UTC Meeting in #openstack-meeting
> >
> > Since the 17:00 UTC as a rather low attendance, but not zero, I would
> > propose to drop that meeting in favour of a second office hours slot, so
> > that we have one slot every week and the meeting would be every
> > second week:
> >
> > Week1:
> > - Tue 9:00 UTC Office hours in #openstack-qa
> > Week2:
> > - Tue 8:00 UTC Meeting in #openstack-meeting
> > - [TBD] Office hours in #openstack-qa
> >
> > Proposals for the office hours schedule in the doodle [0]
> >
> > Let me know your thoughts on this proposal and please vote for the
> > time slot in the doodle.
> >
> > Thank you!
> >
> > Andrea Frittoli (andreaf)
> >
> > [0] https://doodle.com/poll/kf6b8847wa2s5mxv
> >
> >
> >
> __
> > 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
>
__
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] [qa] Proposing changes to 17UTC team meeting

[Andrea Frittoli]

Dear all,

The current schedule for QA meetings and office hours is as follows
(alternating weeks):

Week1:
- Tue 9:00 UTC Office hours in #openstack-qa
- Tue 17:00 UTC Meeting in #openstack-meeting
Week2:
- Tue 8:00 UTC Meeting in #openstack-meeting

Since the 17:00 UTC as a rather low attendance, but not zero, I would
propose to drop that meeting in favour of a second office hours slot, so
that we have one slot every week and the meeting would be every
second week:

Week1:
- Tue 9:00 UTC Office hours in #openstack-qa
Week2:
- Tue 8:00 UTC Meeting in #openstack-meeting
- [TBD] Office hours in #openstack-qa

Proposals for the office hours schedule in the doodle [0]

Let me know your thoughts on this proposal and please vote for the
time slot in the doodle.

Thank you!

Andrea Frittoli (andreaf)

[0] https://doodle.com/poll/kf6b8847wa2s5mxv
__
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] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

[Andrea Frittoli]

On Fri, Oct 13, 2017 at 1:46 PM Flavio Percoco  wrote:

> Greetings,
>
> Some of you, TC candidates, expressed concerns about diversity and
> inclusiveness
> (or inclusivity, depending on your taste) in your candidacy. I believe
> this is a
> broad, and some times ill-used, topic so, I'd like to know, from y'all,
> how you
> think we could make our community more inclusive. What areas would you
> improve
> first?
>

Hi Flavio,

I'd continue promoting asynchronous communication, office hours and a good
use
of meetbot to generate good summaries (it's true that all IRC communication
is logged,
but it can be a lot of text to go through sometimes).

I'd propose we write training material on inclusiveness to be included in
the great work
of the upstream institute. We can use this to build and maintain awareness
in the
community.

It's important we don't think that training and educations are only for
new-comers into
the community. Especially after a few years in the community one may be
tempted
to fall into routines and/or preconceptions - it's important to keep an
open mind towards
people and ideas.

One idea that has been bouncing in mind is trainings for newly elected PTLs
or TCs or
any other interested individuals. I'm thinking especially of leaders since
their words
often bear a stronger impact on the community.

Perhaps self paced trainings where we present community guiding principles,
code of
conduct and vision or dedicated sessions at the PTG.

Faithfully,

Andrea Frittoli (andreaf)


> Thank you,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
> __
> 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] [all][tc] TC Candidates: what does an OpenStack user look like?

[Andrea Frittoli]

On Thu, Oct 12, 2017 at 5:51 PM Zane Bitter  wrote:

> (Reminder: we are in the TC election campaigning period, and we all have
> the opportunity to question the candidates. The campaigning period ends
> on Saturday, so make with the questions.)
>
>
> In my head, I have a mental picture of who I'm building OpenStack for.
> When I'm making design decisions I try to think about how it will affect
> these hypothetical near-future users. By 'users' here I mean end-users,
> the actual consumers of OpenStack APIs. What will it enable them to do?
> What will they have to work around? I think we probably all do this, at
> least subconsciously. (Free tip: try doing it consciously.)
>
> So my question to the TC candidates (and incumbent TC members, or anyone
> else, if they want to answer) is: what does the hypothetical OpenStack
> user that is top-of-mind in your head look like? Who are _you_ building
> OpenStack for?
>


Unlike a few years ago we don't walk so much in the dark anymore.
We now know a lot of our users because:
- some are contributors to OpenStack. OpenStack developers but not only.
With
  contributors to OpenStack I don't mean only code, but any kind of
contribution,
  like presenting and discussing use cases at the PTG, at the forum or on
the
  mailing list, providing feedback, ideas, resources and even motivation.
- some are adjacent communities that depend on or collaborate with
OpenStack.
- some answer our user survey.

So who am _I_ building OpenStack for?

- For OpenStack developers, since I work mostly on QA and CI
- For the users that are closer to the OpenStack community. I don't want to
focus
  on hypothetical users that don't care to talk to the OpenStack community.
  Consistency across projects in they way they different projects are
built, tested,
  deployed, operated, documented and consumed is important for this type of
users.
- I build it to be a good software for everyone to use. I care about
usability, good
  documentation, stable APIs, proper logging features that
  make it a good software for anyone to invest their time on.

Faithfully,

Andrea Frittoli (andreaf)


> There's a description of mine in this email, as an example:
> http://lists.openstack.org/pipermail/openstack-dev/2017-October/123312.html
>
> To be clear, for me at least there's only one wrong answer ("person who
> needs somewhere to run their IRC bouncer"). What's important in my
> opinion is that we have a bunch of people with *different* answers on
> the TC, because I think that will lead to better discussion and
> hopefully better decisions.
>
> Discuss.
>
> cheers,
> Zane.
>
> __
> 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] [tc][election] Question for the candidates

[Andrea Frittoli]

On Thu, Oct 12, 2017 at 7:38 PM Ed Leafe  wrote:

> In the past year or so, has there been anything that made you think “I
> wish the TC would do something about that!” ? If so, what was it, and what
> would you have wanted the TC to do about it?
>

I really appreciate the work that the TC has done with the vision and the
community goals.
The TC is applying the ideas of servant leadership, which are a very good
fit with OpenStack guiding principles [0].

I wish the TC would be more proactive in propagating the ideas of servant
leadership and vision into the project teams - and help the PTLs be servant
leaders for their project teams.

Faithfully,

Andrea Frittoli (andreaf)

[0]
https://governance.openstack.org/tc/reference/principles.html#guiding-principles



> -- Ed Leafe
>
>
>
>
>
>
> __
> 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] [tc][election] Question for the candidates

[Andrea Frittoli]

On Thu, Oct 12, 2017 at 8:43 PM Clay Gerrard  wrote:

> I like a representative democracy.  It mostly means I get a say in which
> other people I have to trust to think deeply about issues which effect me
> and make decisions which I agree (more or less) are of benefit to the
> social groups in which I participate.  When I vote IRL I like to consider
> voting records.  Actions speak louder blah blah.
>
> To candidates:
>
> Would you please self select a change (or changes) from
> https://github.com/openstack/governance/ in the past ~12 mo or so where
> they thought the outcome or the discussion/process was particular good and
> explain why you think so?
>

The TC proposes and votes governance patches; however its real power, or
better, responsibility, is to inspire, to provide guidance by building
trust first, to work in the community for the community.
I think the TC vision work [0] was a great example of all three. The draft
has been proposed by the TC. Is has been discussed with the community and
everyone had a chance to contribute to it.

I very much appreciated the work on the guiding principles [1] and on the
meetings [2] as well.
The vision was special in the way the community was even more involved than
in the others.

Faithfully,

Andrea Frittoli (andreaf)

[0]
https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html
[1]
https://governance.openstack.org/tc/reference/principles.html#guiding-principles

[2]
https://governance.openstack.org/tc/resolutions/20170718-allow-scheduling-meetings-on-team-channels.html


>
> It'd be super helpful to me, thanks!
>
> -Clay
> __
> 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

[openstack-dev] [QA] Office Hours report 2017-10-12

[Andrea Frittoli]

Dear all,

today we had our first QA office hours.
Thanks to everyone who attended and to chandankumar for leading the bug
triage.

I think it was an hour well spent, we had good discussions about several
recent bugs.
We will have the next office hours in two weeks from now.

The IRC report [0] and full log [1] are available through meetbot.

Below a details of the bugs we triaged today.

Kind regards

Andrea Frittoli (andreaf)

Bug #1721553 in tempest: "Functional tests fail: Expecting to find domain
in project / auth_url was not provided to the Neutron client"
https://bugs.launchpad.net/tempest/+bug/1721553
discussed, triaged

Bug #1715663 in tempest: "Silent termination on wrong entry point from
plugin"
https://bugs.launchpad.net/tempest/+bug/1715663
discussed, triaged, tagged as low hanging fruit

Bug #1672620 in tempest: "Need pre/post test hooks for tempest"
https://bugs.launchpad.net/tempest/+bug/1672620
discussed, triaged, need clarification

Bug #1722201 in tempest: "Deprecation Warning for 'Mitaka' and
 'openstack-tempest-16.0.0-1.el7ost.noarch'"
https://bugs.launchpad.net/tempest/+bug/1722201
discussed, invalid

Bug #1722995 in devstack: "DevStack in DevStack"
https://bugs.launchpad.net/devstack/+bug/1722995
triaged and commented

[0]
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-10-12-09.01.html

[1]
http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-10-12-09.01.log.html
__
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] [forum] Draft Schedule - Deadline Oct 13 Friday 20:00 UTC

[Andrea Frittoli]

On Thu, Oct 12, 2017 at 9:36 AM Thierry Carrez 
wrote:

> Mike Perez wrote:
> > [...]
> > You have until Friday, October 13th 20:00UTC to let us know of any
> > corrections/conflicts.
>
> Nice work, all!
>
> A few potential conflicts I detected that we might want to address:
>
> 11/8 11:00-11:40
> I know a number of people who will want to attend both the "Ironic vs.
> Mogan vs. Nova" discussion and the "First contact SIG" discussion. I
> suggest swapping "First Contact SIG" with the "Heat ops and users
> feedback" session later on the same day.
>
> 11/7 11:40-12:20
> In the same vein, I know of a few people interested in both the
> "Documentation and relnotes" session and the "Making OpenStack more
> palatable to part-time contributors" session. I suggest swapping the
> "part-time contributors" discussion with the "Users / Operators adoption
> of QA tools / plugins" session earlier on the same day (bonus point for
> eliminating the QA/Zuul session conflict there).
>

+1 it works for me.
The QA project update is 10:50am - 11:10am, so no conflict.

thanks,

Andrea Frittoli (andreaf)


>
> Cheers,
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [qa][all] QA Office Hours

[Andrea Frittoli]

Dear all,

a kind reminder that tomorrow at 9:00 UTC we'll start office hours for the
QA team in the #openstack-qa channel.
Please join us with any question / comment you may have.

We'll triage bugs for QA projects from the past 7 days and then extend the
time frame if there is time left.

Kind regards

Andrea Frittoli (andreaf)

On Fri, Oct 6, 2017 at 12:09 PM Andrea Frittoli 
wrote:

> Dear all,
>
> Staring next week the QA team will start running office hours be-weekly
> (every send week) on Thursdays at 9:00 UTC.
> Office hours will happen in the #openstack-qa channel, and we'll use
> meetbot there to record info, action and generate dedicated logs.
>
> Several core developers from the QA program will be available, so please
> join us in the #openstack-qa channel to ask any question related QA
> projects.
>
> Faithfully,
>
> Andrea Frittoli (andreaf)
>
__
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] [qa][infra][devstack] Changes to devstack-core for zuul v3 migration

[Andrea Frittoli]

Dear all,

with zuul v3, the common roles and playbooks that will be used for all
devstack jobs will be hosted in openstack-dev/devstack.
To speed up the implementation and stabilisation of the code I propose the
following changes:

- we will treat +1 from infra-core members on devstack changes in the
ansible bits as +2
- add clarkb to devstack-core, since he's quite aware of the the devstack
codebase

Please let me know if you have any objection, else the change we'll become
effective tomorrow.

Kind regards

Andrea Frittoli (andreaf)
__
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] [TC][election] TC Candidacy

[Andrea Frittoli]

Dear all,

I’d like to announce my candidacy for a seat on the OpenStack Technical
Committee.

I started my journey on OpenStack in 2011 as a user and operator. I had
little experience contributing to open source at the time; the people and
the values in the OpenStack community soon convinced me I could not simply
sit on the "consumer" side of the fence, and I started contributing to
the QA program. I've been a core contributor for Tempest since 2014 and the
PTL for the QA Program since the Pike cycle.

I attended the 2nd Leadership Training in Ann Arbour; the ideas of servant
leadership and vision inspired me and I put them into use while serving as
a PTL and working with the community in general.

I'm a supporter of the OpenStack vision prepared by the TC and by this
community. Diversity and collaboration with other communities enrich us,
"constellations" give a clearer message to users and operators, and help
us focus our development and testing efforts in a consistent direction.

On the TC I would focus on a few ares:

- Inclusivity of the OpenStack community: reduce language and time
barriers for contribution. Everyone should feel welcome and have the
opportunity to be successful when working on OpenStack.

- Build our new leaders: it's not enough to welcome new contributors,
we need to help them grow into the community future leaders.

- Cross-project and cross-community testing: help companies bring their
downstream architecture, integration and testing efforts in upstream
so they can benefit from the contributions of others in the community
that want to solve similar problems via OpenStack.

Regardless of the results of this election I will work hard to see the
vision we set for ourselves realised.

Thank you for your consideration.

Andrea Frittoli (andreaf)

https://www.openstack.org/community/members/profile/1211/andrea-frittoli
https://review.openstack.org/#/c/510961/
__
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] [QA] QA Bug Czar

[Andrea Frittoli]

Dear all,

as discussed during the PTG, starting in the Queens cycle we will have a
bug czar.

chandakumar has graciously put his name forward for the role, and he'll be
QA bug czar for the Queens cycle.
Thank you!

The bug czar ensures that all bugs to OpenStack projects under the QA
umbrella are triaged and acted upon in a timely fashion based on
criticality.
The bug czar responsibilities include:

- ensure that new bugs are triaged
- prune old / stale bugs that are not relevant anymore
- maintain a list of low hanging fruit bugs for new contributors to pick
and fix
- ensure that PTLs / core reviewers are aware of high-priority bugs / raise
attention to critical issues
- run a regular session in IRC for discussion on bugs, mentoring of bug
triage contributor
- drive implementation / adoption of automation that may help with any of
the above

Kind regards,

Andrea Frittoli (andreaf)
__
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] [qa][all] QA Office Hours

[Andrea Frittoli]

Dear all,

Staring next week the QA team will start running office hours be-weekly
(every send week) on Thursdays at 9:00 UTC.
Office hours will happen in the #openstack-qa channel, and we'll use
meetbot there to record info, action and generate dedicated logs.

Several core developers from the QA program will be available, so please
join us in the #openstack-qa channel to ask any question related QA
projects.

Faithfully,

Andrea Frittoli (andreaf)
__
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] [all] Important information for people with in-repo Zuul v3 config

[Andrea Frittoli]

On Wed, Oct 4, 2017 at 1:00 PM Jon Schlueter  wrote:

> On Wed, Oct 4, 2017 at 7:35 AM, Sean Dague  wrote:
> > On 10/04/2017 07:23 AM, Boden Russell wrote:
> >>
> >> On 10/3/17 1:37 PM, Monty Taylor wrote:
> >>> The partial rollback of Zuulv3 is in place now. Zuulv2 is acting as
> your
> >>> gate keeper once again.
> >>
> >> Since the rollback, one of the neutron-lib (v2) jobs has been
> >> consistently failing [1] with:
> >>
> >> c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
> >>
> >> Is this a known issue?
> >
> > Yes, this is unrelated.
> >
> > cffi 1.11.1 was released today on pypi, without wheels. It's installed
> > super early in the job run because ansible is used to drive things.
> >
> > There is a stop gap work around that's running tests right now -
> > https://review.openstack.org/#/c/509394/1/devstack-vm-gate-wrap.sh
> >
> > If it passes I'll approve it to get folks back to work. A longer term
> > solution is probably needed.
>
> might want to consider adding --only-binary 
> to the pip install line
>
Sounds like a good safety net for the future, thanks.


>
> But it looks like cffi 1.11.1 now has wheels
>

Indeed, thank you

>
>
> Jon
>
>
> > -Sean
> >
> > --
> > Sean Dague
> > http://dague.net
> >
> >
> __
> > 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
>
>
>
> --
> Jon Schlueter
> jschl...@redhat.com
> IRC: jschlueter/yazug
> Senior Software Engineer - OpenStack Productization Engineer
>
> __
> 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] [all] Important information for people with in-repo Zuul v3 config

[Andrea Frittoli]

On Wed, Oct 4, 2017 at 12:23 PM Boden Russell  wrote:

>
> On 10/3/17 1:37 PM, Monty Taylor wrote:
> > The partial rollback of Zuulv3 is in place now. Zuulv2 is acting as your
> > gate keeper once again.
>
> Since the rollback, one of the neutron-lib (v2) jobs has been
> consistently failing [1] with:
>
> c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory
>
> Is this a known issue?
>

This is cause by the latest of cffi 1.11.1 which only comes with a tarball
and no wheels as 1.11.0 used to. [0][1][2].
There is a proposed temp d-g patch up to address this [3].

[0]
https://bitbucket.org/cffi/cffi/issues/339/no-wheel-packages-for--version

[1] https://pypi.python.org/pypi/cffi/1.11.0
[2] https://pypi.python.org/pypi/cffi/1.11.1
[3] https://review.openstack.org/#/c/509394/

Andrea Frittoli (andreaf)


>
>
> [1]
>
> http://logs.openstack.org/01/508901/1/check/gate-tempest-dsvm-neutron-src-neutron-lib-ubuntu-xenial/c1d98e2/console.html#_2017-10-04_11_06_07_410466
>
> __
> 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] [all] Important information for people with in-repo Zuul v3 config

[Andrea Frittoli]

On Tue, Oct 3, 2017 at 8:37 PM Monty Taylor  wrote:

> Hi everybody,
>
> The partial rollback of Zuulv3 is in place now. Zuulv2 is acting as your
> gate keeper once again. The status page for Zuulv2 can be found at
> http://status.openstack.org/zuul and Zuulv3 can be found at
> http://zuulv3.openstack.org.
>
> With the partial rollback of v3, we've left the v3 check pipeline
> configured for everyone so that new v3 jobs can be iterated on in
> preparation for rolling forward. Doing so leaves open a potential hole
> for breakage, so ...
>
> If you propose any changes to your repos that include changes to zuul
> config files (.zuul.yaml or .zuul.d) - PLEASE make sure that Zuul v3
> runs check jobs and responds before approving the patch.
>

While work on zuulv3 continues, what's likely to happen rather often is that
patches get a +1 from Jenkins and nothing or some unrelated error from Zuul,
caused perhaps by a restart of zuulv3.

It might be handy to configure a zuulv3-only trigger for patch recheck, to
avoid
consuming the 80% share of zuulv2 nodes to re-run a couple of jobs on zuulv3
side. To that end I proposed [0], I hope you find it useful.

Andrea Frittoli (andreaf)

[0] https://review.openstack.org/#/c/509379/


>
> If you don't don't do that, you could have zuul v2 land a patch that
> contains a syntax error that would result in invalid config for v3.
> Note that this would break not only your repo - but all testing using
> Zuul v3 (in which case we would have to temporarily remove your
> repository from the v3 configuration or ask for immediate revert)!
>
> Keep in mind that as we work on diagnosing the issue that caused the
> rollback, we could be restarting v3, shutting it down for a bit or it
> could be wedged - so v3 might not respond.
>
> Make sure you get a response from v3 on any v3 related patches. Please.
>
> Thanks!
> Monty
>
> __
> 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] [all] review.openstack.org downtime and Gerrit upgrade TODAY 15:00 UTC - 23:59 UTC

[Andrea Frittoli]

On Wed, Sep 20, 2017 at 12:00 PM Paul Bourke  wrote:

> I had the following bookmark:
>
> status:open is:mergeable (project:openstack/kolla OR
> project:openstack/kolla-ansible) NOT label:Code-Review>=-2,self NOT
> owner:pauldbourke NOT age:1month branch:master
>
> Which basically means, find changes that are:
>
> * open
> * in kolla or kolla-ansible
> * not reviewed by me
> * not owned by me
> * not older than a month
> * on the master branch
>
> This seems to no longer work unless I remove the
> 'label:Code-Review>=-2,self'.
>
> Anyone else having similar issues?
>

See Sean's message and patch
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122281.html

Andrea Frittoli (andreaf)


>
> On 19/09/17 00:58, Clark Boylan wrote:
> > On Mon, Sep 18, 2017, at 06:43 AM, Andreas Jaeger wrote:
> >> Just a friendly reminder that the upgrade will happen TODAY, Monday
> >> 18th, starting at 15:00 UTC. The infra team expects that it takes 8
> >> hours, so until 2359 UTC.
> >
> > This work was functionally completed at 23:43 UTC. We are now running
> > Gerrit 2.13.9. There are some cleanup steps that need to be performed in
> > Infra land, mostly to get puppet running properly again.
> >
> > You will also notice that newer Gerrit behaves in some new and exciting
> > ways. Most of these should be improvements like not needing to reapprove
> > changes that already have a +1 Workflow but also have a +1 Verified;
> > recheck should now work for these cases. If you find a new behavior that
> > looks like a bug please let us know, but we should also work to file
> > them upstream so that newer Gerrit can address them.
> >
> > Feel free to ask us questions if anything else comes up.
> >
> > Thank you to everyone that helped with the upgrade. Seems like these get
> > more and more difficult with each Gerrit release so all the help is
> > greatly appreciated.
> >
> > Clark
> >
> >
> __
> > 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
>
__
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] [PTG][QA] Queens PTG - QA Summary

[Andrea Frittoli]

On Tue, Sep 19, 2017 at 6:51 PM Andrea Frittoli 
wrote:

> Dear Bats,
>
> thanks everyone for participating to the Queens PTG - in person and
> remotely - and for making it a successful and enjoyable event.
>
> Here's a summary of what we discussed and achieved during the week.
> This report is far from complete - please complement it with QA related
> stories I may have missed.
>
> Unfortunately I ran out of bat stickers, I hope to have some more for the
> next time we meet :)
>
> Pike Retrospective
> -
> We experimented this time with running a retrospective [0].
> The input for the retrospective was almost exclusively from members of the
> QA team, which means that either the retrospective was poorly advertised by
> me, or that we did a nice job for the community during the QA cycle. I hope
> the latter :)
>
> The outcome of the retrospective was mostly 'yay' for tasks completed, and
> 'next cycle' for things we did not have time to work on.
> A few extra things that came up were:
> - bug triage and fix: we may need a bug czar and more automation to stay
> on top of the bug queue
> - elastic recheck categorisation: we may need an e-r czar to ensure we
> don't leave gate failures and races uncategorised and accumulating
> - meetings are mostly attended in the APAC time zone and very seldom
> attended by non-qa folks. We will consider shortening / reducing them and
> complementing them with QA office hours
>
> Monitoring the Gate
> --
> At the beginning of the Pike cycle we had a number of stability issues in
> the gate.
> To prevent issues from accumulating over time we discussed a few ideas
> about monitoring the status of the gate and providing more feedback to
> reviewers to help catch patches that may introduce issues [1].
> There are a few things that can be done relatively easily (or that we
> already have) in terms of data collection: job duration and failure rates,
> aggregated dstat data, resources created by tests.
> We miss OpenStack Health contributors to create new views for this data.
> Links from gerrit and zuul dashboard into OpenStack Health would help
> making the data discoverable.
>
> Tempest
> 
> A large chunk of the patches required to mark test.py as a stable
> interface for plugins was merged during the summit.
> It was good to have them merged during PTG so it was easier to fix
> resulting issues in Tempest plugins - at least Manila and Sahara needed a
> small patch.
> There are two patch series left [2][3] which should have very little
> impact on plugins - we'll try to merge them as soon as possible to avoid
> disruptions later in the Queens cycle.
>
> We worked with a few project teams on the goal to split Tempest plugins to
> a dedicated repo.
> The step by step process [4] linked to the goal includes an example
> section - we hope to get more and more examples in there from team who
> already went through the process.
>
> Devstack
> 
> We discussed about devstack runtime. The time to setup an OpenStack cloud
> using devstack seems to have increased over time [5][6] - it would be good
> to investigate why and see if there is time we can save in the gate and on
> each developer laptop :) Between August and September the average runtime
> in the gate increased by about 200s.
>
> Upgrade Testing
> --
> Rolling upgrade testing via grenade is important for project that seek
> obtaining the support rolling upgrade tag [7].
> While the scope of Grenade is rather fixed, it should be possible to
> support ordering (or relative ordering) in project updates.
>
> Policy Testing
> --
> We discussed what's next for the Queens cycle - support for multi-policy
> testing is the largest chunk of work planned for now.
>
> stestr
> ---
> The migration in ostestr to use stestr internally happened shortly before
> the PTG [8] and we worked through the PTG to amend any deviation in
> behaviour that this may have caused.
> Next in the todo list is to run stestr natively in Tempest, bypassing
> ostestr completely.
> The plan is for this to lead the way for projects to gradually remove the
> dependency to ostestr completely.
>
> HA Testing
> ---
> We talked quite a bit about HA and non-functional testing in general.
> Non-functional testing is not a good fit for gate testing, since it's not
> as reliable as functional / integration testing and it often produces
> results which needs to be interpreted by a human being.
> It also has strong dependencies to the deployment tooling and
> architecture. Until now most of OpenStack non-functional

[openstack-dev] QA Forum Topics for Sydney Summit

[Andrea Frittoli]

Dear all,

I would like to start brainstorming about QA related topics for the Forum
at the OpenStack Summit in Sydney.
I setup an etherpad to collect and share ideas [1].

At the PTG in Denver we discussed about non-functional testing for
OpenStack, and I think it would be interesting to discuss about it with the
wider community of OpenStack users and operators, so I went ahead and added
that as a proposed general topic

If you have proposals for topics, please include your IRC nick and/or
contact details as well.

Thank you!

Andrea Frittoli (andreaf)

[1] https://etherpad.openstack.org/p/qa-sydney-forum-topics
__
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] [PTG][QA] Queens PTG - QA Summary

[Andrea Frittoli]

e of months in the Queens cycle.
The NFV ecosystem would be happy to see publicly available non-functional
tests for OpenStack as well - if we had a common framework for such tests
we'd have an opportunity to attract contributions into tests from them as
well.

All things Zuul V3
---
Zuul v3 will provide a DB backend for test runs data, which we want to
integrate as a new data source for OpenStack Health, so that we can then
provide a full picture of all job runs in O-H.

Job names will change with zuul v3. While we found a simple solution to
keep OpenStack Health data functional with Zuul v3 provided metadata, we
will still loose 6 months of historical data in the process of migration,
for which we don't have a solution yet.

In terms of Zuul v3 jobs, we started working on Zuul v3 native Tempest jobs
[10]. this will be the basis for most jobs that run Tempest against
devstack.
The patch is still WIP, but it already runs the full Tempest run, with only
one test failure which I need to investigate.

QA Help Room

The help room was helpful (heh, I couldn't resist) mostly on day 1.
It was good to have dedicated time allocated to answer questions, since it
gave us space to open the laptop and work on code directly to answer
specific questions.

There were no questions asked during day 2. We used the time to join other
sessions and work on QA topics, but perhaps in Dublin we could consider
having a single help room day.

Cross-Community

NFV:
It was very interesting to discuss with the OPNFV community about CI and
test processes and architecture.
The aim on both sides to re-use / share tools and best practices, share
test results and avoid duplicate efforts where relevant.

K8S:
We discussed with dmellado the possibility of having a basic k8s client
hosted in a Tempest plugin [11], that could be used by k8s related
OpenStack project to write OpenStack / k8s scenario tests. The main
advantages of a k8s client written in Tempest format and hosted by
OpenStack would be a uniform interface with the OpenStack Tempest client
and a stable testing API.

QA Themes for Queens

We summarised the topics the QA team will focus on through the Queens cycle
in out queens priority etherpad [11].
The main etherpad for QA at the PTG in Denver is available as well [12].

QA Team Pictures

I'll forward the pictures as soon as I have a high-res copy available :)

Thanks for reading!

Andrea Frittoli (andreaf)

[0] https://etherpad.openstack.org/p/qa-pike-retrospective
[1] https://etherpad.openstack.org/p/qa-pike-gate-performance
[2]
https://review.openstack.org/#/q/topic:test_module_stable+(status:open+OR+status:merged
)
[3]
https://review.openstack.org/#/q/topic:bp/consistent-service-method-names+status:open+owner:%22Ghanshyam+Mann+%253Cghanshyammann%2540gmail.com%253E%22

[4] https://etherpad.openstack.org/p/tempest-separate-plugin
[5]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122271.html
[6]
http://status.openstack.org/openstack-health/#/test/devstack?resolutionKey=day&duration=P6M

[7]
https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html
[8]
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122135.html

[9] https://etherpad.openstack.org/p/qa-queens-ptg-destructive-testing
[10] https://review.openstack.org/#/c/504246/
[11] https://etherpad.openstack.org/p/qa-queens-priorities
[12] https://etherpad.openstack.org/p/qa-queens-ptg
__
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] [all] review.openstack.org downtime and Gerrit upgrade TODAY 15:00 UTC - 23:59 UTC

[Andrea Frittoli]

On Tue, Sep 19, 2017 at 12:58 AM Clark Boylan  wrote:

> On Mon, Sep 18, 2017, at 06:43 AM, Andreas Jaeger wrote:
> > Just a friendly reminder that the upgrade will happen TODAY, Monday
> > 18th, starting at 15:00 UTC. The infra team expects that it takes 8
> > hours, so until 2359 UTC.
>
> This work was functionally completed at 23:43 UTC. We are now running
> Gerrit 2.13.9. There are some cleanup steps that need to be performed in
> Infra land, mostly to get puppet running properly again.
>

Thanks Clark and the infra team for the hard on this!


>
> You will also notice that newer Gerrit behaves in some new and exciting
> ways. Most of these should be improvements like not needing to reapprove
> changes that already have a +1 Workflow but also have a +1 Verified;
> recheck should now work for these cases. If you find a new behavior that
> looks like a bug please let us know, but we should also work to file
> them upstream so that newer Gerrit can address them.
>

The "review-inbox-dashboard
<https://review.openstack.org/#/projects/openstack-dev/devstack,dashboards/important-changes:review-inbox-dashboard>"
dashboards
seems not be working anymore - at least they show up empty for a few
projects I tried [0][1][2][3].

Andrea Frittoli (andreaf)

[0] Tempest:
https://review.openstack.org/#/projects/openstack/tempest,dashboards/important-changes:review-inbox-dashboard

[1] subunit2sql:
https://review.openstack.org/#/projects/openstack-infra/subunit2sql,dashboards/important-changes:review-inbox-dashboard

[2] devstack:
https://review.openstack.org/#/projects/openstack-dev/devstack,dashboards/important-changes:review-inbox-dashboard

[3] nova:
https://review.openstack.org/#/projects/openstack/nova,dashboards/important-changes:review-inbox-dashboard



>
> Feel free to ask us questions if anything else comes up.
>


>
> Thank you to everyone that helped with the upgrade. Seems like these get
> more and more difficult with each Gerrit release so all the help is
> greatly appreciated.
>
> Clark
>
> __
> 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] [QA][ptg] QA Team social evening

[Andrea Frittoli]

Hello,

the plan for tonight is to meet at 6:15 in the lobby.
>From there we can take uber to the Art museum downtown
I didn't book a place, we I didn't book a place - we can walk around and
find a place for drinks & food.

See you later!

andrea

On Mon, Sep 11, 2017 at 1:17 PM Andrea Frittoli 
wrote:

> The best days according to the doodle are Wed or Thu,
> Since Wed there's an official PTG evening event, I'll book a place for
> Thursday.
>
> andrea
>
> On Wed, Aug 30, 2017 at 3:29 PM Andrea Frittoli 
> wrote:
>
>> Hello,
>>
>>
>> I'd like to propose a social evening for the folks who will attend QA
>> sessions at the PTG in Denver.
>>
>> I prepared a doodle [0] so if you're interested please vote :)
>>
>>
>> I added the link to the main QA etherpad [1] as well.
>>
>> If you know a good place to go for food or drinks please add it to the
>> etherpad as well.
>>
>>
>> Andrea
>>
>>
>> [0] https://doodle.com/poll/84mwxxbrtsmsaw4x
>>
>> [1] https://etherpad.openstack.org/p/qa-queens-ptg
>> <https://etherpad.openstack.org/p/qa-ptg-pike>
>>
>>
__
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] [QA][ptg] QA Team social evening

[Andrea Frittoli]

The best days according to the doodle are Wed or Thu,
Since Wed there's an official PTG evening event, I'll book a place for
Thursday.

andrea

On Wed, Aug 30, 2017 at 3:29 PM Andrea Frittoli 
wrote:

> Hello,
>
>
> I'd like to propose a social evening for the folks who will attend QA
> sessions at the PTG in Denver.
>
> I prepared a doodle [0] so if you're interested please vote :)
>
>
> I added the link to the main QA etherpad [1] as well.
>
> If you know a good place to go for food or drinks please add it to the
> etherpad as well.
>
>
> Andrea
>
>
> [0] https://doodle.com/poll/84mwxxbrtsmsaw4x
>
> [1] https://etherpad.openstack.org/p/qa-queens-ptg
> <https://etherpad.openstack.org/p/qa-ptg-pike>
>
>
__
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] [PTG][QA] QA PT Agenda & Schedule

[Andrea Frittoli]

Dear all,

attached the agenda / schedule [0][1] for the work of the QA team in Denver.

If there is a session you would like to join but you're not able to because
of a conflict, please do let me know, I'll do my best to accommodate
everyone needs.

The actual schedule will be defined in real time via the PTG bot so keep an
eye on it for the latest  news about what's going on in the QA room;
however we'll try to stick as much as possible to the proposed schedule.

See you in Denver and on IRC

Andrea Frittoli (andreaf)

[0] https://ethercalc.openstack.org/Queens-PTG-QA-Planning
[1] https://etherpad.openstack.org/p/qa-queens-ptg
__
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] [hacking][all] Hacking 1.0.0 release

[Andrea Frittoli]

Hello everyone,

Hacking 1.0.0 has been released [0].

There are some new rules available - off by default - so there should be no
impact in theory - but please do let the QA team know should you experience
any issue with it.

You may also want to enable the new rules in your project - they're about
unit tests: enforcing autospec in mock and use of specific assert method -
details in [1].

Andrea Frittoli (andreaf)

[0] https://pypi.python.org/pypi/hacking/1.0.0
[1] https://docs.openstack.org/releasenotes/hacking/unreleased.html#id1
__
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] [QA] Pike retrospective

[Andrea Frittoli]

Hello,

I started an etherpad [0] for a retrospective about QA in Pike.
I'd like to discuss about it during the PTG, so please add your inputs in
time.

Everyone is welcome to contribute, even if you're not in the QA team and/or
your not attending the PTG.

andrea

[0] https://etherpad.openstack.org/p/qa-pike-retrospective
__
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] [QA][ptg] QA Team social evening

[Andrea Frittoli]

Hello,


I'd like to propose a social evening for the folks who will attend QA
sessions at the PTG in Denver.

I prepared a doodle [0] so if you're interested please vote :)


I added the link to the main QA etherpad [1] as well.

If you know a good place to go for food or drinks please add it to the
etherpad as well.


Andrea


[0] https://doodle.com/poll/84mwxxbrtsmsaw4x

[1] https://etherpad.openstack.org/p/qa-queens-ptg

__
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] [QA] Queens PTL candidacy

[Andrea Frittoli]

Dear all,

I’d like to announce my candidacy for PTL of the QA Program for the Queens
cycle [0].

I served as PTL for QA during the Pike cycle, and I would be honoured to
continue to do so in the next six months.

After a few years working with the OpenStack community, I continue to find
it an exceptional experience and great opportunity for meeting and working
with great people, learning and innovating.

My priority is to provide, as a QA team, an excellent service to the
OpenStack community: stable gates (based on the great infrastructure
maintained by the infra team); easy to use and well documented tools to
enable project teams to achieve their quality goals; support and attention
to the community needs.

We have limited resources to achieve all that and I would like to counter
that by:
- mentorning new and existing contributors
- investing in automation to make the day to day maintainence less onerous
- making QA tools beneficial beyond OpenStack to attract contributors from
  other communities

Thank you!

Andrea Frittoli (andreaf)

[0] https://review.openstack.org/#/c/490477/
__
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] [tempest][infra][congress] subprocess launched in tempest test lacks file permission

[Andrea Frittoli]

On Fri, Jul 28, 2017 at 4:38 AM Eric K  wrote:

> A tempest test [1] launches additional instances of Congress using
> subprocess.popen and tests the coordination between them and the original
> instance launched by devstack. The problem is, the new instances are
> launched from the tempest test user rather than the user of the original
> congress instance devstack created. As a result, the new instances fail
> for being unable to access the encryption keys created by the original
> congress instance (600 permission).[2]
>
> Any suggestions for how to workaround this problem? Is it possible to
> somehow configure the gate job to run tempest tests as SU or as the
> stackuser that launches the original congress instance? Thanks so much!
>

Unfortunately we don't have any facility in Tempest to control the user for
subprocesses since Tempest is meant for API testing only. Starting a
subprocess within the test sounds a bit outside of the scope of what you
may want to do in a Tempest test.

If you want to use Tempest to verify HA type of scenarios you may want
to move the orchestration bit outside of Tempest - you could have an ansible
script that manages your services and run Tempest before and after certain
actions to verify that things are still working.

If you want tests to run in parallel to things happening to your system you
can do that but again you will need an external component to orchestrate
this, and you don't know what kind of tempest test will be running unless
you use a single long running scenario test designed for this purpose.

Andrea Frittoli (andreaf)


> [1]
> https://github.com/openstack/congress/blob/master/congress_tempest_tests/te
> sts/scenario/congress_ha/test_ha.py.disabled#L117
> <https://github.com/openstack/congress/blob/master/congress_tempest_tests/tests/scenario/congress_ha/test_ha.py.disabled#L117>
> (currently disabled,
> trying to re-enable)
>
> [2]
> http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ub
> untu-xenial/607623d/logs/testr_results.html.gz
> <http://logs.openstack.org/35/487235/5/check/gate-congress-dsvm-api-mysql-ubuntu-xenial/607623d/logs/testr_results.html.gz>
> (find: OSError: [Errno 13]
> Permission denied: '/etc/congress/keys/aes_key¹)
>
>
>
> __
> 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

[openstack-dev] [QA][PTG] Planning QA work at the PTG

[Andrea Frittoli]

Hello folks,

it's time we start planning the week for the QA team at the PTG in Denver.
Please add your ideas / proposal / comments to the etherpad [0].

We welcome proposed topics from anyone, not only the QA team.

Since we have a community goal in Queens for Tempest plugins, we will
definitely spend some time on that during the PTG.

Andrea Frittoli (andreaf)

[0] https://etherpad.openstack.org/p/qa-queens-ptg
__
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] [hacking] Propose removal of cores

[Andrea Frittoli]

On Tue, Jun 27, 2017 at 3:01 PM John Villalovos 
wrote:

> I am proposing that the following people be removed as core reviewers from
> the hacking project:
> https://review.openstack.org/#/admin/groups/153,members
>
> Joe Gordon
> James Carey
>
> +1


>
> Joe Gordon:
> Has not done a review in OpenStack since 16-Feb-2017
> http://stackalytics.com/?release=all&user_id=jogo
>
> Has not done a review in hacking since 23-Jan-2016:
> http://stackalytics.com/?module=hacking&user_id=jogo&release=all
>
>
> James Carey
> Has not done a review in OpenStack since 9-Aug-2016
> http://stackalytics.com/?release=all&user_id=jecarey
>
> Has not done a review in hacking since 9-Aug-2016:
> http://stackalytics.com/?module=hacking&release=all&user_id=jecarey
>
>
> And maybe this project needs more core reviewers as there have been six
> total reviews by four core reviewers so far in the Pike cycle:
> http://stackalytics.com/?release=pike&module=hacking
>
> it's always nice to have core reviewers.
The volume on the project is quite low though, so I suppose the current
team should be able to manage it.
If a patch is laking reviews please ping in the QA channel :)

Andrea Frittoli (andreaf).


> __
> 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

[openstack-dev] [QA][tempest] New Tempest stable interfaces coming soon

[Andrea Frittoli]

We have been working on making more Tempest module stable, especially for
Tempest plugins.
Once this work is complete, plugins will benefit from backward
compatibility on an extended set
of Tempest API.

This benefit comes at a small cost though, since we have to make a few
changes to the modules
before they can be declared as stable. In some cases the impact will be
zero, in other cases it
should be limited to changing an import line or adding an __init__
parameter, but I wanted to give
ample warning to everyone that the changes are coming, so that people can
prepare.

Some more details about this work and the specific patches on Tempest side
is available at [0].

Below is a list of the modules affected and main changes that will be
coming in the near future.
The list of modules affected

The following module will be marked as stable, and moved under tempest.lib:
- tempest/services/object_storage: there may be changes to the interface
- tempest/common/dynamic_creds: extra __init__ parameters will be required
- tempest/common/preprov_creds: extra __init__ parameters will be required
- tempest/common/fixed_network

The following modules will be marked stable for plugins:
- tempest/test.py: No change planned
- tempest/clients.py: Client aliases will only be defined when the
corresponding service is marked
  as enabled in config
- tempest/common/credentials_factory: signature changes to a couple of
helpers

Andrea Frittoli (andreaf)

[0] https://etherpad.openstack.org/p/tempest-test-module-stable
__
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] [keystone] We still have a not identical HEAD response

[Andrea Frittoli]

On Tue, Jul 11, 2017 at 12:06 PM Attila Fazekas  wrote:

> Hi all,
>
> Long time ago it was discussed to make the keystone HEAD responses
>  right [1] as the RFC [2][3] recommends:
>
> "  A response to the HEAD method is identical to what an equivalent
>request made with a GET would have been, except it lacks a body. "
>
> So, the status code needs to be identical as well !
>
> Recently  turned out, keystone is still not correct in all cases [4].
>
> 'Get role inference rule' (GET), 'Confirm role inference rule' (HEAD)
>  has the same URL pattern, but they differs in the status code (200/204)
>  which is not allowed! [5]
>
> This is the only documented case where both the HEAD and GET defined and
> the HEAD has a 204 response.
>
> Are you going to fix this [4] as it was fixed before [6] ?
>
> Best Regards,
> Attila
>
> PS.:
>  Here is the tempest change for accepting the right code [7].
>

On Tempest side, adding a new accepted code into the test would open the
doors to an API backward incompatible change on keystone side.
It should be possible for tests (as for a real application) to discover
what kind of behaviour is available on server side, the 204 or the 200
response.
Otherwise any existing code that expects a 204 response will cease to work
against clouds running a new version of keystone with the code change in.
If keystone would use a micro-version for this, Tempest would cap the
existing test to a max micro-version, and develop a new test for the new
behaviour.

andrea


>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-July/039140.html
> [2] https://tools.ietf.org/html/rfc7231#section-4.3.2
> [3] https://tools.ietf.org/html/rfc7234#section-4.3.5
> [4] https://bugs.launchpad.net/keystone/+bug/1701541
> [5]
> https://developer.openstack.org/api-ref/identity/v3/?expanded=confirm-role-inference-rule-detail,get-role-inference-rule-detail
> [6] https://bugs.launchpad.net/keystone/+bug/1334368
> [7] https://review.openstack.org/#/c/479286/
> __
> 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

[openstack-dev] [QA] QA meeting cancelled today

[Andrea Frittoli]

Hello everyone,

unfortunately I have to cancel the QA meeting today as I won't be able to
attend.
Sorry about the short notice!

Kind regards

andreaf
__
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] [all][tc] Moving away from "big tent" terminology

[Andrea Frittoli]

On Thu, Jun 15, 2017 at 4:45 PM Jeremy Stanley  wrote:

> On 2017-06-15 11:15:36 +0200 (+0200), Thierry Carrez wrote:
> [...]
> > I'd like to propose that we introduce a new concept: "OpenStack-Hosted
> > projects". There would be "OpenStack projects" on one side, and
> > "Projects hosted on OpenStack infrastructure" on the other side (all
> > still under the openstack/ git repo prefix).
>
> I'm still unconvinced a term is needed for this. Can't we just have
> "OpenStack Projects" (those under TC governance) and "everything
> else?" Why must the existence of any term require a term for its
> opposite?
>

+1!

We don't need to try and bring everything which is not an OpenStack
project under a single name which will also then require a definition which
may not fit all.

Andrea Frittoli (andreaf)


>
> > We'll stop saying "official OpenStack project" and "unofficial
> > OpenStack project". The only "OpenStack projects" will be the
> > official ones. We'll chase down the last mentions of "big tent" in
> > documentation and remove it from our vocabulary.
> [...]
>
> I agree on getting rid of the "big tent" phrase anywhere we find it,
> though I thought we'd already avoided using that in favor of more
> descriptive terminology anyway. Also I'm very excited to see a focus
> on "OpenStack projects" I just don't see a benefit to making up a
> name for "not an OpenStack project."



> --
> Jeremy Stanley
> __
> 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

[openstack-dev] [qa] Bug Triage and Integrated gate issue categorisation

[Andrea Frittoli]

Hello folks,

The QA team triage duty [0] has no-one assigned for the rest
of the cycle (except for one week), we could really use some volunteers.

I'm also introducing a new rota for integrated gate issue categorisation
[1].
The idea is to stay on top of the categorisation of issues, so that bugs are
filed, identified in reviews and can be triaged and solved by the relevant
teams.

If you're new to OpenStack QA / CI this is a great opportunity to get
started, I'm happy to offer mentorship to anyone who would like to give
this a try.

Just add your IRC nick (and name if you want) in one of the etherpad
and reach out to the QA team in #openstack-qa if you have any question
and/or need guidance.

Thank you!

Andrea (andreaf)

[0] https://etherpad.openstack.org/p/pike-qa-bug-triage
[1] https://etherpad.openstack.org/p/pike-gate-issue-categotisation
__
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] [QA] Proposed changes to the team meeting time

[Andrea Frittoli]

I proposed a change to irc-meetings [1] to move the meeting to 8:00 UTC.
The first 8:00 UTC meeting will be next week June 15th.

[1] https://review.openstack.org/472194

On Mon, May 29, 2017 at 6:01 AM Masayuki Igawa  wrote:

> Thanks Andrea,
>
> +1
> But my only one concern is this change is not good for you, right? Of
> course, you don't need to attend both meetings, though :)
>

It should not be a problem for me to join in most cases.

andrea


>
> --
>   Masayuki Igawa
>
>
>
> On Fri, May 26, 2017, at 10:41 AM, zhu.fang...@zte.com.cn wrote:
>
>
> +1, thanks!
>
>
> zhufl
>
>
>
>
> Original Mail
> *Sender: * ＜andrea.fritt...@gmail.com＞;
> *To: * ＜openstack-dev@lists.openstack.org＞;
> *Date: *2017/05/25 21:19
> *Subject: **[openstack-dev] [QA] Proposed changes to the team meeting
> time*
>
>
> Hello team,
>
> our current QA team meeting schedule alternates between 9:00 UTC and 17:00
> UTC.
> The 9:00 meetings is a bit towards the end of the day for out contributors
> in APAC, so I'm proposing to move the meeting to 8:00 UTC.
>
> Please respond with +1 / -1 and/or comments, I will leave the poll open
> for about 10 days to make sure everyone interested gets a chance to comment.
>
> Thank you
>
> andrea
>
>
>
>
> *__*
> 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
>
__
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-dev] [Designate]

[Andrea Frittoli]

On Thu, May 25, 2017 at 5:27 PM Carmine Annunziata <
carmine.annunziat...@gmail.com> wrote:

> Hi everyone,
> I integrated Designate in Openstack by devstack, now i'm using the new
> default commands like zone create/delete, etc. I got this problem:
>
>
> +--+---+-++++
> | id   | name  | type|
> serial | status | action |
>
> +--+---+-++++
> | fd80ab02-c8d7-4b06-9a4a-6026c3ca7a1c | example1.net. | PRIMARY |
> 1495725108 | ERROR  | DELETE |
> | bfd19d7d-b259-4f88-afe0-b56d21d09ebe | example2.net. | PRIMARY |
> 1495726327 | ERROR  | DELETE |
> | a33bf1fc-0112-48de-8f43-51c34845f011 | example1.com. | PRIMARY |
> 1495727006 | ERROR  | CREATE |
>
> +--+---+-++++
>

Hello Carmine,

I'm not an expect in Designate, but I can recommend you try to have a look
in designate logs to see why your zone creation fails.
If you don't find your answer there you could post relevant cli commands,
log fragments and configuration to a publicly available place (e.g. [1])
and ask the ML again.

andrea

[1] https://paste.openstack.org

>
> Same on dashboard.
>
> Cheers,
> --
> Carmine
> __
> 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

[openstack-dev] [QA] Proposed changes to the team meeting time

[Andrea Frittoli]

Hello team,

our current QA team meeting schedule alternates between 9:00 UTC and 17:00
UTC.
The 9:00 meetings is a bit towards the end of the day for out contributors
in APAC, so I'm proposing to move the meeting to 8:00 UTC.

Please respond with +1 / -1 and/or comments, I will leave the poll open for
about 10 days to make sure everyone interested gets a chance to comment.

Thank you

andrea
__
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] [ptg] Strawman Queens PTG week slicing

[Andrea Frittoli]

On Wed, May 24, 2017 at 11:40 AM Dmitry Tantsur  wrote:

> On 05/24/2017 12:10 PM, Thierry Carrez wrote:
> > Hi everyone,
> >
> > In a previous thread[1] I introduced the idea of moving the PTG from a
> > purely horizontal/vertical week split to a more
> > inter-project/intra-project activities split, and the initial comments
> > were positive.
> >
> > We need to solidify how the week will look like before we open up
> > registration (first week of June), so that people can plan their
> > attendance accordingly. Based on the currently-signed-up teams and
> > projected room availability, I built a strawman proposal of how that
> > could look:
> >
> >
> https://docs.google.com/spreadsheets/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/pubhtml?gid=397241312&single=true
> >
> > Let me know what you think. If you're scheduled on the Wed-Fri but would
> > rather be scheduled on Mon-Tue to avoid conflicting with another team,
> > let me know. If you're scheduled on Wed-Fri but plan to skip the Friday,
> > let me know as well, I'll update the spreadsheet accordingly.
>
> This looks good.
>
> I'm only surprised that Ironic is under question for the VM-BM room. We're
> the
> Bare Metal service after all :) Please correct me if I'm misunderstanding
> that
> room's purpose.
>
> >
> > One of the things you might notice on Mon-Tue is the "helproom" concept.
> > In the spirit of separating inter-project and intra-project activities,
> > support teams (Infra, QA, Release Management, Stable branch maintenance,
> > but also teams that are looking at decentralizing their work like Docs
> > or Horizon) would have team members in helprooms available to provide
> > guidance to vertical teams on their specific needs.


This looks fine for me, one thing that I missed in Atlanta was the
possibility to join
any of the WG sessions. By moving QA sessions to the 2nd part of the week,
QA team members could take turn attending the QA help room and join WG
conversations where needed.


> Some of those teams
> > (like Infra/QA) could still have a "team meeting" on Wed-Fri to get
> > stuff done as a team, though.
>

The only concern I have here is that the topics to be discussed by the QA
and Infra
teams will be different and a shared room might not be ideal since we would
have two
ongoing discussions in the same room.
The three days would be a mix of QA sessions and hacking. Sharing a room
for the
hacking part is not an issue, but I would prefer to have a dedicated room
for at least 1.5 days.

andrea


>
> I don't have a strong opinion here, but this sounds like a great idea.
>
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-May/116971.html
> >
>
>
> __
> 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] [tempest] Proposing Fanglei Zhu for Tempest core

[Andrea Frittoli]

Polls are closed now, with six positive votes.
Welcome to the team Fanglei!

andrea

On Thu, May 18, 2017 at 10:59 AM Attila Fazekas  wrote:

> +1, Totally agree.
>
> Best Regards,
> Attila
>
> On Tue, May 16, 2017 at 10:22 AM, Andrea Frittoli <
> andrea.fritt...@gmail.com> wrote:
>
>> Hello team,
>>
>> I'm very pleased to propose Fanglei Zhu (zhufl) for Tempest core.
>>
>> Over the past two cycle Fanglei has been steadily contributing to Tempest
>> and its community.
>> She's done a great deal of work in making Tempest code cleaner, easier to
>> read, maintain and
>> debug, fixing bugs and removing cruft. Both her code as well as her
>> reviews demonstrate a
>> very good understanding of Tempest internals and of the project future
>> direction.
>> I believe Fanglei will make an excellent addition to the team.
>>
>> As per the usual, if the current Tempest core team members would please
>> vote +1
>> or -1(veto) to the nomination when you get a chance. We'll keep the polls
>> open
>> for 5 days or until everyone has voted.
>>
>> References:
>> https://review.openstack.org/#/q/owner:zhu.fanglei%2540zte.com.cn
>> https://review.openstack.org/#/q/reviewer:zhufl
>>
>> Thank you,
>>
>> Andrea (andreaf)
>>
>> __
>> 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
>
__
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] [qa] Create subnetpool on dynamic credentials

[Andrea Frittoli]

Hi Hongbin,

If several of your test cases require a subnet pool, I think the simplest
solution would be creating one in the resource creation step of the tests.
As I understand it, subnet pools can be created by regular projects (they
do not require admin credentials).

The main advantage that I can think of for having subnet pools provisioned
as part of the credential provider code is that - in case of
pre-provisioned credentials - the subnet pool would be created and delete
once per test user as opposed to once per test class.

That said I'm not opposed to the proposal in general, but if possible I
would prefer to avoid adding complexity to an already complex part of the
code.

andrea

On Sun, May 21, 2017 at 2:54 AM Hongbin Lu  wrote:

> Hi QA team,
>
>
>
> I have a proposal to create subnetpool/subnet pair on dynamic credentials:
> https://review.openstack.org/#/c/466440/ . We (Zun team) have use cases
> for using subnets with subnetpools. I wanted to get some early feedback on
> this proposal. Will this proposal be accepted? If not, would appreciate
> alternative suggestion if any. Thanks in advance.
>
>
>
> Best regards,
>
> Hongbin
> __
> 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

[openstack-dev] [tempest] Proposing Fanglei Zhu for Tempest core

[Andrea Frittoli]

Hello team,

I'm very pleased to propose Fanglei Zhu (zhufl) for Tempest core.

Over the past two cycle Fanglei has been steadily contributing to Tempest
and its community.
She's done a great deal of work in making Tempest code cleaner, easier to
read, maintain and
debug, fixing bugs and removing cruft. Both her code as well as her reviews
demonstrate a
very good understanding of Tempest internals and of the project future
direction.
I believe Fanglei will make an excellent addition to the team.

As per the usual, if the current Tempest core team members would please
vote +1
or -1(veto) to the nomination when you get a chance. We'll keep the polls
open
for 5 days or until everyone has voted.

References:
https://review.openstack.org/#/q/owner:zhu.fanglei%2540zte.com.cn
https://review.openstack.org/#/q/reviewer:zhufl

Thank you,

Andrea (andreaf)
__
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] [tempest] Jenkins verification failures with stable release gates

[Andrea Frittoli]

On Mon, May 15, 2017 at 2:51 PM Hemanth N  wrote:

> Hi
>
> I have written new Tempest functional test cases for Identity OAUTH API.
> https://review.openstack.org/#/c/463240/
>
>
> This patch have dependency on a keystone fix that is still under
> review and I have mentioned this patch as Depends-On for above one.
> (https://review.openstack.org/#/c/464577/)
>
> The gates with stable releases are failing but on master it is successful
> gate-tempest-dsvm-neutron-full-ubuntu-xenial-ocata
> gate-tempest-dsvm-neutron-full-ubuntu-xenial-newton
>
> I am assuming the stable releases will cherry-pick the Depends-On
> patches and then builds/verifies the environment.
> Is my understanding correct?
>

Your change is for keystone master, and it won't be automatically
cherry-picked.


> If not, how should I proceed in such scenarios.
>

Your change make it possible to use the oath API in deployments where TLS
is terminated in front of the API server. I would use a feature flag on
Tempest side
to indicate whether this keystone feature is available. Default to false,
 set to true in Pike
in devstack, skip the tests if the feature is not available.

Even if your change was back ported, merging this would immediately enforce
the new behaviour on all Netwton+ clouds, to I think having a feature flag
would be
useful anyways.

andrea


> Thanks in Advance.
>
> Best Regards,
> Hemanth
>
> __
> 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

[openstack-dev] [QA] PTG in Denver

[Andrea Frittoli]

Hello team,

I'm trying to get an idea about how many of us (QA) will be (or intend to
be) at the PTG in Denver.
Could you reply to me only or ping in IRC and let me know?

Thanks

andrea
__
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] [tripleo] pingtest vs tempest

[Andrea Frittoli]

On Thu, May 4, 2017 at 7:13 PM Emilien Macchi  wrote:

> On Thu, May 4, 2017 at 9:41 AM, Dan Prince  wrote:
> > On Thu, 2017-05-04 at 03:11 -0400, Luigi Toscano wrote:
> >> - Original Message -
> >> > On Wed, 2017-05-03 at 17:53 -0400, Emilien Macchi wrote:
> >> > > (cross-posting)
> >> >
> >> > > Instead of running the Pingtest, we would execute a Tempest
> >> > > Scenario
> >> > > that boot an instance from volume (like Pingstest is already
> >> > > doing)
> >> > > and see how it goes (in term of coverage and runtime).
> >> > > I volunteer to kick-off the work with someone more expert than I
> >> > > am
> >> > > with quickstart (Arx maybe?).
> >> > >
> >> > > Another iteration could be to start building an easy interface to
> >> > > select which Tempest tests we want a TripleO CI job to run and
> >> > > plug
> >> > > it
> >> > > to our CI tooling (tripleo-quickstart I presume).
> >> >
> >> > Running a subset of Tempest tests isn't the same thing as designing
> >> > (and owning) your own test suite that targets the things that mean
> >> > the
> >> > most to our community (namely speed and coverage). Even giving up
> >> > 5-10
> >> > minutes of runtime...just to be able to run Tempest isn't something
> >> > that some of us would be willing to do.
> >>
> >> As I mentioned, you can do it with Tempest (the library). You can
> >> have your own test suite that does exactly what you are asking
> >> (namely, a set of scenario tests based on Heat which targets the
> >> TripleO use case) in a Tempest plugin and there is no absolute reason
> >> that those tests should add 5-10 minutes of runtime compared to
> >> pingtest.
> >>
> >> It/they would be exactly pingtest, only implemented using a different
> >> library and running with a different runner, with the *exact* same
> >> run time.
> >>
> >> Obvious advantages: only one technology used to run tests, so if
> >> anyone else want to run additional tests, there is no need to
> >> maintain two code paths; reuse on a big and proven library of test
> >> and test runner tools.
> >
> > I like the idea of getting pingtest out of tripleo.sh as more of a
> > stand alone tool. I would support an effort that re-implemented it...
> > and using tempest-lib would be totally fine. And as you point out one
> > could even combine these tests with a more common "Tempest" run that
> > incorporates the scenarios, etc.
>
> I don't understand why we would re-implement the pingtest in a tempest
> plugin.
> Could you please tell us what is the technical difference between what
> does this scenario :
>
> https://github.com/openstack/tempest/blob/master/tempest/scenario/test_volume_boot_pattern.py
>
> And this pingtest:
>
> https://github.com/openstack/tripleo-heat-templates/blob/master/ci/pingtests/tenantvm_floatingip.yaml
>
> They both create a volume Cinder, snapshot it in Glance and and spawn
> a Nova server from the volume.
>
> What one does that the other one doesn't?
>
> > To me the message is clear that we DO NOT want to consume the normal
> > Tempest scenarios in TripleO upstream CI at this point. Sure there is
> > overlap there, but the focus of those tests is just plain different...
>
> I haven't seen strong pushback in this thread except you.
> I'm against overlap in general and this one is pretty obvious. Why
> would we maintain a tripleo-specific Tempest scenario while existing
> ones would work for us. Please give me a technical reason in what is
> not good enough in the existing scenarios.
>
> > speed isn't a primary concern there as it is for us so I don't think we
> > should do it now. And probably not ever unless the CI job time is less
> > than an hour. Like even if we were able to tune a set of stock Tempest
> > smoke tests today to our liking unless TripleO proper gates on the
> > runtime of those not increasing we'd be at risk of breaking our CI
> > queues as the wall time would potentially get too long. In this regard
> > this entire thread is poorly named I think in that we are no longer
> > talking about 'pingtest vs. tempest' but rather the implementation
> > details of how we reimplement our existing pingtest to better suite the
> > community.
>
> What I would like to see if we're going to use Tempest in our gate, is
> to run at least one TripleO jobs as voting in Tempest.
>
> Tempest folks: I need your support here. We have been running Puppet
> jobs as non-voting and we have seen a quite number of patches that
> broke us because folks were ignore the jobs. If we switch TripleO to
> use more Tempest, being in your gate might be required. We'll run the
> fastest and  more stable job that we have to make sure the impact for
> you is minimal.
>
>
For TripleO I guess the risks of failures might be about deploying tempest
tests and their dependencies more than else.

We're increasing our stable API surface constantly, and I believe the number
of breakages have decreased over time - I don't have data to support this
though.

>From a test pov, any cloud deploye

Re: [openstack-dev] [tripleo] pingtest vs tempest

[Andrea Frittoli]

On Thu, May 4, 2017 at 11:11 PM Dan Prince  wrote:

> On Thu, 2017-05-04 at 14:11 -0400, Emilien Macchi wrote:
> > On Thu, May 4, 2017 at 9:41 AM, Dan Prince 
> > wrote:
> > > On Thu, 2017-05-04 at 03:11 -0400, Luigi Toscano wrote:
> > > > - Original Message -
> > > > > On Wed, 2017-05-03 at 17:53 -0400, Emilien Macchi wrote:
> > > > > > (cross-posting)
> > > > > > Instead of running the Pingtest, we would execute a Tempest
> > > > > > Scenario
> > > > > > that boot an instance from volume (like Pingstest is already
> > > > > > doing)
> > > > > > and see how it goes (in term of coverage and runtime).
> > > > > > I volunteer to kick-off the work with someone more expert
> > > > > > than I
> > > > > > am
> > > > > > with quickstart (Arx maybe?).
> > > > > >
> > > > > > Another iteration could be to start building an easy
> > > > > > interface to
> > > > > > select which Tempest tests we want a TripleO CI job to run
> > > > > > and
> > > > > > plug
> > > > > > it
> > > > > > to our CI tooling (tripleo-quickstart I presume).
> > > > >
> > > > > Running a subset of Tempest tests isn't the same thing as
> > > > > designing
> > > > > (and owning) your own test suite that targets the things that
> > > > > mean
> > > > > the
> > > > > most to our community (namely speed and coverage). Even giving
> > > > > up
> > > > > 5-10
> > > > > minutes of runtime...just to be able to run Tempest isn't
> > > > > something
> > > > > that some of us would be willing to do.
> > > >
> > > > As I mentioned, you can do it with Tempest (the library). You can
> > > > have your own test suite that does exactly what you are asking
> > > > (namely, a set of scenario tests based on Heat which targets the
> > > > TripleO use case) in a Tempest plugin and there is no absolute
> > > > reason
> > > > that those tests should add 5-10 minutes of runtime compared to
> > > > pingtest.
> > > >
> > > > It/they would be exactly pingtest, only implemented using a
> > > > different
> > > > library and running with a different runner, with the *exact*
> > > > same
> > > > run time.
> > > >
> > > > Obvious advantages: only one technology used to run tests, so if
> > > > anyone else want to run additional tests, there is no need to
> > > > maintain two code paths; reuse on a big and proven library of
> > > > test
> > > > and test runner tools.
> > >
> > > I like the idea of getting pingtest out of tripleo.sh as more of a
> > > stand alone tool. I would support an effort that re-implemented
> > > it...
> > > and using tempest-lib would be totally fine. And as you point out
> > > one
> > > could even combine these tests with a more common "Tempest" run
> > > that
> > > incorporates the scenarios, etc.
> >
> > I don't understand why we would re-implement the pingtest in a
> > tempest plugin.
> > Could you please tell us what is the technical difference between
> > what
> > does this scenario :
> > https://github.com/openstack/tempest/blob/master/tempest/scenario/tes
> > t_volume_boot_pattern.py
> >
> > And this pingtest:
> > https://github.com/openstack/tripleo-heat-templates/blob/master/ci/pi
> > ngtests/tenantvm_floatingip.yaml
> >
> > They both create a volume Cinder, snapshot it in Glance and and spawn
> > a Nova server from the volume.
> >
> > What one does that the other one doesn't?
>
> I don't think these are the same things. Does the Tempest test even
> create a floating IP? And in the case of pingtest we also cover Heat
> API in the overcloud (also valuable coverage). And even if they could
> be made to match today is there any guarantee that they would diverge
> in the future or maintain the same speed goals as that test lives in
> Tempest (and most TripleO cores don't review there).
>
> The main difference that I care about is it is easier for us to
> maintain and fix the pingtest varient at this point. We care a lot
> about our CI, and like I said before increasing the runtime isn't
> something we could easily tolerate. I'm willing to entertain reuse so
> long as it also allows us the speed and control we desire.
>
> >
> > > To me the message is clear that we DO NOT want to consume the
> > > normal
> > > Tempest scenarios in TripleO upstream CI at this point. Sure there
> > > is
> > > overlap there, but the focus of those tests is just plain
> > > different...
> >
> > I haven't seen strong pushback in this thread except you.
>
> Perhaps most cores haven't weighed in on this issue because moving to
> Tempest(-lib) isn't the most pressing issue ATM. We have a lot of
> architectural changes happening at the moment for example and that is
> why I only replied to this thread this week.
>
> > I'm against overlap in general and this one is pretty obvious. Why
> > would we maintain a tripleo-specific Tempest scenario while existing
> > ones would work for us. Please give me a technical reason in what is
> > not good enough in the existing scenarios.
>
> We maintain it because we care about speed I think.


We (QA) care about speed as well :)

E

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Andrea Frittoli]

On Tue, May 2, 2017 at 4:56 PM Sean McGinnis  wrote:

> On Tue, May 02, 2017 at 03:36:20PM +0200, Jordan Pittier wrote:
> > On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann 
> > wrote:
> >
> > > In Cinder, there are many features/APIs which are backend specific and
> > > will return 405 or 501 if same is not implemented on any backend [1].
> > > If such tests are implemented in Tempest, then it will break some gate
> > > where that backend job is voting. like ceph job in glance_store gate.
> > >
> > > There been many such cases recently where ceph jobs were broken due to
> > > such tests and recently it is for force-delete backup feature[2].
> > > Reverting force-delete tests in [3]. To resolve such cases at some
> > > extend, Jon is going to add a white/black list of tests which can run
> > > on ceph job [4] depends on what all feature ceph implemented. But this
> > > does not resolve it completely due to many reason like
> > > 1. External use of Tempest become difficult where user needs to know
> > > what all tests to skip for which backend
> > > 2. Tempest tests become too specific to backend.
> > >
> > > Now there are few options to resolve this:
> > > 1. Tempest should not tests such API/feature which are backend
> > > specific like mentioned by api-ref like[1].
> > >
> > So basically, if one of the 50 Cinder driver doesn't support a feature,
> we
> > should never test that feature ? What about the 49 other drivers ? If a
> > feature exists and can be tested in the Gate (with whatever default
> > config/driver is shipped) then I think we should test it.
> >
> 50? Over 100 as of Ocata.
>
> Well, is tempest's purpose in life to provide complete gate test coverage,
> or is tempest's purpose in life to give operators a tool to validate that
> their deployment is working as expected?
>

Neither.

Tempest is used for several different purposes, but I would say it was never
meant to ensure 100% coverage of the API. It is used by many operators to
validate their deployments, even if that part is better achieved via the
"scenario" tests, as opposed to the "API" tests.

Main use cases for Tempest are:
- integration (cross-service) testing in the gate
- help to ensure API backward compatibility / stability
- home for interoperability tests


> In attempting to do things in the past, I've received push back based on
> the argument that it was the latter. For this reason, in-tree tempest tests
> were added to Cinder to give us a way to get better test coverage for our
> own sake.
>

There are several use cases for in-tree tests.
Some examples:

Test that provide very little cross-service validation (e.g. most API
negative
tests) do not need to be in Tempest. Running a full cloud is expensive
resource and time-wise, and it's not the best test environment to run a
large
combination of negative test cases.

Many tests cannot be driven via API. It's very hard for instance to test
any transient resource state via API, since there's not enough control via
the API.

Scheduler tests are not best implemented via API as well, since they often
require
several nodes and resources when executed in a full cloud environment.


> Now that this is all in place, I think it's working well and I would like
> to see it continue that way. IMO, tempest proper should not have anything
> that isn't universally applicable to real world deployments. Not just for
> things like Ceph, but things like the manage/unmanage backend specific
> tests that were added and broke a large majority of third party CI.
>

Is there a policy in Cinder that a backend must implement a certain set of
APIs? If so we could think of testing only that set of APIs in Tempest, so
that
any app developer knows that he/she can rely on that minimum set of APIs.

If the list of APIs is not constrained on cinder side, the next driver
could come
along that does not support an API, and then we would have to stop testing
it
in Tempest - which is not an option.

Another point is that API that rely on services other than nova are best
tested
in Tempest, so that the tests run in the gate of other services as well -
or at
least the cinder functional test job should run against the other services
as well.


>
> Backend specific things should not be part of tempest in my opinion. We
> should cover those things through in-tree tempest plugins and our own
> testing.
> >
> > > 2. Tempest test can be disabled/skip based on backend. - This is not
> > > good idea as it increase config options and overhead of setting those.
> > >
> > Using regex and blacklist, any 3rd party CI can skip any test based on
> the
> > test ID. Without introducing a config flag. See:
> >
> https://github.com/openstack-infra/project-config/blob/1cea31f402b6b047cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871
> >
> >
> > > 3. Tempest test can verify behavior with if else condition as per
> > > backend. This is bad idea and lose the test strength.
> > >
> > Yeah, that's bad.
> >
> > >
> > > IMO options 

Re: [openstack-dev] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Andrea Frittoli]

On Tue, May 2, 2017 at 2:41 PM Jordan Pittier 
wrote:

> On Tue, May 2, 2017 at 7:42 AM, Ghanshyam Mann 
> wrote:
>
>> In Cinder, there are many features/APIs which are backend specific and
>> will return 405 or 501 if same is not implemented on any backend [1].
>> If such tests are implemented in Tempest, then it will break some gate
>> where that backend job is voting. like ceph job in glance_store gate.
>>
>> There been many such cases recently where ceph jobs were broken due to
>> such tests and recently it is for force-delete backup feature[2].
>> Reverting force-delete tests in [3]. To resolve such cases at some
>> extend, Jon is going to add a white/black list of tests which can run
>> on ceph job [4] depends on what all feature ceph implemented. But this
>> does not resolve it completely due to many reason like
>> 1. External use of Tempest become difficult where user needs to know
>> what all tests to skip for which backend
>> 2. Tempest tests become too specific to backend.
>>
>> Now there are few options to resolve this:
>> 1. Tempest should not tests such API/feature which are backend
>> specific like mentioned by api-ref like[1].
>>
> So basically, if one of the 50 Cinder driver doesn't support a feature, we
> should never test that feature ? What about the 49 other drivers ? If a
> feature exists and can be tested in the Gate (with whatever default
> config/driver is shipped) then I think we should test it.
>
>
>> 2. Tempest test can be disabled/skip based on backend. - This is not
>> good idea as it increase config options and overhead of setting those.
>>
> Using regex and blacklist, any 3rd party CI can skip any test based on the
> test ID. Without introducing a config flag. See:
> https://github.com/openstack-infra/project-config/blob/1cea31f402b6b047cde203c12184b5392c90/jenkins/jobs/devstack-gate.yaml#L1871
>

This way each 3rd party system has to maintain its own list, which has the
advantage that
different teams maintain their own list (which is nice from an ownership
and scale pov).

However I think such list of tests are not as re-usable as having a
devstack plugin (or an
ansible or puppet module) changing a few tempest config options.


>
>> 3. Tempest test can verify behavior with if else condition as per
>> backend. This is bad idea and lose the test strength.
>>
> Yeah, that's bad.
>
>>
>> IMO options 1 is better options. More feedback are welcome.
>
>
>> ..1
>> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup
>> ..2 https://bugs.launchpad.net/glance/+bug/1687538
>> ..3 https://review.openstack.org/#/c/461625/
>> ..4
>> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html
>>
>> -gmann
>>
>> __
>> 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
>
__
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] [qa][cinder][ceph] should Tempest tests the backend specific feature?

[Andrea Frittoli]

On Tue, May 2, 2017 at 6:46 AM Ghanshyam Mann 
wrote:

> In Cinder, there are many features/APIs which are backend specific and
> will return 405 or 501 if same is not implemented on any backend [1].
> If such tests are implemented in Tempest, then it will break some gate
> where that backend job is voting. like ceph job in glance_store gate.
>

Having a test in Tempest is important for interoperability and API backward
compatibility.
As long as available features are discoverable and reported in a consistent
way, it
is possible for app developer to write application that will work fine
against
different backends.


>
> There been many such cases recently where ceph jobs were broken due to
> such tests and recently it is for force-delete backup feature[2].
> Reverting force-delete tests in [3]. To resolve such cases at some
> extend, Jon is going to add a white/black list of tests which can run
> on ceph job [4] depends on what all feature ceph implemented. But this
> does not resolve it completely due to many reason like
> 1. External use of Tempest become difficult where user needs to know
> what all tests to skip for which backend
> 2. Tempest tests become too specific to backend.
>
> Now there are few options to resolve this:
> 1. Tempest should not tests such API/feature which are backend
> specific like mentioned by api-ref like[1].
> 2. Tempest test can be disabled/skip based on backend. - This is not
> good idea as it increase config options and overhead of setting those.
>

Tempest has many options because we decide not to rely on discovery, i.e.
we configure what we expect to find in the target cloud. I don't think we
can use
this as a factor to influence the decision in this case.


> 3. Tempest test can verify behavior with if else condition as per
> backend. This is bad idea and lose the test strength.
>
> IMO options 1 is better options. More feedback are welcome.
>
> ..1
> https://developer.openstack.org/api-ref/block-storage/v3/?expanded=force-delete-a-backup-detail#force-delete-a-backup
> ..2 https://bugs.launchpad.net/glance/+bug/1687538
> ..3 https://review.openstack.org/#/c/461625/
> ..4
> http://lists.openstack.org/pipermail/openstack-dev/2017-April/115229.html
>
> -gmann
>
> __
> 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] [all] Yakumo: Pythonic, unified OpenStack client library

[Andrea Frittoli]

On Wed, May 3, 2017 at 12:44 PM Brian Curtin  wrote:

> On Tue, May 2, 2017 at 10:46 PM, Akira Yoshiyama  > wrote:
>
>> Hello all,
>>
>> I'm pleased to announce Yakumo, yet another unified OpenStack client
>> library with an interactive shell. You can find Yakumo below:
>>
>>PyPI: https://pypi.python.org/pypi/yakumo/
>>Github: https://github.com/yosshy/python-yakumo/
>>
>> Yakumo development focuses to:
>>
>> * Pythonic: handles each cloud resource as an object in the same manner
>> * Unified: handles all OpenStack APIs at once
>
>
Does Yakumo provide some plugin mechanism, or do you plan to include and
support
all OpenStack services in Yakumo?


> * Less dependency: no import of other OpenStack client libraries
>>
>> Why do we have to specify IDs of cloud resources in Python
>> programming? Python is an object-oriented programming language. IMO,
>> we should use objects to represent cloud resources, including method
>> arguments. It's one of the reasons I've started Yakumo project.
>>
>> Yakumo 0.11.0 suports OpenStack APIs below:
>>
>> * Identity API v2/v3
>> * Compute API v2
>> * Networking v2
>> * Image Service API v1/v2
>> * Block Storage v1/v2
>> * Object Storage v1
>>
>> Yakumo has 23 sample smoke tests below for the APIs now. It's useful
>> to test your cloud and learn usage of Yakumo.
>>
>>https://github.com/yosshy/python-yakumo/tree/master/yakumo/smoketests
>>
>> And also you can use 'ossh', an interactive python shell in Yakumo.
>> It's a good example.
>> # ossh --os-cloud=mypackstack
>>
>> Finding existing resources:
>> (c is an client object automatically generated for mypackstack
>> environment)
>> >>> i = c.image.find_one(name="trusty")
>> >>> f = c.flavor.find_one(name='m1.small')
>> >>> k = c.key_pair.find_one(name='key1')
>> >>> n = c.network.find_one(name='private')
>> >>> i, f, k, n
>> (> (id="887b0393-5065-4bcf-941d-623100baa06e", name="trusty")>,
>> ,
>> ,
>> > (id="22e3fa30-11c0-4065-bbf7-8d8bbb50f63b", name="private")>)
>>
>> Creating a server:
>> >>> s = c.server.create(name='vm1', image=i, flavor=f, networks=[n],
>> key_pair=k)
>> >>> s
>> > (id="b1477f6c-bbc4-4c37-ba05-14b935a5d08c" empty)>
>>
>> Waiting for building task finished:
>> >>> s.wait_for_finished()
>> >>> s.status
>> u'ACTIVE'
>>
>> Deleting the server:
>> >>> s.delete()
>>
>> See README for more usage and details:
>>
>>https://github.com/yosshy/python-yakumo/blob/master/README.md
>>
>> Feedback is welcome!
>>
>
It's not clear to me what is the specific use case this library aims to
cover.
Is it meant for application development or testing or both?
What are its benefit compared to openstacksdk and tempest clients?


>
>> Cheers,
>> Akira Yoshiyama
>
>
> Looks almost exactly like openstacksdk. Why duplicate that and pollute an
> already crowded space as there are already far too many existing libraries
> to work with OpenStack?
>
__
> 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] [qa][heat][murano][daisycloud] Removing Heat support from Tempest

[Andrea Frittoli]

On Tue, May 2, 2017 at 5:33 PM Matthew Treinish 
wrote:

> On Tue, May 02, 2017 at 09:49:14AM +0530, Rabi Mishra wrote:
> > On Fri, Apr 28, 2017 at 2:17 PM, Andrea Frittoli <
> andrea.fritt...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On Fri, Apr 28, 2017 at 10:29 AM Rabi Mishra 
> wrote:
> > >
> > >> On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli <
> > >> andrea.fritt...@gmail.com> wrote:
> > >>
> > >>> Dear stackers,
> > >>>
> > >>> starting in the Liberty cycle Tempest has defined a set of projects
> > >>> which are in scope for direct
> > >>> testing in Tempest [0]. The current list includes keystone, nova,
> > >>> glance, swift, cinder and neutron.
> > >>> All other projects can use the same Tempest testing infrastructure
> (or
> > >>> parts of it) by taking advantage
> > >>> the Tempest plugin and stable interfaces.
> > >>>
> > >>> Tempest currently hosts a set of API tests as well as a service
> client
> > >>> for the Heat project.
> > >>> The Heat service client is used by the tests in Tempest, which run in
> > >>> Heat gate as part of the grenade
> > >>> job, as well as in the Tempest gate (check pipeline) as part of the
> > >>> layer4 job.
> > >>> According to code search [3] the Heat service client is also used by
> > >>> Murano and Daisycore.
> > >>>
> > >>
> > >> For the heat grenade job, I've proposed two patches.
> > >>
> > >> 1. To run heat tree gabbi api tests as part of grenade 'post-upgrade'
> > >> phase
> > >>
> > >> https://review.openstack.org/#/c/460542/
> > >>
> > >> 2. To remove tempest tests from the grenade job
> > >>
> > >> https://review.openstack.org/#/c/460810/
> > >>
> > >>
> > >>
> > >>> I proposed a patch to Tempest to start the deprecation counter for
> Heat
> > >>> / orchestration related
> > >>> configuration items in Tempest [4], and I would like to make sure
> that
> > >>> all tests and the service client
> > >>> either find a new home outside of Tempest, or are removed, by the end
> > >>> the Pike cycle at the latest.
> > >>>
> > >>> Heat has in-tree integration tests and Gabbi based API tests, but I
> > >>> don't know if those provide
> > >>> enough coverage to replace the tests on Tempest side.
> > >>>
> > >>>
> > >> Yes, the heat gabbi api tests do not yet have the same coverage as the
> > >> tempest tree api tests (lacks tests using nova, neutron and swift
> > >> resources),  but I think that should not stop us from *not* running
> the
> > >> tempest tests in the grenade job.
> > >>
> > >> I also don't know if the tempest tree heat tests are used by any other
> > >> upstream/downstream jobs. We could surely add more tests to bridge
> the gap.
> > >>
> > >> Also, It's possible to run the heat integration tests (we've enough
> > >> coverage there) with tempest plugin after doing some initial setup,
> as we
> > >> do in all our dsvm gate jobs.
> > >>
> > >> It would propose to move tests and client to a Tempest plugin owned /
> > >>> maintained by
> > >>> the Heat team, so that the Heat team can have full flexibility in
> > >>> consolidating their integration
> > >>> tests. For Murano and Daisycloud - and any other team that may want
> to
> > >>> use the Heat service
> > >>> client in their tests, even if the client is removed from Tempest, it
> > >>> would still be available via
> > >>> the Heat Tempest plugin. As long as the plugin implements the service
> > >>> client interface,
> > >>> the Heat service client will register automatically in the service
> > >>> client manager and be available
> > >>> for use as today.
> > >>>
> > >>>
> > >> if I understand correctly, you're proposing moving the existing
> tempest
> > >> tests and service clients to a separate repo managed by heat team.
> Though
> > >> that would be collective decision, I'm not sure tha

Re: [openstack-dev] [qa][heat][murano][daisycloud] Removing Heat support from Tempest

[Andrea Frittoli]

On Fri, Apr 28, 2017 at 10:29 AM Rabi Mishra  wrote:

> On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli <
> andrea.fritt...@gmail.com> wrote:
>
>> Dear stackers,
>>
>> starting in the Liberty cycle Tempest has defined a set of projects which
>> are in scope for direct
>> testing in Tempest [0]. The current list includes keystone, nova, glance,
>> swift, cinder and neutron.
>> All other projects can use the same Tempest testing infrastructure (or
>> parts of it) by taking advantage
>> the Tempest plugin and stable interfaces.
>>
>> Tempest currently hosts a set of API tests as well as a service client
>> for the Heat project.
>> The Heat service client is used by the tests in Tempest, which run in
>> Heat gate as part of the grenade
>> job, as well as in the Tempest gate (check pipeline) as part of the
>> layer4 job.
>> According to code search [3] the Heat service client is also used by
>> Murano and Daisycore.
>>
>
> For the heat grenade job, I've proposed two patches.
>
> 1. To run heat tree gabbi api tests as part of grenade 'post-upgrade' phase
>
> https://review.openstack.org/#/c/460542/
>
> 2. To remove tempest tests from the grenade job
>
> https://review.openstack.org/#/c/460810/
>
>
>
>> I proposed a patch to Tempest to start the deprecation counter for Heat /
>> orchestration related
>> configuration items in Tempest [4], and I would like to make sure that
>> all tests and the service client
>> either find a new home outside of Tempest, or are removed, by the end the
>> Pike cycle at the latest.
>>
>> Heat has in-tree integration tests and Gabbi based API tests, but I don't
>> know if those provide
>> enough coverage to replace the tests on Tempest side.
>>
>>
> Yes, the heat gabbi api tests do not yet have the same coverage as the
> tempest tree api tests (lacks tests using nova, neutron and swift
> resources),  but I think that should not stop us from *not* running the
> tempest tests in the grenade job.
>
> I also don't know if the tempest tree heat tests are used by any other
> upstream/downstream jobs. We could surely add more tests to bridge the gap.
>
> Also, It's possible to run the heat integration tests (we've enough
> coverage there) with tempest plugin after doing some initial setup, as we
> do in all our dsvm gate jobs.
>
> It would propose to move tests and client to a Tempest plugin owned /
>> maintained by
>> the Heat team, so that the Heat team can have full flexibility in
>> consolidating their integration
>> tests. For Murano and Daisycloud - and any other team that may want to
>> use the Heat service
>> client in their tests, even if the client is removed from Tempest, it
>> would still be available via
>> the Heat Tempest plugin. As long as the plugin implements the service
>> client interface,
>> the Heat service client will register automatically in the service client
>> manager and be available
>> for use as today.
>>
>>
> if I understand correctly, you're proposing moving the existing tempest
> tests and service clients to a separate repo managed by heat team. Though
> that would be collective decision, I'm not sure that's something I would
> like to do. To start with we may look at adding some of the missing pieces
> in heat tree itself.
>

I'm proposing to move tests and the service client outside of tempest to a
new home.

I also suggested that the new home could be a dedicate repo, since that
would allow you to maintain the
current branchless nature of those tests. A more detailed discussion about
the topic can be found
in the corresponding proposed queens goal [5],

Using a dedicated repo *is not* a precondition for moving tests and service
client out of Tempest.

andrea

[5] https://review.openstack.org/#/c/369749/


>
> Andrea Frittoli (andreaf)
>>
>> [0]
>> https://docs.openstack.org/developer/tempest/test_removal.html#tempest-scope
>> [1] https://docs.openstack.org/developer/tempest/plugin.html
>> [2] https://docs.openstack.org/developer/tempest/library.html
>> [3]
>> http://codesearch.openstack.org/?q=self.orchestration_client&i=nope&files=&repos=
>>
>> [4] https://review.openstack.org/#/c/456843/
>>
>> __
>> 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
>>
>>
>
>
> --
&g