from:"jean\-philippe"

Hello,

TL:DR; If you have spare cycles, join one of our interest groups!

In the Queens cycle, I have formalised the "liaisons" work, making
them an integral part of the Thursday's meeting agenda. Sadly, that
initiative didn't work, as almost no liaison worked/reported on those
meetings, and I stopped the initiative.

Upon common agreement that we now need to change how we scale the
team, we will now start our "liaison 2.0" work.

So, I have started an etherpad [1], where you could see all the
"groups" of people that OSA need, and where you could help.

Please don't hesitate to edit this etherpad, adding your new special
interest group, or simply joining an existing one if you have spare
cycles!

Thank you!

Jean-Philippe Evrard (evrardjp)

[1]: https://etherpad.openstack.org/p/osa-liaisons

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

[openstack-dev] [openstack-ansible] Restarting our very own "SIG" teams

Hello,

TL:DR; If you have spare cycles, join one of our interest groups!

In the Queens cycle, I have formalised the "liaisons" work, making
them an integral part of the Thursday's meeting agenda. Sadly, that
initiative didn't work, as almost no liaison worked/reported on those
meetings, and I stopped the initiative.

Upon common agreement that we now need to change how we scale the
team, we will now start our "liaison 2.0" work.

So, I have started an etherpad [1], where you could see all the
"groups" of people that OSA need, and where you could help.

Please don't hesitate to edit this etherpad, adding your new special
interest group, or simply joining an existing one if you have spare
cycles!

Thank you!

Jean-Philippe Evrard (evrardjp)

[1]: https://etherpad.openstack.org/p/osa-liaisons

__
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] [summary] Organizational diversity tag

> - Drop tags, write a regular report instead that can account for the
> subtlety of each situation (ttx). One issue here is that it's obviously a
> lot more work than the current situation.

That's what I'd prefer personally.

We have a website with a nice project navigator now [1].
This is somewhat a reference IMO, and should always be up to date for
the published releases.

The information is generated, but it could now as well be a static
file/source of truth that we update and peer review manually after a
cycle.
It could allow more flexible and case by case data.

This also make the information easy to find: that's naturally where
I'd go (if I was an end-user) to see information about a project, not
the governance repo.
Although now I have learnt, and I am not sure this is worth spending
much effort.

[1]: https://www.openstack.org/software/project-navigator/

__
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] [release] How to handle "stable" deliverables releases

Option 2 for me. And the option switch to independant is IMO just fine.

__
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-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging

2018-06-07 Thread Jean-Philippe Evrard

> Right, you can set the stable-branch-type field to 'tagless' (see
> http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n462) and
> then set the branch location field to the SHA you want to use.

Exactly what I thought.

> If you would be ready to branch all of the roles at one time, you could
> put all of them into 1 deliverable file. Otherwise, you will want to
> split them up into their own files.

Same.

>
> And since you have so many, I will point out that we're really into
> automation over here on the release team, and if you wanted to work on
> making the edit-deliverable command smart enough to determine the SHA
> for you I could walk you through that code to get you started.

Cool.

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

Re: [openstack-dev] [Openstack-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging

2018-06-07 Thread Jean-Philippe Evrard

> Right, you can set the stable-branch-type field to 'tagless' (see
> http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n462) and
> then set the branch location field to the SHA you want to use.

Exactly what I thought.

> If you would be ready to branch all of the roles at one time, you could
> put all of them into 1 deliverable file. Otherwise, you will want to
> split them up into their own files.

Same.

>
> And since you have so many, I will point out that we're really into
> automation over here on the release team, and if you wanted to work on
> making the edit-deliverable command smart enough to determine the SHA
> for you I could walk you through that code to get you started.

Cool.

__
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-operators] Switching from Fuel to OpenStack-Ansible

Hello,

That's doable indeed! (In fact it's exactly what I did during Kilo
timeframe! :p)
Have you looked at the openstack-ansible deploy guide? It should help
you understand the process. On the way it should link you to the
reference architecture, where you can have more details about the
network flows.

Don't hesitate to join us on our IRC channel for more detailed
questions, on freenode #openstack-ansible.
If you want to continue by email, don't hesitate to put
[openstack-ansible] in the email title :)

Best regards,
Jean-Philippe Evrard (evrardjp)

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

[Openstack-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging

Hello,

*TL:DR;* If you are an openstack-ansible user, consuming our roles directly,
with tags, without using openstack-ansible plays or integrated repo,
then things will change for you. Start using git shas instead of tags.
All other openstack-ansible users should not see a difference, even if
they use openstack-ansible tags.

During the summit, I had a discussion with dhellman (and smcginnis)
to change how openstack-ansible does its releases.

Currently, we tag openstack-ansible + many roles under our umbrella
every two weeks. As far as I know, nobody requested to have roles
tagged every two weeks. Only OpenStack-Ansible need to be tagged
for consumption. Even people using our roles directly outside
openstack-ansible generally use sha for roles. We don't rely on
ansible galaxy.

Because there is no need to tag the roles, there is no need to make them
part of the "openstack-ansible" deliverable [1][2]. I will therefore
clarify the governance repo for that, separating the roles, each of them
with their own deliverable, instead of grouping some roles within
openstack-ansible, and some others outside it.

With this done, a release of openstack-ansible becomes straightforward
using the standard release tooling. The releases of openstack-ansible
becomes far simpler to request, review, and will not have timeouts
anymore :p

There are a few issues I see from the change. Still according to the
discussion, it seems we can overcome those.

1. As this will be applied on all the branches, we may reach some
issues with releasing in the next days. While the validate tooling
of releases has shown me that it wouldn't be a problem (just
warning) to not have all the repos in the deliverable, I would
expect a governance change could be impactful.
However, that is only impacting openstack-ansible, releases,
and governance team: Keep in mind, openstack-ansible will not
change for its users, and will still be tagged as you know it.

2. We will keep branching our roles the same way we do now. What
we liked for roles being part of this deliverable, is the ability
of having them automatically branched and their files adapted.
To what I heard, it is still possible to do so, by having a
devstack-like behavior, which branches on a sha, instead of
branching on tag. So I guess it means all our roles will now be
part of release files like this one [3], or even on a single release
file, similar to it.

What I would like to have, from this email, is:
1. Raise awareness to all the involved parties;
2. Confirmation we can go ahead, from a governance standpoint;
3. Confirmation we can still benefit from this automatic branch
tooling.

Thank you in advance.

Jean-Philippe Evrard (evrardjp)

[1]:
https://github.com/openstack/governance/blob/8215c5fd9b464b332b310bbb767812fefc5d9174/reference/projects.yaml#L2493-L2540
[2]:
https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/openstack-ansible.yaml#L768-L851
[3]:
https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/devstack.yaml

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

[openstack-dev] [openstack-ansible][releases][governance] Change in OSA roles tagging

Hello,

During the summit, I had a discussion with dhellman (and smcginnis)
to change how openstack-ansible does its releases.

There are a few issues I see from the change. Still according to the
discussion, it seems we can overcome those.

Thank you in advance.

Jean-Philippe Evrard (evrardjp)

__
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] Organizational diversity tag

Sorry if I missed/repeat something already said in this thread...

When I am looking at diversity, I generally like to know: 1) what's
going on "right now", and 2) what happened in the cycle x.

I think these 2 are different problems to solve. And tags are, IMO,
best applied to the second case.

So if I focus on the second: What if we are only tagging once per
cycle, after the release?
(I am pushing the idea further than the quarter basically). It would
avoid flappiness (if that's a proper term?).
For me, a cycle has a clear meaning. And involvements can balance out
in a cycle.
This would be, IMO, good enough to promote/declare diversity after the
facts (and is an answer to the "what happened during the cycle").

Jean-Philippe Evrard (evrardjp)

__
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] [docs][openstack-ansible]

2018-05-14 Thread Jean-Philippe Evrard

Can't. use. words.

Much sadness! But happiness for you and your future, at the same time :)
It was a pleasure to work on your side.

https://media.giphy.com/media/IcGkqdUmYLFGE/giphy.gif

__
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-operators] New project creation fails because of a Nova check in a multi-region cloud

2018-05-10 Thread Jean-Philippe Méthot



> Le 11 mai 2018 à 08:36, Matt Riedemann <mriede...@gmail.com> a écrit :
> 
> On 5/10/2018 6:30 PM, Jean-Philippe Méthot wrote:
>> 1.I was talking about the region-name parameter underneath 
>> keystone_authtoken. That is in the pike doc you linked, but I am unaware if 
>> this is only used for token generation or not. Anyhow, it doesn’t seem to 
>> have any impact on the issue at hand.
> 
> The [keystone]/region_name config option in nova is used to pike the identity 
> service endpoint so I think in that case region_one will matter if there are 
> multiple identity endpoints in the service catalog. The only thing is you're 
> on pike where [keystone]/region_name isn't in nova.conf and it's not used, it 
> was added in queens for this lookup:
> 
> https://review.openstack.org/#/c/507693/
> 
> So that might be why it doesn't seem to make a difference if you set it in 
> nova.conf - because the nova code isn't actually using it.
> 

I was talking about the parameter under [keystone_authtoken] 
([keystone_authtoken]/region_name) and not the new one under [keystone] 
([keystone]/region_name). It seems that we were talking about different 
parameters though so this explains that. 


> You could try backporting that patch into your pike deployment, set 
> region_name to RegionOne and see if it makes a difference (although I thought 
> RegionOne was the default if not specified?).

I will attempt this next week. Will update if I run into any issues. Also, from 
experience, most Openstack services seem to pick a random endpoint when 
region_name isn’t specified in a multi-region cloud. I’ve seen that several 
times ever since I've built and started maintaining this infrastructure.

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

Re: [Openstack-operators] New project creation fails because of a Nova check in a multi-region cloud

2018-05-10 Thread Jean-Philippe Méthot




>> 
>>> I currently operate a multi-region cloud split between 2 geographic
>>> locations. I have updated it to Pike not too long ago, but I've been
>>> running into a peculiar issue. Ever since the Pike release, Nova now
>>> asks Keystone if a new project exists in Keystone before configuring
>>> the project’s quotas. However, there doesn’t seem to be any region
>>> restriction regarding which endpoint Nova will query Keystone on. So,
>>> right now, if I create a new project in region one, Nova will query
>>> Keystone in region two. Because my keystone databases are not synched
>>> in real time between each region, the region two Keystone will tell
>>> it that the new project doesn't exist, while it exists in region one
>>> Keystone.
> Are both keystone nodes completely separate? Do they share any information?

I share the DB information between both. In our use case, we very rarely make 
changes to keystone (password change, user creation, project creation) and 
there is a limited number of people who even have access to it, so I can get 
away with having my main DB in region 1 and hosting an exact copy in region 2. 
The original idea was to have a mysql slave in region 2, but that failed and we 
decided to go with manually replicating the keystone DB whenever we would make 
changes. This means I have the same users and projects in both regions, which 
is exactly what I want right now for my specific use case. Of course, that also 
means I only do operations in keystone in Region 1 and never from Region 2 to 
prevent discrepancies.
>>> 
>>> Thinking that this could be a configuration error, I tried setting
>>> the region_name in keystone_authtoken, but that didn’t change much of
>>> anything. Right now I am thinking this may be a bug. Could someone
>>> confirm that this is indeed a bug and not a configuration error?
>>> 
>>> To circumvent this issue, I am considering either modifying the
>>> database by hand or trying to implement realtime replication between
>>> both Keystone databases. Would there be another solution? (beside
>>> modifying the code for the Nova check)
> A variant of this just came up as a proposal for the Forum in a couple
> weeks [0]. A separate proposal was also discussed during this week's
> keystone meeting [1], which brought up an interesting solution. We
> should be seeing a specification soon that covers the proposal in
> greater detail and includes use cases. Either way, both sound like they
> may be relevant to you.
> 
> [0] https://etherpad.openstack.org/p/YVR-edge-keystone-brainstorming 
> 
> [1]
> http://eavesdrop.openstack.org/meetings/keystone/2018/keystone.2018-05-08-16.00.log.html#l-156
>  
> 

This is interesting. Unfortunately I will not be in Vancouver, but I will keep 
an eye on it in the future. I will need to find a way to solve the current 
issue at hand shortly though.

>> 
>> This is the specific code you're talking about:
>> 
>> https://github.com/openstack/nova/blob/stable/pike/nova/api/openstack/identity.py#L35
>> 
>> 
>> I don't see region_name as a config option for talking to keystone in
>> Pike:
>> 
>> https://docs.openstack.org/nova/pike/configuration/config.html#keystone
>> 
>> But it is in Queens:
>> 
>> https://docs.openstack.org/nova/queens/configuration/config.html#keystone
>> 
>> That was added in this change:
>> 
>> https://review.openstack.org/#/c/507693/
>> 
>> But I think what you're saying is, since you have multiple regions,
>> the project could be in any of them at any given time until they
>> synchronize so configuring nova for a specific region isn't probably
>> going to help in this case, right?
>> 
>> Isn't this somehow resolved with keystone federation? Granted, I'm not
>> at all a keystone person, but I'd think this isn't a unique problem.
> Without knowing a whole lot about the current setup, I'm inclined to say
> it is. Keystone-to-keystone federation was developed for cases like
> this, and it's been something we've been trying to encourage in favor of
> building replication tooling outside of the database or over an API. The
> main concerns with taking a manual replication approach is that it could
> negatively impact overall performance and that keystone already assumes
> it will be in control of ID generation for most cases (replicating a
> project in RegionOne into RegionTwo will yield a different project ID,
> even though it is possible for both to have the same name).
> Additionally, there are some things that keystone doesn't expose over
> the API that would need to be replicated, like revocation events (I
> mentioned this in the etherpad linked above).

To answer the questions of both posts:

1.I was talking about the region-name parameter underneath keystone_authtoken. 
That is in the pike doc you linked, but I am unaware if this is only used for 
token

[Openstack-operators] New project creation fails because of a Nova check in a multi-region cloud

2018-05-09 Thread Jean-Philippe Méthot

Hi,

I currently operate a multi-region cloud split between 2 geographic locations. 
I have updated it to Pike not too long ago, but I've been running into a 
peculiar issue. Ever since the Pike release, Nova now asks Keystone if a new 
project exists in Keystone before configuring the project’s quotas. However, 
there doesn’t seem to be any region restriction regarding which endpoint Nova 
will query Keystone on. So, right now, if I create a new project in region one, 
Nova will query Keystone in region two. Because my keystone databases are not 
synched in real time between each region, the region two Keystone will tell it 
that the new project doesn't exist, while it exists in region one Keystone.

Thinking that this could be a configuration error, I tried setting the 
region_name in keystone_authtoken, but that didn’t change much of anything. 
Right now I am thinking this may be a bug. Could someone confirm that this is 
indeed a bug and not a configuration error?

To circumvent this issue, I am considering either modifying the database by 
hand or trying to implement realtime replication between both Keystone 
databases. Would there be another solution? (beside modifying the code for the 
Nova check)

Jean-Philippe Méthot
Openstack system administrator
Administrateur système Openstack
PlanetHoster inc.




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

Re: [openstack-dev] [all][tc][ptls] final stages of python 3 transition

2018-05-07 Thread Jean-Philippe Evrard

We've been juggling with python3, ansible and multiple distros for a while now.
That dance hasn't been fruitful: many hidden issues, either due to
ansible modules, or our own modules, or upgrade issues.

I've recently decided to simplify the python2/3 story.

Queens and all the stable branches will be python2 only (python3 will
not be used anymore, to simplify the code)

For Rocky, we plan to use as much as possible the distribution
packages for the python stack, if it's recent enough for our source
installs.
Ubuntu 16.04 will have python2, SUSE has python2, CentOS has no
appropriate package, so we are pip installing things (and using
python2).
So... If people work on Ubuntu 18.04 support, we could try a python3
only system. Nobody worked on it right now.
Same for CentOS, because there is no usage of packages, we could use
Software Collections and have centos as a python3 only system. Sadly,
nobody has the cycles to do it now.

I am expecting we'll be using/seeing a lot more python3 in the future
with S, and wish for a python3 only "S" release.
But this solely depends on the work done in R to make sure 18.04 is
ready, as this would be our example, and "stepping stone" towards both
python2 and python3.

I am not sure this answers your question, as this is more gray than a
black or white answer.
But I am hoping we'll stabilize python3 this cycle, for ubuntu 18.04
at least, and other distros as a stretch goal.

Best regards,
Jean-Philippe Evrard (evrardjp)

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

Re: [openstack-dev] [openstack-ansible] Implement rotations for meetings handling

2018-05-07 Thread Jean-Philippe Evrard

I think Jesse sumarized things elegantly.

Here is an analogy for you, to complement the answer with more
background. Let me compare our state with a new company,
as this is a a notion people many people can relate to.

Initially we were a startup. Only a few people were working on OSA on
its creation. And they were busy doing everything.
But then we grew, and we continue to grow. At some point, those few
people doing everything didn't (or don't) have the time to do
everything anymore (because of the growing nature). So OSA, like any
business, needs to learn how to grow bigger.

One of the way is to distribute work as much as we can into the more
appropriate persons.
We started doing that by distributing core duties for roles.
We are now adding the meeting organisation.
I have a few other ideas where shared ownership will help the project
mature and allow more growth in the future, but one step at a time :)

Best regards,
Jean-Philippe Evrard (evrardjp)

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

[openstack-dev] [openstack-ansible] Implement rotations for meetings handling

2018-05-02 Thread Jean-Philippe Evrard

Hello everyone,

Now that we are all part-time, I'd like to toy with a new idea,
proposed in the past by Jesse, to rotate the duties with people who
are involved in OSA, or want to get involved more (it's not restricted
to core developers!).

One of the first duties to be handled this way could be the weekly meeting.

Handling the meeting is not that hard, it just takes time to prepare,
and to facilitate.

I think everyone should step into this, not only core developers, but
core developers are now expected to run the meetings when their turn
comes.


What are the actions to take:
- Prepare the triage. Generate the list of the bugs for the week.
- Ping people with the triage links around 1h before the weekly
meeting. It would give them time to get prepared for meeting,
eventually updating the agenda, and read the current bugs
- Ping people at the beginning of the meeting
- Chair the meeting: The structure of the meeting is now always
the same, a recap of the week, and handling the bug triage.
- After the meeting we would ask who is volunteer to run next
meeting, and if none, a meeting char will be selected amongst core
contributors at random.

Thank you for your understanding.

Jean-Philippe Evrard (evrardjp)

__
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] [OpenStackAnsible] Tag repos as newton-eol

2018-04-29 Thread Jean-Philippe Evrard

Hello,

> I'd like to phase out openstack/openstack-ansible-tests and
> openstack/openstack-ansible later.

Now that we had the time to bump the roles in openstack-ansible, and
adapt the tests, we can now EOL the rest of newton, i.e.:
openstack/openstack-ansible and openstack/openstack-ansible-tests.

Thanks for the help again Tony!
JP

__
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-operators] Strange behaviour change in cinder with a Dell compellent backend

2018-04-24 Thread Jean-Philippe Méthot

Thank you for your reply. This implies that the SAN keeps track of a volume’s 
native ID. So, for example, if I had a VM that was trying to mount an 
inexistant volume ID after migration, I could fix this by creating a new volume 
with the proper ID and just migrate the data from the volume that was in-use 
previously. That was my main concern and now it does make the process of fixing 
this simpler.


Jean-Philippe Méthot
Openstack system administrator
Administrateur système Openstack
PlanetHoster inc.




> Le 25 avr. 2018 à 00:22, Sean McGinnis <sean.mcgin...@gmx.com> a écrit :
> 
> If I remember right, this was a fix in the driver to be able to track the
> volume by its native array ID and not its name. This is how things should 
> work.
> Reliance on the name of the volume is not safe, and as seen here, can be
> misused to do things that are not really supported and can cause some
> unintended side effects.
> 
> You can update the database to get the same (mis)behavior you were using, but 
> I
> am not suggesting that is a good thing to do.

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

[openstack-dev] [openstack-ansible] Proposing Mohammed Naser as core reviewer

2018-04-24 Thread Jean-Philippe Evrard

Hi everyone,

I’d like to propose Mohammed Naser [1] as a core reviewer for OpenStack-Ansible.

He has been working actively on fixing the telemetry stack, and is now
willing to step up to improve the CentOS platform which is now in a
very degraded state.

I feel that it’s important that he’s able to safeguard the existing
and future work about CentOS
and help grow the maintenance community for it.

[1] 
http://stackalytics.com/?module=openstackansible-group_id=mnaser=rocky=person-day

Best regards,

Jean-Philippe Evrard
IRC: evrardjp

__
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-operators] Strange behaviour change in cinder with a Dell compellent backend

2018-04-23 Thread Jean-Philippe Méthot

Hi,

This is a very strange behaviour that has causing me issues with my SAN ever 
since we upgraded to Mitaka or Ocata I believe, several months ago. 
Essentially, I used to be able to change the ID of a disk in the SAN to swap 
the disk in Openstack. So, for example, I had disk 1. I could restore a 
snapshot of disk 1 on disk 2, rename disk 1 to disk 1-bak and rename disk 2 to 
disk 1 and the VM would start booting off of the new disk I had just made. This 
has changed. Now, somehow, Openstack sticks to the original disk even if I 
rename the disk. 

While annoying, this behaviour didn’t really cause me that many issues. 
However, I have discovered that if I migrate VMs on which such an operation 
happened, the VM will try to boot off the original disk from several months 
ago, despite the new disk being there with the correct ID. How can Openstack 
find the old disk even if its ID in the SAN has changed? 

Jean-Philippe Méthot
Openstack system administrator
Administrateur système Openstack
PlanetHoster inc.




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

Re: [openstack-dev] [all][infra] ubuntu-bionic and legacy nodesets

2018-04-20 Thread Jean-Philippe Evrard

That's very cool.
Any idea of the repartition of nodes xenial vs bionic? Is that a very
restricted amount of nodes?


On 20 April 2018 at 00:37, Paul Belanger  wrote:
> Greetings,
>
> With ubuntu-bionic release around the corner we'll be starting discussions 
> about
> migrating jobs from ubuntu-xenial to ubuntu-bionic.
>
> On topic I'd like to raise, is round job migrations from legacy to native
> zuulv3.  Specifically, I'd like to propose we do not add legacy-ubuntu-bionic
> nodesets into openstack-zuul-jobs. Projects should be working towards moving
> away from the legacy format, as they were just copypasta from our previous JJB
> templates.
>
> Projects would still be free to move them intree, but I would highly encourage
> projects do not do this, as it only delays the issue.
>
> The good news is the majority of jobs have already been moved to native zuulv3
> jobs, but there are still some projects still depending on the legacy 
> nodesets.
> For example, tox bases jobs would not be affected.  It mostly would be dsvm
> based jobs that haven't been switch to use the new devstack jobs for zuulv3.
>
> -Paul
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [openstack-ansible] Problems with Openstack services while migrating VMs

2018-04-18 Thread Jean-Philippe Evrard

Maybe worth posting on operators, but it looks like the scheduling of
the action fails, which let me think that nova is not running fine
somewhere.

Why is the restart in a random order? That can cause issues, and
that's the whole reason why we are orchestrating the deploys/upgrade
with ansible.
Also, why don't you follow our operations guide for recovering for a
failure? Is there something wrong there?

Regards,
JP

On 17 April 2018 at 14:07, Periyasamy Palanisamy
 wrote:
> Hi,
>
>
>
> I’m trying to migrate controller and compute VMs installed with
> Openstack-Ansible across systems with following approach.
>
> This is mainly to minimize the deployment time in the Jenkins CI
> environment.
>
>
>
> Export steps:
>
> Power off the VMs gracefully.
> virsh dumpxml ${node} > $EXPORT_PATH/${node}.xml
> cp /var/lib/libvirt/images/${node}.qcow2 $EXPORT_PATH/$node.qcow2
> create a tar ball for the xml’s and qcow2 images.
>
>
>
> Import steps:
>
> cp ${node}.qcow2 /var/lib/libvirt/images/
> virsh define ${node}.xml
> virsh start ${node}
>
>
>
> After the import of the VMs, The openstack services (neutron-server, DHCP
> agent, Metering agent, Metadata agent, L3 agent, Open vSwitch agent,
> nova-conductor and nova-comute) are started in random order.
>
> This causes neutron and nova is not able to find DHCP agent and compute
> accordingly to bring up the tenant VM and throws the error [1].
>
>
>
> I have also tried to boot compute VM followed by controller VM. It also
> doesn’t help.
>
> Could you please let me know what is going wrong here ?
>
>
>
> [1] https://paste.ubuntu.com/p/YNg2NnjvpS/ (fault section)
>
>
>
> Thanks,
>
> Periyasamy
>
>
> __
> 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-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-dev] [openstack-ansible] We need to change!

2018-04-17 Thread Jean-Philippe Evrard

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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] Stepping down from OpenStack-Ansible core

2018-03-28 Thread Jean-Philippe Evrard

Hello,

Ahah, gate job breakages? You were the first to break them, but also
willing to step in to fix them as soon as you knew.
And that's the part I will remember the most.

You will be missed, Major. Your next team is lucky to have you!
It was a pleasure working with you. And the gifs, omagad! :)

JP

On 27 March 2018 at 12:11, Jesse Pretorius
 wrote:
> Ah Major, we shall definitely miss your readiness to help, positive attitude 
> and deep care for setenforce 1. Oh, and then there're the gifs... so many 
> gifs...
>
> While I am inclined to [1], I shall instead wish you well while you [2]. (
>
> [1] https://media.giphy.com/media/1BXa2alBjrCXC/giphy.gif
> [2] https://media.giphy.com/media/G6if3AWViiNdC/giphy.gif
>
>
> On 3/26/18, 2:07 PM, "Major Hayden"  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hey there,
>
> As promised, I am stepping down from being an OpenStack-Ansible core 
> reviewer since I am unable to meet the obligations of the role with my new 
> job. :(
>
> Thanks to everyone who has mentored me along the way and put up with my 
> gate job breakages. I have learned an incredible amount about OpenStack, 
> Ansible, complex software deployments, and open source communities. I 
> appreciate everyone's support as I worked through the creation of the 
> ansible-hardening role as well as adding CentOS support for OpenStack-Ansible.
>
> - --
> Major Hayden
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAlq4774ACgkQc3BR4MEB
> H7E+gA/9HJEDibsQhdy191NbxbhF75wUup3gRDHhGPI6eFqHo/Iz8Q5Kv9Z9CXbo
> rkBGMebbGzoKwiLnKbFWr448azMJkj5/bTRLHb1eDQg2S2xaywP2L4e0CU+Gouto
> DucmGT6uLg+LKdQByYTB8VAHelub4DoxV2LhwsH+uYgWp6rZ2tB2nEIDTYQihhGx
> /WukfG+3zA99RZQjWRHmfnb6djB8sONzGIM8qY4qDUw9Xjp5xguHOU4+lzn4Fq6B
> cEpsJnztuEYnEpeTjynu4Dc8g+PX8y8fcObhcj+1D0NkZ1qW7sdX6CA64wuYOqec
> S552ej/fR5FPRKLHF3y8rbtNIlK5qfpNPE4UFKuVLjGSTSBz4Kp9cGn2jNCzyw5c
> aDQs/wQHIiUECzY+oqU1RHZJf9/Yq1VVw3vio+Dye1IMgkoaNpmX9lTcNw9wb1i7
> lac+fm0e438D+c+YZAttmHBCCaVWgKdGxH7BY84FoQaXRcaJ9y3ZoDEx6Rr8poBQ
> pK4YjUzVP9La2f/7S1QemX2ficisCbX+MVmAX9G4Yr9U2n98aXVWFMaF4As1H+OS
> zm9r9saoAZr6Z8BxjROjoClrg97RN1zkPseUDwMQwlJwF3V33ye3ib1dYWRr7BSm
> zAht+Jih/JE6Xtp+5UEF+6TBCYFVtXO8OHzCcac14w9dy1ur900=
> =fx64
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> 
> Rackspace Limited is a company registered in England & Wales (company 
> registered number 03897010) whose registered office is at 5 Millington Road, 
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
> contain confidential or privileged information intended for the recipient. 
> Any dissemination, distribution or copying of the enclosed material is 
> prohibited. If you receive this transmission in error, please notify us 
> immediately by e-mail at ab...@rackspace.com and delete the original message. 
> Your cooperation is appreciated.
> __
> 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] [stable][release] Remove complex ACL changes around releases

2018-03-28 Thread Jean-Philippe Evrard

LGTM

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

[openstack-dev] [OpenStack-Ansible] Vancouver forum etherpad

2018-03-26 Thread Jean-Philippe Evrard

Dear OpenStack-Ansiblers,

We've got an etherpad here [1], to track all the things we want to
discuss at the forum.

if you're an OpenStack-Ansible user, don't hesitate to add your
session ideas, list what you liked or disliked in the last release,
and share your experience!

Thank you in advance.

[1]: https://etherpad.openstack.org/p/YVR-openstack-ansible-brainstorming

Best regards,
Jean-Philippe.

__
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] [charms] [tripleo] [puppet] [fuel] [kolla] [openstack-ansible] [cloudcafe] [magnum] [mogan] [sahara] [shovel] [watcher] [helm] [rally] Heads up: ironic classic drivers deprecation

Hello,

Thanks for the notice!

JP

On 16 March 2018 at 12:09, Dmitry Tantsur  wrote:
> Hi all,
>
> If you see your project name in the subject that is because a global search
> revived usage of "pxe_ipmitool", "agent_ipmitool" or "pxe_ssh" drivers in
> the non-unit-test context in one or more of your repositories.
>
> The classic drivers, such as pxe_ipmitool, were deprecated in Queens, and
> we're on track with removing them in Rocky. Please read [1] about
> differences between classic drivers and newer hardware types. Please refer
> to [2] on how to update your code.
>
> Finally, the pxe_ssh driver was removed some time ago. Please use the
> standard IPMI driver with the virtualbmc project [3] instead.
>
> Please reach out to the ironic team (here or on #openstack-ironic) if you
> have any questions or need help with the transition.
>
> Dmitry
>
> [1] https://docs.openstack.org/ironic/latest/install/enabling-drivers.html
> [2]
> https://docs.openstack.org/ironic/latest/admin/upgrade-to-hardware-types.html
> [3] https://github.com/openstack/virtualbmc
>
> __
> 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][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

Thanks!

On 16 March 2018 at 16:56, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Jeremy Stanley's message of 2018-03-16 13:43:00 +:
>> On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote:
>> > On Mar 16, 2018, at 04:02, Jean-Philippe Evrard <jean-phili...@evrard.me> 
>> > wrote:
>> >
>> > > For OpenStack-Ansible, we don't need to do anything for that
>> > > community goal.  I am not sure how we can remove our name from
>> > > the storyboard, so I just inform you here.
>> >
>> > I believe you can just mark the task as done if there is no
>> > additional work required.
>>
>> Yeah, either "merged" or "invalid" states should work. I'd lean
>> toward suggesting "invalid" in this case since the task did not
>> require any changes merged to your source code.
>
> Yes, we've been using "invalid" to indicate that no work was needed.
>
> Doug
>
> __
> 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][PTLs] Community Goals for Rocky: Toggle the debug option at runtime

Hello,

For OpenStack-Ansible, we don't need to do anything for that community
goal.  I am not sure how we can remove our name from the storyboard,
so I just inform you here.

Jean-Philippe Evrard (evrardjp)

On 28 February 2018 at 05:27, ChangBo Guo <glongw...@gmail.com> wrote:
> Hi ALL,
>
> TC approved the  goal [0]  a week ago ,  so it's time to finish the work. we
> also have a short discussion in oslo meeting  at PTG, find more details in
> [1] ,
> we use storyboard to check the goal in
> https://storyboard.openstack.org/#!/story/2001545.  It's appreciated PTL set
> the owner in time .
> Feel free to reach me( gcb) in IRC if you have any questions.
>
>
> [0] https://review.openstack.org/#/c/534605/
> [1] https://etherpad.openstack.org/p/oslo-ptg-rocky  From line 175
>
> --
> ChangBo Guo(gcb)
> Community Director @EasyStack
>
> __
> 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] Anyone using our ubuntu-mariadb mirror?

Hello,

We were using it until a couple of weeks ago, when 10.1.31 got out.
10.1.31 got issues with clustering and we moved to use a mirror of
10.1. (here 10.1.30), instead of 10.1.
We haven't decided if we'll move back to 10.1 when 10.1.32 will be out.

You can remove it for now, I think we can discuss this again when
10.1.32 will be out.

Best regards,
JP

On 14 March 2018 at 22:50, Ian Wienand  wrote:
> Hello,
>
> We discovered an issue with our mariadb package mirroring that
> suggests it hasn't been updating for some time.
>
> This would be packages from
>
>  http://mirror.X.Y.openstack.org/ubuntu-mariadb/10.<1|2>
>
> This was originally added in [1].  AFAICT from codesearch, it is
> currently unused.  We export the top-level directory in the mirror
> config scripts as NODEPOOL_MARIADB_MIRROR, which is not referenced in
> any jobs [2], and I couldn't find anything setting up apt repos
> pointing to it.
>
> Thus since it's not updating and nothing seems to reference it, I am
> going to assume it is unused and remove it next week.  If not, please
> respond and we can organise a fix.
>
> -i
>
> [1] https://review.openstack.org/#/c/307831/
> [2] 
> http://codesearch.openstack.org/?q=NODEPOOL_MARIADB_MIRROR=nope==
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] OpenStack Ansible Disk requirements [docs] [osa]