[Openstack-operators] Fwd: [openstack-ansible] We need to change!

2018-04-17 Thread Jean-Philippe Evrard
Sorry for the cross-posting, but I think this could interest operators too.

Dear community,

Starting at the end of this month, I won't be able to work full time
on OpenStack-Ansible anymore.

I want to highlight the following:
Our current way of working is not sustainable in the long run, as a lot
of work (and therefore pressure) is concentrated on a few individuals.

I managed to get more people working on some parts of our code
(becoming cores on specific areas of knowledge, like mbuil on
networking, mnaser and gokhan on telemetry, johnsom on octavia,
mugsie on designate), but at the same time we have lost a
core reviewer on all our code base (mhayden).

I like the fact we are still innovating with our own deployment tooling,
bringing more features in, changing the deployment models to be always
more stable, more user-friendly.

But new features aren't all. We need people actively looking at the
quality of existing deliverables. We need to stretch those
responsibilities to more people.

I would be very happy if some people using OpenStack-Ansible
would help on:

* Bugs. We are reaching an all-time high amount of bugs pending.
  We need people actively cleaning those. We need someone to
  organize a bug smash. We need people willing to lead the bug
  triage process too.
* Releases. Our current release process is manual. People
  interested by how releases are handled should step in there
  (for example, what does in, and at what time).
  We also need to coordinate with the releases
  team, and improve our way to release.
* Jobs/state monitoring. I have spent an insane amount of time
  cleaning up after other people. That cannot be done any longer.
  If you're breaking a job, whether it's part of the
  openstack-ansible gates or not, you should be fixing it.
  Even if it's a non-voting job, or a periodic job.
  I'd like everyone to monitor our zuul dashboard, and take
  action based on that. When queens was close to release,
  everything job was green on the zuul dashboard. I did an
  experiment of 1 month without me fixing the upgrade jobs,
  and guess what: ALL (or almost ALL) the upgrade jobs are
  now broken. Please monitor [1] and actively help fixing
  the jobs. Remember, if everyone works on this, it would
  give a great feedback to new users, and it becomes a
  virtuous cycle.
* Reduce technical debt. We have so many variables, so many
  remnants of the past. This cycle is planned to be a
  cleanup. Let's simplify all of this, making sure the
  deployment of openstack with openstack-ansible ends
  up with a system KISS.
* Increasing voting test coverage. We need more code
  paths tested and we need those code path preventing
  bad patches to merge. It makes the reduction of
  technical debt easier.

Really thank you for your understanding.

Best regards,
Jean-Philippe (evrardjp)

[1]: 
http://zuul.openstack.org/builds.html?pipeline=periodic=openstack%2Fopenstack-ansible

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


[Openstack-operators] [all] How to handle python3 only projects

2018-04-17 Thread Adrian Turjak
Hello devs,

The python27 clock of doom ticks closer to zero
(https://pythonclock.org/) and officially dropping python27 support is
going to have to happen eventually, that though is a bigger topic.

Before we get there outright what we should think about is what place
python3 only projects have in OpenStack alongside ones that support both.

Given that python27's life is nearing the end, we should probably
support a project either transitioning to only python3 or new projects
that are only python3. Not to mention the potential inclusion of python3
only libraries in global-requirements.

Potentially we should even encourage python3 only projects, and
encourage deployers and distro providers to focus on python3 only (do
we?). Python3 only projects are now a reality, python3 only libraries
are now a reality, and most of OpenStack already supports python3. Major
libraries are dropping python27 support in newer versions, and we should
think about how we want to do it too.

So where do projects that want to stop supporting python27 fit in the
OpenStack ecosystem? Or given the impending end of python27, why should
new projects be required to support it at all, or should we heavily
encourage new projects to be python3 only (if not require it)?

It's not an easy topic, and there are likely lots of opinions on the
matter, but it's something to start considering.

Cheers!

- Adrian Turjak








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