Re: [openstack-dev] [rpm-packaging] Step down as a reviewer

[Javier Pena]

- Original Message -
> Dear rpm-packaging team,
> 
> I was lucky to help doing reviews for the rpm-packaging OpenStack
> project for the last couple of release cycles. I learned a lot during
> this time.
> 
> I will change my role at SUSE at the end of the month (August 2018), so
> I request to be removed from the core position on those projects.
> 
> Also, a big thank to the team for the provided help during this time.
> 

Alberto, thank you very much for your contributions. I wish you the best in 
your new position.

Regards,
Javier

> Saludos!
> 
> --
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
> Maxfeldstraße 5, 90409 Nürnberg, Germany
> 
> 
> __
> 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][election][tc] Lederless projects.

[Javier Pena]

- Original Message -
> On Wed, Aug 01, 2018 at 09:55:13AM +1000, Tony Breeds wrote:
> > 
> > Hello all,
> > The PTL Nomination period is now over. The official candidate list
> > is available on the election website[0].
> > 
> > There are 8 projects without candidates, so according to this
> > resolution[1], the TC will have to decide how the following
> > projects will proceed: Dragonflow, Freezer, Loci, Packaging_Rpm,

The Packaging RPM team had our weekly meeting yesterday. We are sorry for the 
inconveniences, caused by some miscommunication on our side.

We decided to propose Dirk Mueller as PTL for TC appointment for the Stein 
cycle [1], and we will make an effort to avoid this situation in the future.

Thanks,
Javier

[1] - 
http://eavesdrop.openstack.org/meetings/rpm_packaging/2018/rpm_packaging.2018-08-01-13.01.log.html#l-44

> > RefStack, Searchlight, Trove and Winstackers.
> 
> Hello TC,
> A few extra details[1]:
> 
> ---
> Projects[1]   :65
> Projects with candidates  :57 ( 87.69%)
> Projects with election: 2 (  3.08%)
> ---
> Need election : 2 (Senlin Tacker)
> Need appointment  : 8 (Dragonflow Freezer Loci Packaging_Rpm RefStack
>Searchlight Trove Winstackers)
> ===
> Stats gathered@ 2018-08-01 00:11:59 UTC
> 
> Of the 8 projects that can be considered leaderless, Trove did have a
> candidate[2] that doesn't meet the ATC criteria in that they do not
> have a merged change.
> 
> I also excluded Security due to the governance review[3] to remove it as
> a project and the companion email discussion[4]
> 
> Yours Tony.
> 
> [1] http://paste.openstack.org/show/727002
> [2] https://review.openstack.org/587333
> [3] https://review.openstack.org/586896
> [4] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132595.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

[openstack-dev] [packaging-rpm] PTL on vacation

[Javier Pena]

Hi,

I will be on vacation between July 9th and July 27th, without much e-mail 
access depending on the specific day. Jakub Ruzicka (jruzicka) will be my 
deputy during that time.

Regards,
Javier

__
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] [requirements][barbican][daisycloud][freezer][fuel][heat][pyghmi][rpm-packaging][solum][tatu][trove] pycrypto is dead and insecure, you should migrate

[Javier Pena]

- Original Message -
> This is a reminder to the projects called out that they are using old,
> unmaintained and probably insecure libraries (it's been dead since
> 2014).  Please migrate off to use the cryptography library.  We'd like
> to drop pycrypto from requirements for rocky.
> 
> See also, the bug, which has most of you cc'd already.
> 
> https://bugs.launchpad.net/openstack-requirements/+bug/1749574
> 

In the rpm-packaging case, the requirements.txt file is not actually a list of 
requirements for the project, but a copy of the requirements project 
upper-constraints.txt file (a bit outdated now).

Regards,
Javier


> ++-+--+---+
> | Repository | Filename
> | | Line | Text
> | |
> ++-+--+---+
> | barbican   | requirements.txt
> | |   25 | pycrypto>=2.6
> | # Public Domain |
> | daisycloud-core| code/daisy/requirements.txt
> | |   17 | pycrypto>=2.6 # Public
> | Domain |
> | freezer| requirements.txt
> | |   21 | pycrypto>=2.6
> | # Public Domain |
> | fuel-web   | nailgun/requirements.txt
> | |   24 | pycrypto>=2.6.1
> | |
> | heat-cfnclient | requirements.txt
> | |2 |
> | PyCrypto>=2.1.0   |
> | pyghmi | requirements.txt
> | |1 | pycrypto>=2.6
> | |
> | rpm-packaging  | requirements.txt
> | |  189 | pycrypto>=2.6
> | # Public Domain|
> | solum  | requirements.txt
> | |   24 | pycrypto>=2.6
> | # Public Domain |
> | tatu   | requirements.txt
> | |7 |
> | pycrypto>=2.6.1   |
> | tatu   | test-requirements.txt
> | |7 | pycrypto>=2.6.1
> | |
> | trove  |
> | integration/scripts/files/requirements/fedora-requirements.txt  |   30
> | | pycrypto>=2.6  # Public Domain|
> | trove  |
> | integration/scripts/files/requirements/ubuntu-requirements.txt  |   29
> | | pycrypto>=2.6  # Public Domain|
> | trove  | requirements.txt
> | |   47 | pycrypto>=2.6
> | # Public Domain |
> ++-+--+---+
> 
> --
> Matthew Thode (prometheanfire)
> 
> __
> 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] [tripleo] Upcoming changes to DLRN might affect TripleO

[Javier Pena]

Hi,

We are working on some changes to DLRN, which will improve its flexibility and 
ability to build packages using different backends [1]. While we try to make 
these changes backwards-compatible, we have detected an issue with existing CI 
jobs for TripleO.

Both tripleo-ci and oooq-extras change the build_rpm.sh script from DLRN, and 
that change will no longer be required (and actually the sed command that tries 
that will fail). I have proposed patches to both tripleo-ci and oooq-extras 
[2], which allow compatibility with the current and future DLRN.

Would it be possible to get some reviews on these patches? We need that 
functionality in DLRN and want to avoid breaking the TripleO gate.

Thanks,
Javier

[1] - 
https://softwarefactory-project.io/r/#/q/status:open+project:DLRN+branch:master+topic:modular-build-drivers
[2] - https://review.openstack.org/#/q/topic:dlrn-modular-build-drivers

__
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] [packaging-rpm][meeting] Proposal for new meeting time

[Javier Pena]

Hello fellow packagers,

During today's meeting [1], we discussed the schedule conflicts some of us have 
with the current meeting slot. As a result, I would like to propose a new 
meeting time:

- Wednesdays, 1 PM UTC (3 PM CEST)

So far, dirk and jruzicka agreed with the change. If you have an issue, please 
reply now.

Regards,
Javier Peña

__
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] PTG session about All-In-One installer: recap & roadmap

[Javier Pena]

- Original Message -
> On Tue, Apr 3, 2018 at 10:00 AM, Javier Pena <jp...@redhat.com> wrote:
> >
> >> Greeting folks,
> >>
> >> During the last PTG we spent time discussing some ideas around an
> >> All-In-One
> >> installer, using 100% of the TripleO bits to deploy a single node
> >> OpenStack
> >> very similar with what we have today with the containerized undercloud and
> >> what we also have with other tools like Packstack or Devstack.
> >>
> >> https://etherpad.openstack.org/p/tripleo-rocky-all-in-one
> >>
> >
> > I'm really +1 to this. And as a Packstack developer, I'd love to see this
> > as a
> > mid-term Packstack replacement. So let's dive into the details.
> 
> Curious on this one actually, do you see a need for continued
> baremetal support? Today we support both baremetal and containers.
> Perhaps "support" is a strong word. We support both in terms of
> installation but only containers now have fully supported upgrades.
> 
> The interfaces we have today still support baremetal and containers
> but there were some suggestions about getting rid of baremetal support
> and only having containers. If we were to remove baremetal support
> though, Could we keep the Packstack case intact by just using
> containers instead?

I don't have a strong opinion on this. As long as we can update containers with 
under-review packages, I guess we should be ok. That said, I still think some 
kind of baremetal support is a good idea to catch co-installability issues, if 
it is not very expensive to mantain.

Regards,
Javier

> 
> Dan
> 
> >
> >> One of the problems that we're trying to solve here is to give a simple
> >> tool
> >> for developers so they can both easily and quickly deploy an OpenStack for
> >> their needs.
> >>
> >> "As a developer, I need to deploy OpenStack in a VM on my laptop, quickly
> >> and
> >> without complexity, reproducing the same exact same tooling as TripleO is
> >> using."
> >> "As a Neutron developer, I need to develop a feature in Neutron and test
> >> it
> >> with TripleO in my local env."
> >> "As a TripleO dev, I need to implement a new service and test its
> >> deployment
> >> in my local env."
> >> "As a developer, I need to reproduce a bug in TripleO CI that blocks the
> >> production chain, quickly and simply."
> >>
> >
> > "As a packager, I want an easy/low overhead way to test updated packages
> > with TripleO bits, so I can make sure they will not break any automation".
> >
> >> Probably more use cases, but to me that's what came into my mind now.
> >>
> >> Dan kicked-off a doc patch a month ago:
> >> https://review.openstack.org/#/c/547038/
> >> And I just went ahead and proposed a blueprint:
> >> https://blueprints.launchpad.net/tripleo/+spec/all-in-one
> >> So hopefully we can start prototyping something during Rocky.
> >>
> >> Before talking about the actual implementation, I would like to gather
> >> feedback from people interested by the use-cases. If you recognize
> >> yourself
> >> in these use-cases and you're not using TripleO today to test your things
> >> because it's too complex to deploy, we want to hear from you.
> >> I want to see feedback (positive or negative) about this idea. We need to
> >> gather ideas, use cases, needs, before we go design a prototype in Rocky.
> >>
> >
> > I would like to offer help with initial testing once there is something in
> > the repos, so count me in!
> >
> > Regards,
> > Javier
> >
> >> Thanks everyone who'll be involved,
> >> --
> >> Emilien Macchi
> >>
> >> __
> >> 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

Re: [openstack-dev] [tripleo] PTG session about All-In-One installer: recap & roadmap

[Javier Pena]

- Original Message -

> On Tue, 3 Apr 2018 at 10:00 Javier Pena < jp...@redhat.com > wrote:

> > > Greeting folks,
> 
> > >
> 
> > > During the last PTG we spent time discussing some ideas around an
> > > All-In-One
> 
> > > installer, using 100% of the TripleO bits to deploy a single node
> > > OpenStack
> 
> > > very similar with what we have today with the containerized undercloud
> > > and
> 
> > > what we also have with other tools like Packstack or Devstack.
> 
> > >
> 
> > > https://etherpad.openstack.org/p/tripleo-rocky-all-in-one
> 
> > >
> 

> > I'm really +1 to this. And as a Packstack developer, I'd love to see this
> > as
> > a
> 
> > mid-term Packstack replacement. So let's dive into the details.
> 

> > > One of the problems that we're trying to solve here is to give a simple
> > > tool
> 
> > > for developers so they can both easily and quickly deploy an OpenStack
> > > for
> 
> > > their needs.
> 
> > >
> 
> > > "As a developer, I need to deploy OpenStack in a VM on my laptop, quickly
> > > and
> 
> > > without complexity, reproducing the same exact same tooling as TripleO is
> 
> > > using."
> 
> > > "As a Neutron developer, I need to develop a feature in Neutron and test
> > > it
> 
> > > with TripleO in my local env."
> 
> > > "As a TripleO dev, I need to implement a new service and test its
> > > deployment
> 
> > > in my local env."
> 
> > > "As a developer, I need to reproduce a bug in TripleO CI that blocks the
> 
> > > production chain, quickly and simply."
> 
> > >
> 

> > "As a packager, I want an easy/low overhead way to test updated packages
> > with
> > TripleO bits, so I can make sure they will not break any automation".
> 

> I suspect we need to not only update packages, but also update containers,
> wdyt?

I'm being implementation-agnostic in my requirement on purpose :). It could be 
either a new container including the updates, or updating the existing 
container with the new packages. 

> > > Probably more use cases, but to me that's what came into my mind now.
> 
> > >
> 
> > > Dan kicked-off a doc patch a month ago:
> 
> > > https://review.openstack.org/#/c/547038/
> 
> > > And I just went ahead and proposed a blueprint:
> 
> > > https://blueprints.launchpad.net/tripleo/+spec/all-in-one
> 
> > > So hopefully we can start prototyping something during Rocky.
> 
> > >
> 
> > > Before talking about the actual implementation, I would like to gather
> 
> > > feedback from people interested by the use-cases. If you recognize
> > > yourself
> 
> > > in these use-cases and you're not using TripleO today to test your things
> 
> > > because it's too complex to deploy, we want to hear from you.
> 
> > > I want to see feedback (positive or negative) about this idea. We need to
> 
> > > gather ideas, use cases, needs, before we go design a prototype in Rocky.
> 
> > >
> 

> > I would like to offer help with initial testing once there is something in
> > the repos, so count me in!
> 

> > Regards,
> 
> > Javier
> 

> > > Thanks everyone who'll be involved,
> 
> > > --
> 
> > > Emilien Macchi
> 
> > >
> 
> > > __
> 
> > > 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

Re: [openstack-dev] [tripleo] PTG session about All-In-One installer: recap & roadmap

[Javier Pena]

> Greeting folks,
>
> During the last PTG we spent time discussing some ideas around an All-In-One
> installer, using 100% of the TripleO bits to deploy a single node OpenStack
> very similar with what we have today with the containerized undercloud and
> what we also have with other tools like Packstack or Devstack.
>
> https://etherpad.openstack.org/p/tripleo-rocky-all-in-one
>

I'm really +1 to this. And as a Packstack developer, I'd love to see this as a
mid-term Packstack replacement. So let's dive into the details.

> One of the problems that we're trying to solve here is to give a simple tool
> for developers so they can both easily and quickly deploy an OpenStack for
> their needs.
>
> "As a developer, I need to deploy OpenStack in a VM on my laptop, quickly and
> without complexity, reproducing the same exact same tooling as TripleO is
> using."
> "As a Neutron developer, I need to develop a feature in Neutron and test it
> with TripleO in my local env."
> "As a TripleO dev, I need to implement a new service and test its deployment
> in my local env."
> "As a developer, I need to reproduce a bug in TripleO CI that blocks the
> production chain, quickly and simply."
>

"As a packager, I want an easy/low overhead way to test updated packages with 
TripleO bits, so I can make sure they will not break any automation".

> Probably more use cases, but to me that's what came into my mind now.
>
> Dan kicked-off a doc patch a month ago:
> https://review.openstack.org/#/c/547038/
> And I just went ahead and proposed a blueprint:
> https://blueprints.launchpad.net/tripleo/+spec/all-in-one
> So hopefully we can start prototyping something during Rocky.
>
> Before talking about the actual implementation, I would like to gather
> feedback from people interested by the use-cases. If you recognize yourself
> in these use-cases and you're not using TripleO today to test your things
> because it's too complex to deploy, we want to hear from you.
> I want to see feedback (positive or negative) about this idea. We need to
> gather ideas, use cases, needs, before we go design a prototype in Rocky.
>

I would like to offer help with initial testing once there is something in the 
repos, so count me in!

Regards,
Javier

> Thanks everyone who'll be involved,
> --
> Emilien Macchi
>
> __
> 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] [tripleo] Recap of Python 3 testing session at PTG

[Javier Pena]

- Original Message -

> During the PTG we had some nice conversations about how TripleO can make
> progress on testing OpenStack deployments with Python 3.
> In CC, Haikel, Alfredo and Javier, please complete if I missed something.

> ## Goal

> As an OpenStack distribution, RDO would like to ensure that the OpenStack
> services (which aren't depending on Python 2) are packaged and can be
> containerized to be tested in TripleO CI.

> ## Challenges

> - Some services aren't fully Python 3, but we agreed this was not our problem
> but the project's problems. However, as a distribution, we'll make sure to
> ship what we can on Python 3.
> - CentOS 7 is not the Python 3 distro and there are high expectations from
> the next release but we aren't there yet.
> - Fedora is Python 3 friendly but we don't deploy TripleO on Fedora, and we
> don't want to do it (for now at least).

> ## Proposal

> - Continue to follow upstream projects who support Python3 only and ship rpms
> in RDO.
> - Investigate the build of Kolla containers on Fedora / Python 3 and push
> them to a registry (maybe in the same namespace with different name or maybe
> a new namespace).
> - Kick-off some TripleO CI experimental job that will use these containers to
> deploy TripleO (maybe on one basic scenario for now).

One point we should add here: to test Python 3 we need some base operating 
system to work on. For now, our plan is to create a set of stabilized Fedora 28 
repositories and use them only for CI jobs. See [1] for details on this plan. 

Regards, 
Javier 

[1] - 
https://etherpad.openstack.org/p/stabilized-fedora-repositories-for-openstack 

> ## Roadmap for Rocky

> For Rocky we agreed to follow the 3 steps part of the proposal (maybe more,
> please add what I've missed).
> That way, we'll be able to have some early testing on python3-only
> environments (thanks containers!) without changing the host OS.

> Thanks for your feedback and comments, it's an open discussion.
> --
> Emilien Macchi
__
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] [packaging-rpm] PTL candidacy

[Javier Pena]

Hello fellow packagers!

I would like to announce my candidacy to be the PTL for the Packaging Rpm
project during the Rocky development cycle.

During the last cycles, the project has become a great collaboration space for
people working on RPM packages for OpenStack products. We have a number of
great tools that help us in different areas, even beyond the boundaries of
RPM-based distributions [1], and a wide, up-to-date package set.

For the Rocky cycle, my focus would be on:

* Fixing 3rd party CI annoyances: we are often getting hit by known issues in
  the 3rd party CI systems. Let's try to work on those known issues and reduce
  their occurrence to a minimum, so we can spend more time on reviews and less
  time troubleshooting our CI.

* Work on getting the packages created by the project tested by some installer
  project. This would greatly help us in improving quality on those small
  details that only get caught during real life tests.

* Expanding OpenStack distribution usage of the artifacts generated by the
  Packaging Rpm project.

That, of course, would be in addition to our common goals: expanding our
contributor base, improving collaboration between RPM distributions, and
keeping a high quality set of packages.

Thanks for reading,
Javier

[1] - 
https://github.com/openstack/pymod2pkg/blob/master/pymod2pkg/__init__.py#L294-L316

__
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] Ocata to Pike upgrade job is working as of today.

[Javier Pena]

- Original Message -
> Hi,
> 
> So join us (upgrade squad) to celebrate the working ocata->pike upgrade
> job[1], without any depends-on whatsoever.
> 
> We would like it to be voting as soon as possible. It has been a
> rather consuming task to revive that forgotten but important jobs, and
> the only way for it to not drift into oblivion again is to have it
> voting.
> 

I see the job is actually voting (it should have a -nv suffix to be non-voting).

Regards,
Javier

> Eventually, let’s thanks rdo-cloud people for their support (especially
> David Manchado), James Slagle for Traas[2] and Alfredo Moralejo for his
> constant availability to answer our questions.
> 
> Thanks,
> 
> [1] https://review.openstack.org/#/c/532791/, look for
> «gate-tripleo-ci-centos-7-containers-multinode-upgrades-pike»
> [2] https://github.com/slagle/traas … the repo we use ->
> https://github.com/sathlan/traas (so many pull requests to make that it
> would be cool for it to be an openstack project … :))
> --
> Sofer Athlan
> 
> __
> 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] [rdo-list] [tripleo][quickstart][rdo] shipping python-virtualbmc in Newton to allow undercloud upgrades from Newton to Queens

[Javier Pena]

> Adding rdo-list in an attempt to get more feeback regarding this
> proposal, tl;dr can we ship python-virtualbmc in Newton?
> 

Given the background, I think it's reasonable to add it to Newton, even though 
it is close to EOL.

Could you open a review to rdoinfo and add the required tag after 
https://github.com/redhat-openstack/rdoinfo/blob/master/rdo.yml#L4736-L4737 ? 
We could iron out any details in the review.

Regards,
Javier

> On 04-10-17 12:08:25, Lee Yarwood wrote:
> > Hello all,
> > 
> > I'm currently working to get the tripleo-spec for fast-forward upgrades
> > out of WIP and merged ahead of the Queens M-1 milestone next week. One
> > of the documented pre-requisite steps for fast-forward upgrades is for
> > an operator to linearly upgrade the undercloud from Newton (N) to Queens
> > (N+3):
> > 
> > https://review.openstack.org/#/c/497257/
> > 
> > This is not possible at present with tripleo-quickstart deployed virtual
> > environments thanks to our use of the pxe_ssh Ironic driver in Newton
> > that has now been removed in Pike:
> > 
> > https://docs.openstack.org/releasenotes/ironic/pike.html#id14
> > 
> > I briefly looked into migrating between pxe_ssh and the new default of
> > vbmc during the Ocata to Pike undercloud upgrade but I'd much rather
> > just deploy Newton using vbmc. AFAICT the only issue here is packaging
> > with the python-virtualbmc package not present in the Newton repos.
> > 
> > With that in mind I've submitted the following changes that remove the
> > various conditionals in tripleo-quickstart that block the use of vbmc in
> > Newton and verified that this works by using the Ocata python-virtualbmc
> > package:
> > 
> > https://review.openstack.org/#/q/topic:allow_vbmc_newton+(status:open+OR+status:merged)
> > 
> > FWIW I can deploy successfully on Newton with these changes and then
> > upgrade the undercloud to Pike just fine.
> > 
> > Would anyone be able to confirm *if* we could ship python-virtualbmc in
> > the Newton relevant repos?
> > 
> > Thanks in advance,
> > 
> > Lee
> --
> Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672
> 2D76
> 
> ___
> rdo-list mailing list
> rdo-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscr...@redhat.com

__
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] [rdo-list] [rdo][tripleo][kolla] Routine patch maintenance on trunk.rdoproject.org, Tue Oct 3rd

[Javier Pena]

> Hi,
> 
> We need to do some routine patching on trunk.rdoproject.org on Oct 3rd, at
> 8:00 UTC. There will be a brief downtime for a reboot, where jobs using
> packages from RDO Trunk can fail. Sorry for the inconveniences.
> 

Hi,

The maintenance is now complete. Everything should be back to normal, please 
contact us if you find any issue.

Regards,
Javier

> If you need additional information, please do not hesitate to contact us.
> 
> Regards,
> Javier
> 

__
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] [rdo][tripleo][kolla] Routine patch maintenance on trunk.rdoproject.org, Tue Oct 3rd

[Javier Pena]

Hi,

We need to do some routine patching on trunk.rdoproject.org on Oct 3rd, at 8:00 
UTC. There will be a brief downtime for a reboot, where jobs using packages 
from RDO Trunk can fail. Sorry for the inconveniences.

If you need additional information, please do not hesitate to contact us.

Regards,
Javier

__
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][kolla][puppet] DLRN maintenance on June 29, 8:00 AM UTC

[Javier Pena]

The DLRN server maintenance has been completed. If you had any issue in a CI 
job, you can recheck now.

Please contact me if you find any trouble accessing the RDO Trunk repos.

Regards,
Javier

- Original Message -
> This is also of interest for CI jobs in TripleO, kolla and
> puppet-openstack-integration.
> 
> Javier
> 
> - Forwarded Message -
> Hi,
> 
> We need to run some maintenance activities on the DLRN public instance on
> June 29, starting at 8:00 UTC time (10:00 CET). As a result, the
> repositories hosted by trunk.rdoproject.org will be intermittently
> unavailable. The maintenance is expected to last 1 hour.
> 
> Regards,
> Javier
> 
> ___
> rdo-list mailing list
> rdo-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscr...@redhat.com
> 

__
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] [tripleo][kolla][puppet] DLRN maintenance on June 29, 8:00 AM UTC

[Javier Pena]

This is also of interest for CI jobs in TripleO, kolla and 
puppet-openstack-integration.

Javier

- Forwarded Message -
Hi,

We need to run some maintenance activities on the DLRN public instance on June 
29, starting at 8:00 UTC time (10:00 CET). As a result, the repositories hosted 
by trunk.rdoproject.org will be intermittently unavailable. The maintenance is 
expected to last 1 hour.

Regards,
Javier

___
rdo-list mailing list
rdo-l...@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list

To unsubscribe: rdo-list-unsubscr...@redhat.com

__
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][ci] tripleo periodic jobs moving to RDO's software factory and RDO Cloud

[Javier Pena]

- Original Message -
> On Mon, Jun 12, 2017 at 05:01:26PM -0400, Wesley Hayutin wrote:
> > Greetings,
> > 
> > I wanted to send out a summary email regarding some work that is still
> > developing and being planned to give interested parties time to comment and
> > prepare for change.
> > 
> > Project:
> > Move tripleo periodic promotion jobs
> > 
> > Goal:
> > Increase the cadence of tripleo-ci periodic promotion jobs in a way
> > that does not impact upstream OpenStack zuul queues and infrastructure.
> > 
> > Next Steps:
> > The dependencies in RDO's instance of software factory are now complete
> > and we should be able to create a new a net new zuul queue in RDO infra for
> > tripleo-periodic jobs.  These jobs will have to run both multinode nodepool
> > and ovb style jobs and utilize RDO-Cloud as the host cloud provider.  The
> > TripleO CI team is looking into moving the TripleO periodic jobs running
> > upstream to run from RDO's software factory instance. This move will allow
> > the CI team more flexibility in managing the periodic jobs and resources to
> > run the jobs more frequently.
> > 
> > TLDR:
> > There is no set date as to when the periodic jobs will move. The move
> > will depend on tenant resource allocation and how easily the periodic jobs
> > can be modified.  This email is to inform the group that changes are being
> > planned to the tripleo periodic workflow and allow time for comment and
> > preparation.
> > 
> > Completed Background Work:
> > After long discussion with Paul Belanger about increasing the cadence
> > of the promotion jobs [1]. Paul explained infa's position and if he doesn't
> > -1/-2 a new pipeline that has the same priority as check jobs someone else
> > will. To summarize the point, the new pipeline would compete and slow down
> > non-tripleo projects in the gate even when the hardware resources are our
> > own.
> > To avoid slowing down non-tripleo projects Paul has volunteered to help
> > setup the infrastructure in rdoproject to manage the queue ( zuul etc). We
> > would still use rh-openstack-1 / rdocloud for ovb, and could also trigger
> > multinode nodepool jobs.
> > There is one hitch though, currently, rdo-project does not have all the
> > pieces of the puzzle in place to move off of openstack zuul and onto
> > rdoproject zuul. Paul mentioned that nodepool-builder [2] is a hard
> > requirement to be setup in rdoproject before we can proceed here. He
> > mentioned working with the software factory guys to get this setup and
> > running.
> > At this time, I think this issue is blocked until further discussion.
> > [1] https://review.openstack.org/#/c/443964/
> > [2]
> > https://github.com/openstack-infra/nodepool/blob/master/nodepool/builder.py
> > 
> > Thanks
> 
> The first step is landing the nodepool elements in nodepool.rdoproject.org,
> and
> building a centos-7 DIB.  I believe number80 is currently working on this and
> hopefully that could be landed in the next day or so.  Once images have been
> built, it won't be much work to then run a job. RDO already has 3rdparty jobs
> running, we'd to the same with tripleo-ci.
> 

I'm familiar with the 3rd party CI setup in review.rdoproject.org, since I 
maintain it for the rpm-packaging project. Please feel free to ping me if you 
need any help with the setup.

Javier

> 
> __
> 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] [release][keystone] Can we get a new python-keystoneclient release?

[Javier Pena]

Hi,

The latest python-keystoneclient release (3.10.0) dates back to Ocata, and it 
can't be properly packaged in Pike because it fails to run unit tests, since 
[1] is required.

Can we get a new release?

Thanks,
Javier

[1] - 
https://github.com/openstack/python-keystoneclient/commit/cfd33730868350cd475e45569a8c1573803a6895

__
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] [gnocchi] Moving python-gnocchiclient to GitHub

[Javier Pena]

- Original Message -
> On Tue, Apr 25 2017, Julien Danjou wrote:
> 
> > We're in the process of moving python-gnocchiclient to GitHub. The
> > patches are up for review:
> >
> >   https://review.openstack.org/#/c/459748/
> >
> > and its dependencies need to be merged before this happen. As soon as
> > this patch is merged, the repository will officially be available at:
> >
> >   https://github.com/gnocchixyz/python-gnocchiclient
> 
> This happened! The repository has now been moved to GitHub. I've also
> created copies of the existing opened bugs there so we don't lose that
> data.
> 
> If I missed anything, let me know.
> 

Hi Julien,

I see none of the tags or branches have been moved over, could they be copied? 
It would of great help to packagers.

Thanks,
Javier

> --
> Julien Danjou
> ;; Free Software hacker
> ;; https://julien.danjou.info
> 
> __
> 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] [DLRN][tripleo][kolla][puppet] trunk.rdoproject.org maintenance on Thu 30 Mar, 9:00 UTC

[Javier Pena]

> FYI, trunk.rdo maintenance will affect CI jobs tomorrow.
> 

Hi,

The maintenance has been completed, and trunk.rdoproject.org is serving 
packages as usual.

Please do not hesitate to contact us if you find any issue.

Regards,
Javier

> - Forwarded Message -
> Hi,
> 
> We need to do some maintenance patching in trunk.rdoproject.org. The expected
> downtime is 1 hour, and during the reboot you will see errors in CI jobs
> that fetch packages from it.
> 
> I will send a follow-up e-mail once the maintenance window is finished.
> 
> Regards,
> Javier
> 
> ___
> rdo-list mailing list
> rdo-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscr...@redhat.com
> 
> __
> 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] [DLRN][tripleo][kolla][puppet] trunk.rdoproject.org maintenance on Thu 30 Mar, 9:00 UTC

[Javier Pena]

FYI, trunk.rdo maintenance will affect CI jobs tomorrow.

- Forwarded Message -
Hi,

We need to do some maintenance patching in trunk.rdoproject.org. The expected 
downtime is 1 hour, and during the reboot you will see errors in CI jobs that 
fetch packages from it.

I will send a follow-up e-mail once the maintenance window is finished.

Regards,
Javier

___
rdo-list mailing list
rdo-l...@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list

To unsubscribe: rdo-list-unsubscr...@redhat.com

__
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] [release] RDO Ocata packages released

[Javier Pena]

The RDO community is pleased to announce the general availability of the RDO 
build for OpenStack Ocata for RPM-based distributions, CentOS Linux 7 and Red 
Hat Enterprise Linux.
RDO is suitable for building private, public, and hybrid clouds. Ocata is the 
15th release from the OpenStack project (http://openstack.org), which is the 
work of more than 2500 contributors from around the world (source 
http://stackalytics.com/).

The RDO community project (https://www.rdoproject.org/) curates, packages, 
builds, tests and maintains a complete OpenStack component set for RHEL and 
CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG 
(https://wiki.centos.org/SpecialInterestGroup/Cloud). The Cloud Infrastructure 
SIG focuses on delivering a great user experience for CentOS Linux users 
looking to build and maintain their own on-premise, public or hybrid clouds.

All work on RDO, and on the downstream release, Red Hat OpenStack Platform, is 
100% open source, with all code changes going upstream first.

Interesting things in the Ocata release include:

- Significant Improvements 
(https://www.rdoproject.org/blog/2017/02/testing-rdo-with-tempest-new-features-in-ocata/)
 to Tempest and Tempest plugin packaging in RDO
- The OpenStack-Ansible 
(https://docs.openstack.org/releasenotes/openstack-ansible/ocata.html#new-features)
 project now supports deployment on top of CentOS with the help of RDO-packaged 
dependencies

For cloud operators, RDO now provides packages for some new OpenStack Services:

- Tacker (https://docs.openstack.org/developer/tacker/): an ETSI MANO NFV 
Orchestrator and VNF Manager
- Congress 
(https://docs.openstack.org/developer/congress/architecture.html): an open 
policy framework for the cloud
- Vitrage (https://docs.openstack.org/developer/vitrage/): the OpenStack 
RCA (Root Cause Analysis) Service
- Kolla (https://github.com/openstack/kolla): The Kolla project provides 
tooling to build production-ready container images for deploying OpenStack 
clouds

Some other notable additions:

- novajoin (https://github.com/openstack/novajoin): a dynamic vendordata 
plugin for the OpenStack nova metadata service to manage automatic host 
instantiation in an IPA server
- ironic-ui (https://docs.openstack.org/developer/ironic-ui/): a new 
Horizon plugin to view and manage baremetal servers
- python-virtualbmc (https://github.com/openstack/virtualbmc) VirtualBMC is 
a proxy that translates IPMI commands to libvirt calls. This allows projects 
such as OpenStack Ironic to test IPMI drivers using VMs.
- python-muranoclient (https://github.com/openstack/python-muranoclient): a 
client for the Application Catalog service.
- python-monascaclient (https://github.com/openstack/python-monascaclient): 
a client for the Monasca monitoring-as-a-service solution.
- Shaker (http://pyshaker.readthedocs.io/en/latest/): the distributed 
data-plane testing tool built for OpenStack
- Multi-architecture support: aarch64 builds are now provided through an 
experimental repository - enable the RDO 'testing' repositories to get started

>From a networking perspective, we have added some new Neutron plugins that can 
>help Cloud users and operators to address new use cases and scenarios:

- networking-bagpipe 
(https://docs.openstack.org/developer/networking-bagpipe/): a mechanism driver 
for Neutron ML2 plugin using BGP E-VPNs/IP VPNs as a backend
- networking-bgpvpn 
(https://docs.openstack.org/developer/networking-bgpvpn/): an API and framework 
to interconnect BGP/MPLS VPNs to Openstack Neutron networks
- networking-fujitsu (https://github.com/openstack/networking-fujitsu): 
FUJITSU ML2 plugins/drivers for OpenStack Neutron
- networking-l2gw (https://github.com/openstack/networking-l2gw): APIs and 
implementations to support L2 Gateways in Neutron
- networking-sfc (https://github.com/openstack/networking-sfc): APIs and 
implementations to support Service Function Chaining in Neutron

>From the Packstack (https://github.com/openstack/packstack) side, we have 
>several improvements:

- We have added support to install Panko and Magnum
- Puppet 4 is now supported, and we have updated our manifests to cover the 
latest changes in the supported projects

**Getting Started**

There are three ways to get started with RDO.

- To spin up a proof of concept cloud, quickly, and on limited hardware, 
try the All-In-One Quickstart (http://rdoproject.org/Quickstart). You can run 
RDO on a single node to get a feel for how it works.
- For a production deployment of RDO, use the TripleO Quickstart 
(https://www.rdoproject.org/tripleo/) and you'll be running a production cloud 
in short order.
- Finally, if you want to try out OpenStack, but don't have the time or 
hardware to run it yourself, visit TryStack (http://trystack.org/), where you 
can use a free public OpenStack instance, running RDO packages, to experiment 
with the 

Re: [openstack-dev] [Packaging-RPM] Nominating Alberto Planas Dominguez for Packaging-RPM core

[Javier Pena]

> +1
> 
> Welcome Alberto!
> 

+1 for me. Good reviews so far, it'll be great to have him as core.

Javier

> 
> On Thu, 2017-02-16 at 17:43 +0300, Igor Yozhikov wrote:
> > Hello team.
> > I want to announce the following changes to Packaging-RPM core team:
> > I’d like to nominate Alberto Planas Dominguez known as aplanas on irc
> > for Packaging-RPM core.
> > Alberto done a lot of reviews for as for project modules [1],[2] as
> > for rest of OpenStack components [3]. His experience within OpenStack
> > components and packaging are very appreciated.
> > 
> > 
> > [1] http://stackalytics.com/?metric=marks_type=all=pac
> > kaging-rpm-group_id=aplanas
> > [2] http://stackalytics.com/?metric=marks_type=all=pac
> > kaging-rpm-group
> > [3] http://stackalytics.com/?user_id=aplanas=marks
> > 
> > Packaging-RPM team please respond with +1/-1 to the proposed changes.
> > 
> > Thanks,
> > Igor Yozhikov
> > Senior Deployment Engineer
> > at Mirantis
> > skype: igor.yozhikov
> > cellular: +7 901 5331200
> > slack: iyozhikov
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > cribe
> > 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] [tripleo][puppet] Preparations for Ocata release in RDO

[Javier Pena]

> Hi,
> 
> In RDO we are preparing for the incoming Ocata release. This means
> we'll create a new RDO Trunk builder "centos-ocata" in the next few
> days (It will be ready for next week). This builder will get content
> from stable/ocata branches of projects as they become available and
> fallback to master for those not branched yet. The repos created by
> this worker will be published under
> https://trunk.rdoproject.org/centos7-ocata/ (which will not longer be
> a link to https://trunk.rdoproject.org/centos7-master/).
> 

Hi all,

The centos-ocata builder has been successfully bootstrapped, and its 
repositories are available at https://trunk.rdoproject.org/centos7-ocata/

Regards,
Javier

> According to the feedback received during the last release cycle, we
> are changing the way we do the transition this time so that
> repositories content will be more accurate to what is expected at any
> point in the cycle. Repos under centos-master will allways follow
> master branch and centos-ocata will get stable/ocata as soon as repos
> get the branch created.
> 
> This has some implications from the upstream projects point of view:
> 
> - Projects using repositories under
> https://trunk.rdoproject.org/centos7-ocata/ will start getting
> packages for content delivered in stable/ocata branches instead of
> master. Repos in https://trunk.rdoproject.org/centos7-master/ will
> keep getting packages for content in master branch.
> - Anyone currently pinning to a specific hash repo under
> https://trunk.rdoproject.org/centos7-ocata/ should move it to use
> https://trunk.rdoproject.org/centos7-master/ as soon as possible. Note
> that pinning to a specific hash is not recommended practice.
> - With current job definitions, link current-tripleo promoted by
> upstream TripleoCI will promote repos with content from master
> branches and not stable/ocata after creating the ocata builder. We
> think this is not the desired situation during RC period and we must
> keep promotion of current-tripleo link for stable/ocata until
> cycle-trailing projects are tagged. This will require some changes in
> both Tripleo-CI and RDO-CI, please let us know your thoughs so that we
> can agree on the best way to implement this and start working on it.
> 
> Best regards,
> 
> Alfredo
> 
> __
> 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] [RDO][DLRN] DLRN worker downtime during the weekend

[Javier Pena]

> Hi RDO,
> 
> We need to run some maintenance operations on the DLRN instance next weekend,
> starting on Friday 13 @ 19:00 UTC. These are required to reduce the storage
> usage of the master and newton workers. The impact is:
> 
> - During the weekend, no new packages will be processed for the centos-master
> and centos-newton workers
> - The existing repositories will be available as usual.
> 
> I will send a follow-up e-mail once the maintenance has been finished. Please
> do not hesitate to contact me if you have any concerns.
> 

The maintenance is now completed, and all workers are building packages again.

Please reach out to us if you find any issue.

Regards,
Javier

> Regards,
> Javier
> 
> __
> 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] [RDO][DLRN] DLRN worker downtime during the weekend

[Javier Pena]

Hi RDO,

We need to run some maintenance operations on the DLRN instance next weekend, 
starting on Friday 13 @ 19:00 UTC. These are required to reduce the storage 
usage of the master and newton workers. The impact is:

- During the weekend, no new packages will be processed for the centos-master 
and centos-newton workers
- The existing repositories will be available as usual.

I will send a follow-up e-mail once the maintenance has been finished. Please 
do not hesitate to contact me if you have any concerns.

Regards,
Javier

__
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] [packstack] Proposal to add Alfredo Moralejo as core reviewer

[Javier Pena]

So after a week we have three +2, one +1, and noone against.

Alfredo, welcome to the core team!

Javier

- Original Message -
> Hi all,
> 
> I'd like to propose Alfredo Moralejo (amoralej in #Freenode) as a core
> reviewer for Packstack.
> 
> Alfredo has been providing consistent and quality reviews during the Newton
> cycle, and also a good number of patches [1].
> 
> Existing core reviewers, please vote now.
> 
> Regards,
> Javier
> 
> [1]
> https://review.openstack.org/#/q/status:merged+owner:%22Alfredo+Moralejo+%253Camoralej%2540redhat.com%253E%22+project:openstack/packstack
> 
> __
> 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] [packstack] Proposal to add Alfredo Moralejo as core reviewer

[Javier Pena]

Hi all,

I'd like to propose Alfredo Moralejo (amoralej in #Freenode) as a core reviewer 
for Packstack.

Alfredo has been providing consistent and quality reviews during the Newton 
cycle, and also a good number of patches [1].

Existing core reviewers, please vote now.

Regards,
Javier

[1] 
https://review.openstack.org/#/q/status:merged+owner:%22Alfredo+Moralejo+%253Camoralej%2540redhat.com%253E%22+project:openstack/packstack

__
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] [puppet] Puppet OpenStack PTL non-candidacy

[Javier Pena]

Emilien, you've done an awesome job, thanks a lot!

Javier

- Original Message -
> Hi,
> 
> I wrote a little blog post about the last cycle in PuppetOpenStack:
> http://my1.fr/blog/puppet-openstack-achievements-during-newton-cycle/
> 
> I can't describe how much I liked to be PTL during the last 18 months
> and I wouldn't imagine we would be where we are today when I started
> to contribute on this project.
> Working on it is something I really enjoy because we have interactions
> with all OpenStack community and I can't live without it.
> 
> However, I think it's time to pass the PTL torch for Ocata cycle.
> Don't worry, I'll still be around and bother you when CI is broken ;-)
> 
> Again, a big thank you for those who work with me,
> --
> Emilien Macchi
> 
> __
> 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] [puppet] proposal: start gating on puppet4

[Javier Pena]

- Original Message -
> Hi,
> 
> Today Puppet OpenStack CI is running unit and functional test jobs
> against puppet 3 and puppet 4.
> Unit jobs for puppet 4 are currently voting and pretty stable.
> Functional jobs for puppet 4 are not voting but also stable.
> 
> Even if Puppet4 has not been largely adopted by our community [1] yet,
> I would like to encourage our users to upgrade the version of Puppet.
> Fedora ships it by default [2] and for Ubuntu, it's also the default
> since yakkety [3].
> 
> [1]
> https://docs.google.com/spreadsheets/d/1iIQ6YmpdOVctS2-wCV6SGPP1NSj8nKD9nv_xtZH9loY/edit?usp=sharing
> [2] http://koji.fedoraproject.org/koji/packageinfo?packageID=3529
> [3] http://packages.ubuntu.com/yakkety/puppet
> 
> So here's my proposal, feel free to bring any feedback:
> - For stable/mitaka CI and stable/liberty nothing will change.
> - For current master (future stable/newton in a few months), transform
> non-voting puppet4 jobs into voting and add them to the gate. Also
> keep puppet3 unit tests jobs, as voting.
> - After Newton release (during Ocata cycle), change master CI to only
> gate functional jobs on puppet4 (and remove puppet3 jobs for
> puppet-openstack-integration); but keep puppet3 unit tests jobs, as
> voting.
> - During Ocata cycle, implement a periodic job that will nightly check
> we can deploy with Puppet3. The periodic job is something our
> community interested by Puppet 3 will have to monitor and report any
> new failure so we can address it.
> 
> That way, we tell our users:
> - don't worry if you deploy Liberty, Mitaka, Newton, we will
> officially support Puppet 3.
> - if you plan to deploy Puppet 4, we'll officially support you
> starting from Newton.
> - if you plan to deploy Ocata with Puppet 3, we won't support you
> anymore since our functional testing jobs will be gone. Though we'll
> make our best to be backward compatible thanks to our unit  and
> periodic functional testing jobs.
> 
> Regarding packaging:
> - on Ubuntu, we'll continue rely on what provides Puppetlabs because
> Xenial doesn't provide Puppet4.
> - on CentOS7, we are working on getting Puppet 4 packaged in RDO and
> our CI will certainly use it.
> 
> Any feedback is welcome,

I like the idea. It gives distros enough time to prepare to Puppet 4, and we're 
supposed to write compatible manifests anyway.

Javier

> --
> Emilien Macchi
> 
> __
> 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] [packstack] Update packstack core list

[Javier Pena]

- Original Message -
> 
> Hello,
> 
> I would like to step up as PTL if everybody is ok with it.
> 

Go for it Iván!

Javier

> Cheers,
> Ivan
> 
> - Original Message -
> > From: "Martin Magr" <mm...@redhat.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > Cc: "Javier Pena" <javier.p...@redhat.com>, "David Moreau Simard"
> > <d...@redhat.com>, "Alan Pevec" <ape...@redhat.com>,
> > "Ivan Chavero" <ichav...@redhat.com>
> > Sent: Tuesday, April 12, 2016 1:52:38 AM
> > Subject: Re: [openstack-dev] [packstack] Update packstack core list
> > 
> > Greetings guys,
> > 
> > 
> >   I will have to step down from PTL responsibility. TBH I haven't have time
> >   to work on Packstack lately and I probably won't have in the future
> >   because of my other responsibilities. So from my point of view it is not
> >   correct to lead the project (though I'd like to contribute/do review from
> >   time to time).
> > 
> > Thanks for understanding,
> > Martin
> > 
> > 
> > - Original Message -
> > From: "Emilien Macchi" <emil...@redhat.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > Cc: "Javier Pena" <javier.p...@redhat.com>, "David Moreau Simard"
> > <d...@redhat.com>
> > Sent: Wednesday, March 16, 2016 3:50:37 PM
> > Subject: Re: [openstack-dev] [packstack] Update packstack core list
> > 
> > On Wed, Mar 16, 2016 at 6:35 AM, Alan Pevec <ape...@gmail.com> wrote:
> > > 2016-03-16 11:23 GMT+01:00 Lukas Bezdicka <lbezd...@redhat.com>:
> > >>> ...
> > >>> - Martin Mágr
> > >>> - Iván Chavero
> > >>> - Javier Peña
> > >>> - Alan Pevec
> > >>>
> > >>> I have a doubt about Lukas, he's contributed an awful lot to
> > >>> Packstack, just not over the last 90 days. Lukas, will you be
> > >>> contributing in the future? If so, I'd include him in the proposal as
> > >>> well.
> > >>
> > >> Thanks, yeah I do plan to contribute just haven't had time lately for
> > >> packstack.
> > >
> > > I'm also adding David Simard who recently contributed integration tests.
> > >
> > > Since there hasn't been -1 votes for a week, I went ahead and
> > > implemented group membership changes in gerrit.
> > > Thanks to the past core members, we will welcome you back on the next
> > >
> > > One more topic to discuss is if we need PTL election? I'm not sure we
> > > need formal election yet and de-facto PTL has been Martin Magr, so if
> > > there aren't other proposal let's just name Martin our overlord?
> > 
> > Packstack is not part of OpenStack big tent so de-facto does not need
> > a PTL to work.
> > It's up to the project team to decide if whether or not a PTL is needed.
> > 
> > Oh and of course, go ahead Martin ;-)
> > 
> > > Cheers,
> > > Alan
> > >
> > > __
> > > 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
> > 
> > 
> > 
> > --
> > Emilien Macchi
> > 
> > __
> > 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] [packstack] Update packstack core list

[Javier Pena]

- Original Message -
> 2016-03-16 11:23 GMT+01:00 Lukas Bezdicka :
> >> ...
> >> - Martin Mágr
> >> - Iván Chavero
> >> - Javier Peña
> >> - Alan Pevec
> >>
> >> I have a doubt about Lukas, he's contributed an awful lot to
> >> Packstack, just not over the last 90 days. Lukas, will you be
> >> contributing in the future? If so, I'd include him in the proposal as
> >> well.
> >
> > Thanks, yeah I do plan to contribute just haven't had time lately for
> > packstack.
> 
> I'm also adding David Simard who recently contributed integration tests.
> 
> Since there hasn't been -1 votes for a week, I went ahead and
> implemented group membership changes in gerrit.
> Thanks to the past core members, we will welcome you back on the next
> 
> One more topic to discuss is if we need PTL election? I'm not sure we
> need formal election yet and de-facto PTL has been Martin Magr, so if
> there aren't other proposal let's just name Martin our overlord?
> 

+1 for Martin ;)

> Cheers,
> Alan
> 
> __
> 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] [packstack] Update packstack core list

[Javier Pena]

> Hi,
> 
> [post originally sent on RDO-list but I've been told I should use this
> channel]
> 
> I've looked at packstack core-list [1] and I suggest we revisit to keep
> only active contributors [2] in the core members list.
> 
> The list seems super big comparing to who is actually active on the
> project; in a meritocracy world it would make sense to revisit that list.
> 
> Thanks,
> 
> [1] https://review.openstack.org/#/admin/groups/124,members
> [2] http://stackalytics.com/report/contribution/packstack/90
> 

I agree with Emilien. Looking at the active contributors, my proposal for the 
core list would be:

- Martin Mágr
- Iván Chavero
- Javier Peña
- Alan Pevec

I have a doubt about Lukas, he's contributed an awful lot to Packstack, just 
not over the last 90 days. Lukas, will you be contributing in the future? If 
so, I'd include him in the proposal as well.


Thoughts?
Javier

> --
> Emilien Macchi
> 
> 
> __
> 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] Please do *not* use git (and specifically "git log") when generating the docs

[Javier Pena]

- Original Message -
> Hi,
> 
> I've seen Reno doing it, then some more. It's time that I raise the
> issue globally in this list before the epidemic spreads to the whole of
> OpenStack ! :)
> 
> The last occurence I have found is in oslo.config (but please keep in
> mind this message is for all projects), which has, its doc/source/conf.py:
> 
> git_cmd = ["git", "log", "--pretty=format:'%ad, commit %h'",
>"--date=local","-n1"]
> html_last_updated_fmt = subprocess.check_output(git_cmd,
> stdin=subprocess.PIPE)
> 
> Of course, the .git folder is *NOT* available when building a package in
> Debian (and more generally, in downstream distros). This means that this
> kind of joke *will* break the build of the packages when they also build
> the docs of your project. And consequently, the package maintainers have
> to patch out the above lines from conf.py. It'd be best if it wasn't
> needed to do so.
> 
> As a consequence, it is *not ok* to do "git log" anywhere in the sphinx
> docs. Please keep this in mind.
> 

We have hit the same issue in our automated builds for RDO Trunk, and 
https://bugs.launchpad.net/reno/+bug/1520096 is tracking it for reno.

while it is possible to work around it from the packagers' perspective, it 
would be better to not assume the source is obtained via a git clone.

Cheers,
Javier

> More generally, it is wrong to assume that even the git command is
> present. For Mitaka b2, I had to add git as build-dependency on nearly
> all server packages, otherwise they would FTBFS (fail to build from
> source). This is plain wrong and makes no sense. I hope this can be
> reverted somehow.
> 
> Thanks in advance for considering the above, and to try to see things
> from the package maintainer's perspective,
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> 
> __
> 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