Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

[Jean-Philippe Evrard]

On Mon, 2018-10-22 at 07:50 -0700, Morgan Fainberg wrote:
> Also, doesn't bitbucket have a git interface now too (optionally)?
> 
It does :)
But I think it requires a new repo, so it means that could as well move
to somewhere else like github or openstack infra :p 


__
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] [goals][upgrade-checkers] Week R-25 Update

[Jean-Philippe Evrard]

On Tue, 2018-10-23 at 16:40 -0500, Matt Riedemann wrote:
> On 10/23/2018 1:41 PM, Sean McGinnis wrote:
> > > Yeah, but part of the reason for placeholders was consistency
> > > across all of
> > > the services. I guess if there are never going to be upgrade
> > > checks in
> > > adjutant then I could see skipping it, but otherwise I would
> > > prefer to at
> > > least get the framework in place.
> > > 
> > +1
> > 
> > Even if there is nothing to check at this point, I think having the
> > facility
> > there is a benefit for projects and scripts that are going to be
> > consuming
> > these checks. Having nothing to check, but having the status check
> > there, is
> > going to be better than everything needing to keep a list of which
> > projects to
> > run the checks on and which not.
> > 
> 
> Sure, that works for me as well. I'm not against adding
> placeholder/noop 
> checks knowing that nothing is immediately obvious to replace those
> in 
> Stein, but could be done later when the opportunity arises. If it's 
> debatable on a per-project basis, then I'd defer to the core team
> for 
> the project.
> 

+1 on what Ben, Matt, and Sean said there.


__
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-dev] [goals][upgrade-checkers] Week R-26 Update

[Jean-Philippe Evrard]

ain multi-upgrade (jumps)
scenarios. After a while, we could think of feeding those back to
upgrade checkers.

3) I like the approach of having oslo-config-validator. However, I must
admit it's not part of our process to always validate a config file
before trying to start a service in OSA. I am not sure where other
deployment projects are in terms of that usage. I am not familiar with
upgrade checker code, but I would love to see it re-using oslo-config-
validator, as it would be the unique source of truth for upgrades
before the upgrade happens (vs having to do multiple steps).
If I am completely out of my league here, tell me.

Just my 2 cents.
Jean-Philippe Evrard (evrardjp)



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

Re: [openstack-dev] [goals][upgrade-checkers] Week R-26 Update

[Jean-Philippe Evrard]

ain multi-upgrade (jumps)
scenarios. After a while, we could think of feeding those back to
upgrade checkers.

3) I like the approach of having oslo-config-validator. However, I must
admit it's not part of our process to always validate a config file
before trying to start a service in OSA. I am not sure where other
deployment projects are in terms of that usage. I am not familiar with
upgrade checker code, but I would love to see it re-using oslo-config-
validator, as it would be the unique source of truth for upgrades
before the upgrade happens (vs having to do multiple steps).
If I am completely out of my league here, tell me.

Just my 2 cents.
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][all] Discussing goals (upgrades) with community @ office hours

[Jean-Philippe Evrard]

On Sat, 2018-10-13 at 15:04 +0200, Mohammed Naser wrote:
> I wanted to propose one of the upcoming office hours to perhaps
> invite
> some of the community members (PTL, developers, anyone!) as well as
> the TC with goal champions to perhaps discuss some of these goals to
> help everyone get a clear view on what's going on.
> 
> Does this seem like it would be of interest to the community?  I am
> currently trying to transform our office hours to be more of a space
> where we have more of the community and less of discussion between
> us.
> 

Great idea, mnaser. I think it's good if we discuss all together during
office hours!

I believe the office hours should not only be used for discussing
progress by subject-matter experts (SME), but also a place for the
community to discuss cross-team issues, and victories.

I like to have goal champions talking about progress in the next office
hours. +1!

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-dev] [tc] assigning new liaisons to projects

[Jean-Philippe Evrard]

On Mon, 2018-10-08 at 10:27 -0400, Doug Hellmann wrote:
> TC members,
> 
> Since we are starting a new term, and have several new members, we
> need
> to decide how we want to rotate the liaisons attached to each our
> project teams, SIGs, and working groups [1].
> 
> Last term we went through a period of volunteer sign-up and then I
> randomly assigned folks to slots to fill out the roster evenly.
> During
> the retrospective we talked a bit about how to ensure we had an
> objective perspective for each team by not having PTLs sign up for
> their
> own teams, but I don't think we settled on that as a hard rule.
> 
> I think the easiest and fairest (to new members) way to manage the
> list
> will be to wipe it and follow the same process we did last time. If
> you
> agree, I will update the page this week and we can start collecting
> volunteers over the next week or so.
> 
> Doug
> 
> [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker
> 
> _
> _
> 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

+1


__
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] dropping xenial jobs

[Jean-Philippe Evrard]

On Wed, 2018-10-10 at 06:50 +0200, Mohammed Naser wrote:
> Hi everyone!
> 
> So I’ve been thinking of dropping the Xenial jobs to reduce our
> overall impact in terms of gate usage in master because we don’t
> support it. 
> 
> However, I was a bit torn on this because i realize that it’s
> possible for us to write things and backport them only to find out
> that they’d break under xenial which can be deployed with Rocky. 
> 
> Thoughts?  Ideas?  I was thinking maybe Lee an experimental job.. not
> really sure on specifics but I’d like to bring in more feedback. 
> 
> Thanks,
> Mohammed
> _
> _
> 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

Hello,

In the past we removed the jobs (ocata didn't have trusty jobs, IIRC),
and made sure backports were still passing the gates of newton with
trusty jobs voting. It may force a re-implementation in lower branches,
but it is fine for me, as ansible versions also differ and might
require re-implementation anyway.

That said, we didn't have the flexibility we have now with Zuul v3, and
making the jobs voting/nv/experimental.

The middle ground would be to have a non-voting check job.
It is fine, but it consumes resources for patches that aren't supposed
to be backported, and therefore I think it's not the greatest solution.

I like the "check experimental" part. It has an inconvenient: it relies
on our good behaviour:
When a bug is raised (so first element, we should not forget the bug
link!) for backport, we should all keep in mind to check experimental
before attempting the merge on the higher branch.

That said, I still prefer the "check experimental" that nothing.
You have my vote! 

Best regards,
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-dev] [tc] bringing back formal TC meetings

[Jean-Philippe Evrard]

On Fri, 2018-10-05 at 07:40 -0400, Doug Hellmann wrote:
> Chris Dent  writes:
> 
> > On Thu, 4 Oct 2018, Doug Hellmann wrote:
> > 
> > > TC members, please reply to this thread and indicate if you would
> > > find
> > > meeting at 1300 UTC on the first Thursday of every month
> > > acceptable, and
> > > of course include any other comments you might have (including
> > > alternate
> > > times).
> > 
> > +1
> > 
> > Also, if we're going to set aside a time for a semi-formal meeting,
> > I
> > hope we will have some form of agenda and minutes, with a fairly
> > clear process for setting that agenda as well as a process for
> 
> I had in mind "email the chair your topic suggestion" and then "the
> chair emails the agenda to openstack-dev tagged [tc] a bit in advance
> of
> the meeting". There would also probably be some standing topics, like
> updates for ongoing projects.
> 
> Does that work for everyone?
> 
> 

Fine for me


__
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] Open letter/request to TC candidates (and existing elected officials)

[Jean-philippe Evrard]

mmediately ask, "would doing that get us any 
closer to achieving top technical priority x?" Because if not, or it's 
so fuzzy in scope that no one sees the way forward, document a 
decision and then drop it.
That rises a point of having global design document and decisions, so 
that we learn better. There is still a lot of tribal knowledge in 
OpenStack, and we should remove that over time by setting up the right 
processes. I'd be happy to discuss that with you to have a real/more 
complete understanding of what you mean there.


Jean-Philippe Evrard (evrardjp)

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

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

[Jean-philippe Evrard]

[...]

I respect that tool choices can make a difference in enabling or
improving our outreach to specific cultures.

I agree there.

I'll commit to
personally rejecting presence on proprietary social media services
so as to demonstrate that public work can be done within our
community while relying exclusively on free/libre open source
software.

It is nice to be in a position to do so. Please don't change! : )

I recognize the existence of the free software movement as
a distinct culture with whom we could do a better job of connecting.
If as a community we promote and embrace non-free tools we will only
continue to alienate them, [...]

I agree again with Jeremy here.

As this was a direct question for the candidates, here is my answer...

There is two layers in this conversation: a personal level, and an 
official stance on the subject (as discussed in the TC room).


At a personal level,I guess I wouldn't mind myself joining to Wechat, 
with the hope of being helpful there.
As I don't speak this language particularily, I am not sure how I can be 
more of help there than I can be with speaking an ambassador in a 
mutually common language (I am also not native english). At the same 
time, I would be very sad to not use an open tool, because I am not sure 
what the privacy implications would be. But, pragmatically, I understand 
the biggest picture here: We want to be more reachable, as increasing 
community size over time is a must for sustainable software, and if I 
can be a little help personally, I'd do it.


Before giving my opinion for an official stance as a TC candidate (the 
other layer), I'd like to ask you a few questions ...


- What is the problem joining Wechat will solve (keeping in mind the 
language barrier)?
- Isn't this problem already solved for other languages with existing 
initiatives like local ambassadors and i18n team? Why aren't these relevant?
- Should we widen this 'Wechat' initiative to all system based on location> systems?
- Pardon my ignorance here, what is the problem with email? (I 
understand some chat systems might be blocked, I thought emails would be 
fine, and the lowest common denominator).


I also have technical questions about 'wechat' (like how do you use it 
without a smartphone?) and the relevance of tools we currently use, but 
this will open Pandora's box, and I'd rather not spend my energy on 
closing that box right now :D


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] [charms] PTL non-candidacy for Stein cycle

[Jean-Philippe Evrard]

On July 27, 2018 4:09:04 PM UTC, James Page  wrote:
>Hi All
>
>I won't be standing for PTL of OpenStack Charms for this upcoming
>cycle.
>
>Its been my pleasure to have been PTL since the project was accepted
>into
>OpenStack, but its time to let someone else take the helm.   I'm not
>going
>anywhere but expect to have a bit of a different focus for this cycle
>(at
>least).
>
>Cheers
>
>James

Thanks for the work done on a cross project level and your  communication!

JP (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] [sig][upgrades][ansible][charms][tripleo][kolla][airship] reboot or poweroff?

[Jean-Philippe Evrard]

Sorry about the lack of participation too.

Monthly sounds good.

Regards,
JP

On July 24, 2018 9:34:56 AM UTC, Paul Bourke  wrote:
>Hi James,
>
>Sorry to hear about the lack of participation. I for one am guilty of 
>not taking part, there just seems to be never enough time in the day to
>
>cram in all the moving parts that a project like OpenStack requires.
>
>That being said, this effort is definitely one of the most important to
>
>the project imo, so I'm keen to step up.
>
>Moving to a monthly meeting sounds a good idea, at least till things
>get 
>back on foot. Could you share what the current times / location for the
>
>meeting is?
>
>Cheers,
>-Paul
>
>On 23/07/18 17:01, James Page wrote:
>> Hi All
>> 
>> tl;dr we (the original founders) have not managed to invest the time
>to 
>> get the Upgrades SIG booted - time to hit reboot or time to poweroff?
>> 
>> Since Vancouver, two of the original SIG chairs have stepped down 
>> leaving me in the hot seat with minimal participation from either 
>> deployment projects or operators in the IRC meetings.  In addition
>I've 
>> only been able to make every 3rd IRC meeting, so they have generally
>not 
>> being happening.
>> 
>> I think the current timing is not good for a lot of folk so finding a
>
>> better slot is probably a must-have if the SIG is going to continue -
>
>> and maybe moving to a monthly or bi-weekly schedule rather than the 
>> weekly slot we have now.
>> 
>> In addition I need some willing folk to help with leadership in the 
>> SIG.  If you have an interest and would like to help please let me
>know!
>> 
>> I'd also like to better engage with all deployment projects -
>upgrades 
>> is something that deployment tools should be looking to encapsulate
>as 
>> features, so it would be good to get deployment projects engaged in
>the 
>> SIG with nominated representatives.
>> 
>> Based on the attendance in upgrades sessions in Vancouver and 
>> developer/operator appetite to discuss all things upgrade at said 
>> sessions I'm assuming that there is still interest in having a SIG
>for 
>> Upgrades but I may be wrong!
>> 
>> Thoughts?
>> 
>> James
>> 
>> 
>> 
>> 
>> 
>> 
>>
>__
>> 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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.__
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][all] Front page template for project team documentation

[Jean-Philippe Evrard]

Is there a lint tool that can catch incoherent markup at a global project level 
(vs at a page gen level)?

Any tool to catch these issues would help.

JP.

On July 19, 2018 3:55:29 PM UTC, Petr Kovar  wrote:
>Hi all,
>
>A spin-off discussion in https://review.openstack.org/#/c/579177/
>resulted
>in an idea to update our RST conventions for headings level 2 and 3 so
>that
>our guidelines follow recommendations from
>http://docutils.sourceforge.net/docs/user/rst/quickstart.html#sections.
>
>The updated conventions also better reflect what most projects have
>been
>using already, regardless of what was previously in our conventions.
>
>To sum up, for headings level 2, use dashes:
>
>Heading 2
>-
>
>For headings level 3, use tildes:
>
>Heading 3
>~
>
>For details on the change, see:
>
>https://review.openstack.org/#/c/583239/1/doc/doc-contrib-guide/source/rst-conv/titles.rst
>
>Thanks,
>pk
>
>
>On Fri, 29 Jun 2018 16:45:53 +0200
>Petr Kovar  wrote:
>
>> Hi all,
>> 
>> Feedback from the Queens PTG included requests for the Documentation
>> Project to provide guidance and recommendations on how to structure
>common
>> content typically found on the front page for project team docs,
>located at
>> doc/source/index.rst in the project team repository.
>> 
>> I've created a new docs spec, proposing a template to be used by
>project
>> teams, and would like to ask the OpenStack community and,
>specifically, the
>> project teams, to take a look, submit feedback on the spec, share
>> comments, ideas, or concerns:
>> 
>>   https://review.openstack.org/#/c/579177/
>> 
>> The main goal of providing and using this template is to make it
>easier for
>> users to find, navigate, and consume project team documentation, and
>for
>> contributors to set up and maintain the project team docs.
>> 
>> The template would also serve as the basis for one of the future
>governance
>> docs tags, which is a long-term plan for the docs team.
>> 
>> Thank you,
>> pk
>> 
>>
>__
>> 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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.__
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] dropping selinux support

[Jean-Philippe Evrard]

This title seems very scary. It was to be read as "... for source installs" : )

To be honest, I feel very sad about the lack of involvement in CentOS
in OSA over the years.
We didn't get many contributors over time for it.
This has always been a labour of love, and the honeymoon seems over for many.

So...
Please help us if you want to keep your sourced based installs +
CentOS + selinux.
Else, you can still use packages! :D

Thanks mnaser for starting this hard topic and community decision process.

JP (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] [all] TC Report 18-26

[Jean-Philippe Evrard]

My two cents:

> I think if OpenStack wants to gain back some of the steam it had before, it 
> needs to adjust to the new world it is living in. This means:
>  * Consider abolishing the project walls. They are driving bad architecture 
> (not intentionally but as a side affect of structure)

As long as there is no walled garden, everything should be done in a
modular way. I don't think having separated nova from cinder prevented
some contributions, quite the contrary. (Optionally, watch [1]).
I am not familiar with the modularity and ease of contribution in k8s,
so the modularity could be there in a different form.

[1]: https://www.youtube.com/watch?v=xYkh1sAu0UM

>  * focus on the commons first.

Good point.

>  * simplify the architecture for ops:

Good point, but I don't see how code, org structure, or project
classification changes things here.

>  * come up with an architecture team for the whole, not the subsystem. The 
> whole thing needs to work well.

Couldn't that be done with a group TC sponsored?

>  * encourage current OpenStack devs to test/deploy Kubernetes. It has some 
> very good ideas that OpenStack could benefit from. If you don't know what 
> they are, you can't adopt them.

Good idea.

>
> And I know its hard to talk about, but consider just adopting k8s as the 
> commons and build on top of it. OpenStack's api's are good. The 
> implementations right now are very very heavy for ops. You could tie in K8s's 
> pod scheduler with vm stuff running in containers and get a vastly simpler 
> architecture for operators to deal with. Yes, this would be a major 
> disruptive change to OpenStack. But long term, I think it would make for a 
> much healthier OpenStack.

Well, I know operators that wouldn't like k8s and openstack components
on top. If you're talking about just a shim between k8s concepts and
openstack apis, that sounds like a good project : p

>> I've also argued in the past that all distro- or vendor-specific
>> deployment tools (Fuel, Triple-O, etc [3]) should live outside of
>> OpenStack because these projects are more products and the relentless
>> drive of vendor product management (rightfully) pushes the scope of
>> these applications to gobble up more and more feature space that may or
>> may not have anything to do with the core OpenStack mission (and have
>> more to do with those companies' product roadmap).
>
> I'm still sad that we've never managed to come up with a single way to
> install OpenStack. The amount of duplicated effort expended on that
> problem is mind-boggling. At least we tried though. Excluding those
> projects from the community would have just meant giving up from the
> beginning.

Well, I think it's a blessing and a curse.

Sometimes, I'd rather have only one tool, so that we all work on it, and
not dilute the community into small groups.

But when I started deploying OpenStack years ago, I was glad I could
find a community way to deploy it using ,
and not .
So for me, I am glad (what became) OpenStack-Ansible existed and I am
glad it still exists.

The effort your are talking about is not purely duplicated:
- Example: whether openstack-ansible existed or not, people used to
Ansible would still prefer deploying openstack with Ansible
  than with puppet or chef (because of their experience) if not
relying on a vendor. In that case, they would probably create
  their own series of playbooks. (I've seen some). That's the real waste, IMO.
- Deployments projects talk to each other.

Talking about living outside OpenStack, where would, for you,
OpenStack-Ansible, the puppet modules, or OpenStack-Chef be?
For OSA, I consider our community now as NOT vendor specific, as many
actors are now playing with it.
We've spent a considerable effort in outreaching and ensuring everyone
can get involved.
So we should be in openstack/ right? But what about 4 years ago? Every
project starts with a sponsor.

I am not sure a classification (is it outside, is it inside
openstack/?) matters in this case.

>
> I think Thierry's new map, that collects installer services in a
> separate bucket (that may eventually come with a separate git namespace)
> is a helpful way of communicating to users what's happening without
> forcing those projects outside of the community.

Side note: I'd be super happy if OpenStack-Ansible could be on that bucket!

Cheers,
JP (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] [ptl] PTL E-mail addresses on rendered team pages

[Jean-Philippe Evrard]

> Not sure it'd help but one option we do is to create aliases based on
> the title.  Though since the PTLs don't have addresses on the openstack
> domain an alias may not make as much sense, it'd have to be a full
> account forward.  It's useful for centralized spam filtering.

I foresee this:
1) We create an alias  to PTL email
2) PTL think that kind of emails are worth sharing with a team to balance work
3) We now have a project mailing list
4) People stop using openstack-dev lists.

But that's maybe me...

__
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

[Jean-Philippe Evrard]

I think PTLs would naturally like to have those updated, and for me a
TC +w would make sense.
But we need to have guidelines, so that's it's more tangible, and the
subtlety stays impartial.

__
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] [openstack-ansible] Restarting our very own "SIG" teams

[Jean-Philippe Evrard]

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

[Jean-Philippe Evrard]

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

[Jean-Philippe Evrard]

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

[Jean-Philippe Evrard]

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

[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

[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

[Jean-Philippe Evrard]

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

[Jean-Philippe Evrard]

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

[Jean-Philippe Evrard]

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

[Jean-Philippe Evrard]

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]

[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-dev] [all][tc][ptls] final stages of python 3 transition

[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

[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

[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

[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

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

[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

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

[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

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

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

[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

[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

[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

[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

[Jean-Philippe Evrard]

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

[Jean-Philippe Evrard]

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

[Jean-Philippe Evrard]

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?

[Jean-Philippe Evrard]

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]

[Jean-Philippe Evrard]

Hello,

That's what it always was, but it was hidden in the pages. Now that I
refactored the pages to be more visible, you spotted it :)
Congratulations!

More seriously, I'd like to remove that requirement, showing people
can do whatever they like. It all depends on how/where they store
images, ephemeral storage...

Will commit a patch today.

Best regards,
Jean-Philippe Evrard



On 15 March 2018 at 18:31, Gordon, Kent S
<kent.gor...@verizonwireless.com> wrote:
> Compute host disk requirements for Openstack Ansible seem high in the
> documentation.
>
> I think I have used smaller compute hosts in the past.
> Did something change in Queens?
>
> https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest/overview-requirements.html
>
>
> Compute hosts
>
> Disk space requirements depend on the total number of instances running on
> each host and the amount of disk space allocated to each instance.
>
> Compute hosts must have a minimum of 1 TB of disk space available.
>
>
>
>
> --
> Kent S. Gordon
> kent.gor...@verizonwireless.com Work:682-831-3601 Mobile: 817-905-6518
>
> __
> 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] [OpenStackAnsible] Tag repos as newton-eol

[Jean-Philippe Evrard]

Looks good to me.

On 15 March 2018 at 01:11, Tony Breeds <t...@bakeyournoodle.com> wrote:
> On Wed, Mar 14, 2018 at 09:40:33PM +0000, Jean-Philippe Evrard wrote:
>> Hello folks,
>>
>> The list is almost perfect: you can do all of those except
>> openstack/openstack-ansible-tests.
>> I'd like to phase out openstack/openstack-ansible-tests and
>> openstack/openstack-ansible later.
>
> Okay excluding the 2 repos above and filtering out projects that don't
> have newton branches we came down to:
>
> # EOL repos belonging to OpenStackAnsible
> eol_branch.sh -- stable/newton newton-eol \
>  openstack/ansible-hardening \
>  openstack/openstack-ansible-apt_package_pinning \
>  openstack/openstack-ansible-ceph_client \
>  openstack/openstack-ansible-galera_client \
>  openstack/openstack-ansible-galera_server \
>  openstack/openstack-ansible-haproxy_server \
>  openstack/openstack-ansible-lxc_container_create \
>  openstack/openstack-ansible-lxc_hosts \
>  openstack/openstack-ansible-memcached_server \
>  openstack/openstack-ansible-openstack_hosts \
>  openstack/openstack-ansible-openstack_openrc \
>  openstack/openstack-ansible-ops \
>  openstack/openstack-ansible-os_aodh \
>  openstack/openstack-ansible-os_ceilometer \
>  openstack/openstack-ansible-os_cinder \
>  openstack/openstack-ansible-os_glance \
>  openstack/openstack-ansible-os_gnocchi \
>  openstack/openstack-ansible-os_heat \
>  openstack/openstack-ansible-os_horizon \
>  openstack/openstack-ansible-os_ironic \
>  openstack/openstack-ansible-os_keystone \
>  openstack/openstack-ansible-os_magnum \
>  openstack/openstack-ansible-os_neutron \
>  openstack/openstack-ansible-os_nova \
>  openstack/openstack-ansible-os_rally \
>  openstack/openstack-ansible-os_sahara \
>  openstack/openstack-ansible-os_swift \
>  openstack/openstack-ansible-os_tempest \
>  openstack/openstack-ansible-pip_install \
>  openstack/openstack-ansible-plugins \
>  openstack/openstack-ansible-rabbitmq_server \
>  openstack/openstack-ansible-repo_build \
>  openstack/openstack-ansible-repo_server \
>  openstack/openstack-ansible-rsyslog_client \
>  openstack/openstack-ansible-rsyslog_server \
>  openstack/openstack-ansible-security
>
> If you confirm I have the list right this time I'll work on this tomorrow
>
> Yours Tony.
>
> __
> 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] [OpenStackAnsible] Tag repos as newton-eol

[Jean-Philippe Evrard]

Hello folks,

The list is almost perfect: you can do all of those except
openstack/openstack-ansible-tests.
I'd like to phase out openstack/openstack-ansible-tests and
openstack/openstack-ansible later.

JP

On 14 March 2018 at 21:20, Tony Breeds  wrote:
> Hi all,
> JP has asked me to to work with infra to tag the newton branches of
> the following repos as EOL:
>
>
> openstack/ansible-hardening
> openstack/openstack-ansible-apt_package_pinning
> openstack/openstack-ansible-ceph_client
> openstack/openstack-ansible-galera_client
> openstack/openstack-ansible-galera_server
> openstack/openstack-ansible-haproxy_server
> openstack/openstack-ansible-lxc_container_create
> openstack/openstack-ansible-lxc_hosts
> openstack/openstack-ansible-memcached_server
> openstack/openstack-ansible-nspawn_container_create
> openstack/openstack-ansible-nspawn_hosts
> openstack/openstack-ansible-openstack_hosts
> openstack/openstack-ansible-openstack_openrc
> openstack/openstack-ansible-os_aodh
> openstack/openstack-ansible-os_barbican
> openstack/openstack-ansible-os_ceilometer
> openstack/openstack-ansible-os_cinder
> openstack/openstack-ansible-os_designate
> openstack/openstack-ansible-os_glance
> openstack/openstack-ansible-os_gnocchi
> openstack/openstack-ansible-os_heat
> openstack/openstack-ansible-os_horizon
> openstack/openstack-ansible-os_ironic
> openstack/openstack-ansible-os_keystone
> openstack/openstack-ansible-os_magnum
> openstack/openstack-ansible-os_molteniron
> openstack/openstack-ansible-os_neutron
> openstack/openstack-ansible-os_nova
> openstack/openstack-ansible-os_octavia
> openstack/openstack-ansible-os_panko
> openstack/openstack-ansible-os_rally
> openstack/openstack-ansible-os_sahara
> openstack/openstack-ansible-os_swift
> openstack/openstack-ansible-os_tacker
> openstack/openstack-ansible-os_tempest
> openstack/openstack-ansible-os_trove
> openstack/openstack-ansible-pip_install
> openstack/openstack-ansible-pip_lock_down
> openstack/openstack-ansible-plugins
> openstack/openstack-ansible-rabbitmq_server
> openstack/openstack-ansible-repo_build
> openstack/openstack-ansible-repo_server
> openstack/openstack-ansible-rsyslog_client
> openstack/openstack-ansible-rsyslog_server
> openstack/openstack-ansible-security
> openstack/openstack-ansible-ops
> openstack/openstack-ansible-os_almanach
> openstack/openstack-ansible-os_cloudkitty
> openstack/openstack-ansible-os_congress
> openstack/openstack-ansible-os_freezer
> openstack/openstack-ansible-os_karbor
> openstack/openstack-ansible-os_monasca
> openstack/openstack-ansible-os_monasca-agent
> openstack/openstack-ansible-os_monasca-ui
> openstack/openstack-ansible-os_searchlight
> openstack/openstack-ansible-os_watcher
> openstack/openstack-ansible-os_zaqar
> openstack/openstack-ansible-specs
> openstack/openstack-ansible-tests
>
> I'll process that this week after getting an ACK from JP
>
>
> Yours Tony.
>
> __
> 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] Meetings change (PTG discussion follow-up)

[Jean-Philippe Evrard]

Hello,

We discussed the problem of the miscommunication at the PTG, and we
agreed the focus of the week solved many things for clarity.
I am not sure we need to send a ML summary, if all is recorded in the
meeting each week: people can just browse meetings for this info.

I have no strong opinion about office hours:
- it is more formal than our ad-hoc dicussions (more than necessary?).;
- it helps for timezones: We can have different office hours (US
based/Europe based) for discussing things;
- it can be reported during Tuesday's meeting.

Let's discuss this on the chan and validate next Tuesday I guess :)

Because there were no strong against the meeting time change/format we
should go ahead on the change of the community meetings.
So from now on, until daylight saving applies to Europe, we should
have the meetings on Tuesday at 5PM UTC.

Thanks everyone!



On 6 March 2018 at 16:08, Amy Marrich <a...@demarco.com> wrote:
> JP,
>
> When the Community meeting was moved to once a month there was a lot of
> resulting miscommunication as a result. If a weekly review is going to be
> sent to the mailing list with channel discussions is going to be sent out, I
> think that's a good alternative but the conversations still need to take
> place and as many people involved as possible. What about having office
> hours?
>
> Amy (spotz)
>
> On Tue, Mar 6, 2018 at 9:51 AM, Jean-Philippe Evrard
> <jean-phili...@evrard.me> wrote:
>>
>> Hello,
>>
>> During the PTG, we've discussed about changing our meetings.
>> I'd like to have a written evidence in our mailing lists, showing what
>> we discussed, and what we proposed to change. I propose we validate
>> those changes if they get no opposition in the next 7 days (deadline:
>> 13 March).
>>
>> What we discussed was:
>> - Should the meetings be rescheduled, and at what time;
>> - Should the meetings be happening in alternance for US/Europe
>> friendly timezones;
>> - What is the purpose/expected outcome of those meetings;
>> - What is the reason the attendance is low.
>>
>> The summary is the following:
>> - The expected outcome of bug triage is currently (drumroll)
>> actively triaging bugs which produces better deliverables (what a
>> surprise!).
>> - The expected outcome of the community meeting is to discuss about
>> what we actively need to work on together, but we are doing these kind
>> of conversations, ad-hoc, in the channel. So if we summarize things on
>> a regular basis to make sure everyone is aware of the conversations,
>> we should be good.
>> - The timezone friendly things won't impact the attendance positively.
>> - Right now, the Europe meetings can be postponed of one hour, but
>> decision should be re-discussed with daylight saving.
>> - A lot of ppl have meetings at 4PM UTC right now.
>>
>> As such, here is the PTG proposed change:
>> - Moving the bug triage meeting to 5PM UTC until next daylight saving
>> change.
>> - Keep the "Focus of the week" section of the bug triage, to list what
>> we discussed in the week (if more conversations have to happen, they
>> can happen just after the bug triage)
>> - Removing the community meeting.
>>
>> Any opposition there? If we are all okay, I will update our procedures
>> next week.
>>
>> Best regards,
>> 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
>
>
>
> __
> 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] [openstack-ansible] Meetings change (PTG discussion follow-up)

[Jean-Philippe Evrard]

Hello,

During the PTG, we've discussed about changing our meetings.
I'd like to have a written evidence in our mailing lists, showing what
we discussed, and what we proposed to change. I propose we validate
those changes if they get no opposition in the next 7 days (deadline:
13 March).

What we discussed was:
- Should the meetings be rescheduled, and at what time;
- Should the meetings be happening in alternance for US/Europe
friendly timezones;
- What is the purpose/expected outcome of those meetings;
- What is the reason the attendance is low.

The summary is the following:
- The expected outcome of bug triage is currently (drumroll)
actively triaging bugs which produces better deliverables (what a
surprise!).
- The expected outcome of the community meeting is to discuss about
what we actively need to work on together, but we are doing these kind
of conversations, ad-hoc, in the channel. So if we summarize things on
a regular basis to make sure everyone is aware of the conversations,
we should be good.
- The timezone friendly things won't impact the attendance positively.
- Right now, the Europe meetings can be postponed of one hour, but
decision should be re-discussed with daylight saving.
- A lot of ppl have meetings at 4PM UTC right now.

As such, here is the PTG proposed change:
- Moving the bug triage meeting to 5PM UTC until next daylight saving change.
- Keep the "Focus of the week" section of the bug triage, to list what
we discussed in the week (if more conversations have to happen, they
can happen just after the bug triage)
- Removing the community meeting.

Any opposition there? If we are all okay, I will update our procedures
next week.

Best regards,
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

[openstack-dev] [openstack-ansible] Roles not passing functional tests

[Jean-Philippe Evrard]

Dear community,

We are everyday closer to the end of the cycle, and the following
roles seem not ready for integration into the next release, because
they are failing their own gates's functional testing for more than
two weeks:
- os_ceilometer
- os_aodh
- os_trove
- os_magnum

Following the guidelines of the role maturity downgrade procedure [1],
I am sending you a list of bugs that needs fixing:
- magnum [2]
- trove [3]
- aodh [4]
- ceilometer [5]

According to the same guidelines, if nobody fixes those bugs until the
next community meeting,
those roles's maturity index will be moved to unmaintained, and will
eventually be removed from release.

Thank you for your understanding,

Jean-Philippe Evrard (evrardjp)


[1]: 
https://docs.openstack.org/openstack-ansible/latest/contributor/additional-roles.html#maturity-downgrade-procedure
[2]: https://bugs.launchpad.net/openstack-ansible/+bug/1747607
[3]: https://bugs.launchpad.net/openstack-ansible/+bug/1747608
[4]: https://bugs.launchpad.net/openstack-ansible/+bug/1747610
[5]: https://bugs.launchpad.net/openstack-ansible/+bug/1747612

__
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][ptl] PTL candidacy for Rocky

[Jean-Philippe Evrard]

Hello everyone,

I would like to announce my candidacy for PTL of the
OpenStack-Ansible project for the Rocky cycle.

I will focus on a single theme this cycle, simplification.

After all the features introduced in Queens cycle, it's time
to simplify our work:

* Reduce the amount of variables in each role, and/or rename them to
  a more guessable name.
* Make possible to use a source of truth to reduce the amount of
  glue variables we need. A candidate for source of truth could
  be etcd, due to its presence in the OpenStack reference architecture.
* Simplifying further our "repo build".
* Simplifying our tasks, by using convention over configuration
  (Reducing the group configurability for example).
* Reducing the need of our dynamic inventory: everyone
  should be able to use openstack-ansible with a simple static inventory.
* Clarify each role maturity/contributions status. This would
  make easier for deployers to understand the status of each role, and
  take the appropriate decisions to whether or not deploy project x
  or y. If we make it simple to contribute to new
  roles and playbooks, it would also open us to more contributions
  and contributors.

On top of those simplification topics, I'd like to add the following
features in the next cycle, depending on their release timing:
* Upgrade to Ansible 2.5
* Support Ubuntu 18.04

I look forward to keep working with you all, and it would be my
honor to serve as PTL for the next cycle.

Thanks for taking the time to read this and I hope to see you in Dublin,
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] Limiting pip wheel builds for OpenStack clients

[Jean-Philippe Evrard]

I added my comment/opinion on the bug.

Thanks for reporting this, Major!

__
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] Switching to longer development cycles

[Jean-Philippe Evrard]

On 13 December 2017 at 16:52, Matt Riedemann  wrote:
> On 12/13/2017 10:17 AM, Thierry Carrez wrote:
>>
>> Hi everyone,
>>
>> Over the past year, it has become pretty obvious to me that our
>> self-imposed rhythm no longer matches our natural pace. It feels like we
>> are always running elections, feature freeze is always just around the
>> corner, we lose too much time to events, and generally the impression
>> that there is less time to get things done. Milestones in the
>> development cycles are mostly useless now as they fly past us too fast.
>> A lot of other people reported that same feeling.
>
>
> On the other hand, without community-wide imposed deadlines and milestones,
> we lose some motivation for getting things done by a specific time, which
> could mean the bigger and more complicated things drag on longer because
> there isn't a deadline. One could say that we just need to be more
> disciplined, but in an open source project where there is no boss at the top
> setting that deadline and holding people to it, it's hard to be that
> disciplined. The PTL can only ask people to work on priorities so much.

We could still have community-wide milestones and deadlines.
I don't understand the point of "no boss at the top", I don't see how
it impacts.
You're right on the idea, but I don't see how the cycle length changes that.
Do you think milestones have less value/criticality than final release?

>
>>
>> As our various components mature, we have less quick-paced feature
>> development going on. As more and more people adopt OpenStack, we are
>> more careful about not breaking them, which takes additional time. The
>> end result is that getting anything done in OpenStack takes more time
>> than it used to, but we have kept our cycle rhythm mostly the same.
>>
>> Our development pace was also designed for fast development in a time
>> where most contributors were full time on OpenStack. But fewer and fewer
>> people have 100% of their time to dedicate to OpenStack upstream
>> development: a lot of us now have composite jobs or have to participate
>> in multiple communities. This is a good thing, and it will only
>> accelerate as more and more OpenStack development becomes fueled
>> directly by OpenStack operators and users.
>>
>> In another thread, John Dickinson suggested that we move to one-year
>> development cycles, and I've been thinking a lot about it. I now think
>> it is actually the right way to reconcile our self-imposed rhythm with
>> the current pace of development, and I would like us to consider
>> switching to year-long development cycles for coordinated releases as
>> soon as possible.
>>
>> What it means:
>>
>> - We'd only do one *coordinated* release of the OpenStack components per
>> year, and maintain one stable branch per year
>> - We'd elect PTLs for one year instead of every 6 months
>
>
> If we're running elections too often, we can do this without a change to a
> 1-year dev cycle.

I think it's appropriate to sync elections with cycles.

>
>> - We'd only have one set of community goals per year
>> - We'd have only one PTG with all teams each year
>
>
> This is arguably going to impact productivity, not improve it - because
> without the face time to hash out the complicated things, they drag on
> longer.
>
>>
>> What it does _not_ mean:
>>
>> - It doesn't mean we'd release components less early or less often. Any
>> project that is in feature development or wants to ship changes more
>> often is encouraged to use the cycle-with-intermediary release model and
>> release very early and very often. It just means that the minimum we'd
>> impose for mature components is one release per year instead of one
>> release every 6 months.
>
>
> I personally don't expect anyone to pick up these intermediate releases. I
> expect most consumers are going to pick up a coordinated release (several
> months or years after it's released), especially if that's what the distro
> vendors are going to be doing. So Nova could release once per quarter but I
> wouldn't expect anyone to pick it up except maybe hosting companies, but not
> even sure about that.

Our deployment project could/would rely more on upstream intermediate release,
so all our consumers would get that at the same time.

>
>>
>> - It doesn't mean that we encourage slowing down and procrastination.
>> Each project would be able to set its own pace. We'd actually encourage
>> teams to set objectives for the various (now longer) milestones in the
>> cycle, and organize virtual sprints to get specific objectives done as a
>> group. Slowing down the time will likely let us do a better job at
>> organizing the work that is happening within a cycle.
>
>
> As I said above, encouraging teams to do this and teams actually being
> disciplined enough to do it are different things. Maybe if we actually did
> the runways / slots idea from years past but as I've been reminded by people
> many times over the years, you can't 

Re: [openstack-dev] [all] Switching to longer development cycles

[Jean-Philippe Evrard]

On 13 December 2017 at 16:49, Jeremy Stanley  wrote:
> On 2017-12-13 16:45:14 + (+), Chris Jones wrote:
> [...]
>> For me the first thing that comes to mind with this proposal, is
>> how would the milestones/FF/etc be arranged within that year?
> [...]
>
> Excellent point. If it's not too much work for the Release team, it
> would be very helpful to have a straw man release schedule for a
> year-long Rocky so we can see what that might look like.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Hello,

100% agreed on all of the above.

I'd think it would be nice to move to 1 year, starting from Rocky.

Thierry, with your position it seems logical that you started this
conversation and ask for a TC vote.
I guess there will always be happy/unhappy people anyway, so a TC vote
seems good.

Best regards,
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] How to deal with MTU issue on routers servicing vxlan tenant networks? (openstack-ansible with LXC containers)

[Jean-Philippe Evrard]

Hello,

Ok thanks! Don't hesitate to ask on our channel.

FYI: In case of split brains for rabbitmq, most likely recreating
rabbit is the fastest. We are dealing with non persistent data anyway
:p

Best regards,
JP

On 12 December 2017 at 09:20, David Young <dav...@funkypenguin.co.nz> wrote:
> Hey Jean-Philippe,
>
> No, after I disasterously split-brained/partitioned my rabbitmq and galera
> clusters by allowing LXC to start the containers up without the dnsmasq
> process to address their eth0 interfaces (due to what _may_ be a
> template/Xenial bug), I've spent the last few days cleaning up the mess :)
>
> I have two unused hosts set aside as a test environment for pre-testing, and
> I'll be leveraging these in the next few days to test the issue on a fresh
> Xenial install.
>
> I'll update you (and the list) once I've positively confirmed the issue.
>
> Cheers!
> D
>
>
>
>
> On 12/12/2017 21:52, Jean-Philippe Evrard wrote:
>
> Hello David,
>
> Did you solve your issue?
> Did you check that it depends on the default container interface's mtu
> itself?
>
> Best regards,
> JP
>
>
> On 6 December 2017 at 18:45, David Young <dav...@funkypenguin.co.nz> wrote:
>
> So..
>
> On 07/12/2017 03:12, Jean-Philippe Evrard wrote:
>
> For the mtu, it would be impactful to do it on a live environment. I
> expect that if you change the container configuration, it would
> restart.
>
> It’s a busy lab environment, but given that it’s fully HA (2 controllers), I
> didn’t anticipate a significant problem with changing container
> configuration one-at-a-time.
>
> However, the change has had an unexpected side effect - one of the
> controllers (I haven’t rebooted the other one yet) seems to have lost the
> ability to bring up lxcbr0, and so while it can start all its containers,
> none of them have any management connectivity on eth0, which of course
> breaks all sorts of things.
>
> I.e.
>
> root@nbs-dh-10:~# systemctl status networking.service
> ● networking.service - Raise network interfaces
>Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor
> preset: enabled)
>   Drop-In: /run/systemd/generator/networking.service.d
>└─50-insserv.conf-$network.conf
>Active: failed (Result: exit-code) since Thu 2017-12-07 06:37:00 NZDT;
> 14min ago
>  Docs: man:interfaces(5)
>   Process: 2717 ExecStart=/sbin/ifup -a --read-environment (code=exited,
> status=1/FAILURE)
>   Process: 2656 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ]
> && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm
> settle (code=e
>  Main PID: 2717 (code=exited, status=1/FAILURE)
>
> Dec 07 06:36:58 nbs-dh-10 systemd[1]: Starting Raise network interfaces...
> Dec 07 06:36:58 nbs-dh-10 ifup[2717]: RTNETLINK answers: Invalid argument
> Dec 07 06:36:58 nbs-dh-10 ifup[2717]: /sbin/ifup: waiting for lock on
> /run/network/ifstate.enp4s0
> Dec 07 06:36:58 nbs-dh-10 ifup[2717]: /sbin/ifup: waiting for lock on
> /run/network/ifstate.br-mgmt
> Dec 07 06:37:00 nbs-dh-10 ifup[2717]: /sbin/ifup: waiting for lock on
> /run/network/ifstate.br-vlan
> Dec 07 06:37:00 nbs-dh-10 ifup[2717]: Failed to bring up lxcbr0.
> Dec 07 06:37:00 nbs-dh-10 systemd[1]: networking.service: Main process
> exited, code=exited, status=1/FAILURE
> Dec 07 06:37:00 nbs-dh-10 systemd[1]: Failed to start Raise network
> interfaces.
> Dec 07 06:37:00 nbs-dh-10 systemd[1]: networking.service: Unit entered
> failed state.
> Dec 07 06:37:00 nbs-dh-10 systemd[1]: networking.service: Failed with result
> 'exit-code'.
> root@nbs-dh-10:~#
>
> I’ve manually reversed the “lxc.network.mtu = 1550” entry in
> /etc/lxc/lxc-openstack.conf, but this doesn’t seem to have made a
> difference.
>
> What’s also odd is that lxcbr0 appears to be perfectly normal:
>
> root@nbs-dh-10:~# brctl show lxcbr0
> bridge namebridge idSTP enabledinterfaces
> lxcbr08000.fe0a7fa28303no04063403_eth0
> 075266dc_eth0
> 160c9b30_eth0
> 38ac19ae_eth0
> 4f57300f_eth0
> 59b2b5a5_eth0
> 5b7bbeb4_eth0
> 64a1fcdd_eth0
> 6c99f5fe_eth0
> 6f93ebb2_eth0
> 70ce61e5_eth0
> 745ba80d_eth0
> 85df2fa5_eth0
> 99e6adf8_eth0
> cbdfa2f3_eth0
> e15dc279_eth

Re: [Openstack-operators] How to deal with MTU issue on routers servicing vxlan tenant networks? (openstack-ansible with LXC containers)

[Jean-Philippe Evrard]

Hello David,

Did you solve your issue?
Did you check that it depends on the default container interface's mtu itself?

Best regards,
JP


On 6 December 2017 at 18:45, David Young <dav...@funkypenguin.co.nz> wrote:
> So..
>
> On 07/12/2017 03:12, Jean-Philippe Evrard wrote:
>
> For the mtu, it would be impactful to do it on a live environment. I
> expect that if you change the container configuration, it would
> restart.
>
> It’s a busy lab environment, but given that it’s fully HA (2 controllers), I
> didn’t anticipate a significant problem with changing container
> configuration one-at-a-time.
>
> However, the change has had an unexpected side effect - one of the
> controllers (I haven’t rebooted the other one yet) seems to have lost the
> ability to bring up lxcbr0, and so while it can start all its containers,
> none of them have any management connectivity on eth0, which of course
> breaks all sorts of things.
>
> I.e.
>
> root@nbs-dh-10:~# systemctl status networking.service
> ● networking.service - Raise network interfaces
>Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor
> preset: enabled)
>   Drop-In: /run/systemd/generator/networking.service.d
>└─50-insserv.conf-$network.conf
>Active: failed (Result: exit-code) since Thu 2017-12-07 06:37:00 NZDT;
> 14min ago
>  Docs: man:interfaces(5)
>   Process: 2717 ExecStart=/sbin/ifup -a --read-environment (code=exited,
> status=1/FAILURE)
>   Process: 2656 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ]
> && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm
> settle (code=e
>  Main PID: 2717 (code=exited, status=1/FAILURE)
>
> Dec 07 06:36:58 nbs-dh-10 systemd[1]: Starting Raise network interfaces...
> Dec 07 06:36:58 nbs-dh-10 ifup[2717]: RTNETLINK answers: Invalid argument
> Dec 07 06:36:58 nbs-dh-10 ifup[2717]: /sbin/ifup: waiting for lock on
> /run/network/ifstate.enp4s0
> Dec 07 06:36:58 nbs-dh-10 ifup[2717]: /sbin/ifup: waiting for lock on
> /run/network/ifstate.br-mgmt
> Dec 07 06:37:00 nbs-dh-10 ifup[2717]: /sbin/ifup: waiting for lock on
> /run/network/ifstate.br-vlan
> Dec 07 06:37:00 nbs-dh-10 ifup[2717]: Failed to bring up lxcbr0.
> Dec 07 06:37:00 nbs-dh-10 systemd[1]: networking.service: Main process
> exited, code=exited, status=1/FAILURE
> Dec 07 06:37:00 nbs-dh-10 systemd[1]: Failed to start Raise network
> interfaces.
> Dec 07 06:37:00 nbs-dh-10 systemd[1]: networking.service: Unit entered
> failed state.
> Dec 07 06:37:00 nbs-dh-10 systemd[1]: networking.service: Failed with result
> 'exit-code'.
> root@nbs-dh-10:~#
>
> I’ve manually reversed the “lxc.network.mtu = 1550” entry in
> /etc/lxc/lxc-openstack.conf, but this doesn’t seem to have made a
> difference.
>
> What’s also odd is that lxcbr0 appears to be perfectly normal:
>
> root@nbs-dh-10:~# brctl show lxcbr0
> bridge namebridge idSTP enabledinterfaces
> lxcbr08000.fe0a7fa28303no04063403_eth0
> 075266dc_eth0
> 160c9b30_eth0
> 38ac19ae_eth0
> 4f57300f_eth0
> 59b2b5a5_eth0
> 5b7bbeb4_eth0
> 64a1fcdd_eth0
> 6c99f5fe_eth0
> 6f93ebb2_eth0
> 70ce61e5_eth0
> 745ba80d_eth0
> 85df2fa5_eth0
> 99e6adf8_eth0
> cbdfa2f3_eth0
> e15dc279_eth0
> ea67ce7e_eth0
> ed5c7af9_eth0
> root@nbs-dh-10:~#
>
> … But, no matter the value of lxc.network.mtu, it doesn’t change from 1500
> (I suppose this could actually have reduced itself based on the lower MTUs
> of the member interfaces though):
>
> root@nbs-dh-10:~# ifconfig lxcbr0
> lxcbr0Link encap:Ethernet  HWaddr fe:0c:5d:1c:36:da
>   inet addr:10.0.3.1  Bcast:10.0.3.255  Mask:255.255.255.0
>   inet6 addr: fe80::f4b0:bff:fec3:63b0/64 Scope:Link
>   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>   RX packets:499 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1000
>   RX bytes:128882 (128.8 KB)  TX bytes:828 (828.0 B)
>
> root@nbs-dh-10:~#
>
> Any debugging suggestions?
>
> Thanks,
> D

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

Re: [openstack-dev] [E] [openstack-ansible] Cannot connect to proxy server from infra1-repo-container

[Jean-Philippe Evrard]

So all the nodes need to reach it, on the management network.

Here you are a little early in the steps, you can't install the repo
server because you don't have connectivity in your containers. That
shouldn't happen. You have maybe a misconfiguration, or something
happened to your containers that ended up with no IP assigned on the
containers.
Maybe try to restart your repo container, see if it works better. Else
I'd advise to debug this problem a little more in depth.

You could join us on our irc channel #openstack-ansible for help.

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-operators] How to deal with MTU issue on routers servicing vxlan tenant networks? (openstack-ansible with LXC containers)

[Jean-Philippe Evrard]

gt; container_interface: "eth10"
> container_mtu: "9000"
> ip_from_q: "tunnel"
> type: "vxlan"
> range: "1:1000"
> net_name: "vxlan"
> group_binds:
>   - neutron_linuxbridge_agent
> - network:
> container_bridge: "br-vlan"
> container_type: "veth"
> container_interface: "eth12"
> host_bind_override: "eth12"
> type: "flat"
> net_name: "flat"
> group_binds:
>   - neutron_linuxbridge_agent
> - network:
> container_bridge: "br-vlan"
> container_type: "veth"
> container_interface: "eth11"
> type: "vlan"
> range: "1:4094"
> net_name: "vlan"
> group_binds:
>   - neutron_linuxbridge_agent
> - network:
> container_bridge: "br-storage"
> container_type: "veth"
> container_interface: "eth2"
> ip_from_q: "storage"
> type: "raw"
> group_binds:
>   - glance_api
>   - cinder_api
>   - cinder_volume
>   - nova_compute
>   - swift_proxy
>
> Here are a few things I watch for mtu related discussions:
> 1) ``lxc_net_mtu``: It is used in lxc_hosts to define the lxc bridge.
>
> Aha. I didn’t know about this, it sounds like what I need. I’ll add this and
> report back.
>
> 2) Your compute nodes and your controller nodes need to have
> consistent mtus on their bridges.
>
> They are both configured for an MTU of 9000, but the controller nodes
> bridges’ drop their MTU to 1500 when the veth interface paired with the
> neutron-agent LXC container is joined to the bridge (bridges downgrade their
> MTU to the MTU of the lowest participating interface)
>
> 3) Neutron needs a configuration override.
>
> I’ve set this in neutron.conf on all neutron LXC containers, and on the
> compute nodes too:
> global_physnet_mtu = 1550
>
> And likewise in /etc/neutron/plugins/ml2/ml2_conf.ini:
>
> # Set a global MTU of 1550 (to allow VXLAN at 1500)
> path_mtu = 1550
>
> # Drop VLAN and FLAT providers back to 1500, to align with outside FWs
> physical_network_mtus = vlan:1500,flat:1500
>
> 4) the lxc containers need to be properly defined: each network should
> have a mtu defined, or alternatively, you can define a default mtu for
> all the networks defined in openstack_user_config with
> ``lxc_container_default_mtu``. (This one is the one that spawns up the
> veth pair to the lxc container)
>
> I didn’t know about this one either, it didn’t exist in any of the default
> ansible-provided sample configs, but now that I’ve grepped in the ansible
> roles for “mtu”, it’s obvious. I’ll try this too.
>
> root@nbs-dh-09:~# grep -ri lxc_container_default_mtu /etc/openstack_deploy/*
> root@nbs-dh-09:~# grep -ri lxc_container_default_mtu /etc/ansible/
> /etc/ansible/roles/lxc_container_create/defaults/main.yml:lxc_container_default_mtu:
> "1500"
> /etc/ansible/roles/lxc_container_create/templates/container-interface.ini.j2:lxc.network.mtu
> = {{ item.value.mtu|default(lxc_container_default_mtu) }}
> /etc/ansible/roles/lxc_container_create/templates/debian-interface.cfg.j2:
> mtu {{ item.value.mtu|default(lxc_container_default_mtu) }}
> /etc/ansible/roles/lxc_container_create/templates/rhel-interface.j2:MTU={{
> item.value.mtu|default(lxc_container_default_mtu) }}
> root@nbs-dh-09:~#
>
> 5) The container interfaces need to have this proper mtu. This is
> taking the same configuration as 4) above, so it should work out of
> the box.
>
> Agreed, that seems to be the case currently with 1500, I’d expect it to be
> true with the updated value
>
> 6) If your instance is reaching its router with no mtu issue, you may
> still have issues for the Northbound trafic. Check how you configured
> this northbound and if the interfaces have proper mtu. If there are
> veth pairs to create pseudo links, check their mtus too.
>
> I think it's a good start for the conversation...
>
> Thank you, this is very helpful. I’ll give it a try and respond.
>
> Re #1 and #4, do I need to destroy / recreate my existing LXC containers, or
> will rerunning the playbooks be enough to update the MTUs?
>
> Many thanks,
> David


Hello,

For the mtu, it would be impactful to do it on a live environment. I
expect that if you change the container configuration, it would
restart.

Could you please tell me if this configuration was good enough for
your use case?
Or if the docs need adapting?

If this still doesn't work, maybe you should file a bug with your new
openstack_user_config
and the appropriate user_*.yml file. That would follow our bug triage
process where more ppl can have a look at the issue.

As usual, don't hesitate to come on our irc channel #openstack-ansible
if you have further questions!

Thank you!

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

Re: [openstack-dev] [all] Dublin PTG format

[Jean-Philippe Evrard]

On 29 November 2017 at 03:20, Masayuki Igawa  wrote:
> On 11/28, Ghanshyam Mann wrote:
>> Mon-Tue/Wed-Fri works as most suitable format. There are always
>> conflict for many of us but that can be adjusted by working with team
>> planning.
>>
>> Another thing can help is to give flexibility to team to have team
>> topic even on Mon-Tue, which mean team need dedicated room on Mon-Tue
>> also. For example, if QA want to discuss few of the topic on Mon-Tue
>> and have Code sprint/Help room etc on rest of week. This can help me
>> or other QA members to join other team discussion on Wed-Fri. But that
>> is based on special request and team requirement of number of topics
>> to discuss.
>>
>> morning/afternoon format will be little hectic and less productive due
>> to changing rooms and topic etc, at least for me :)
>
> Yeah, I totally agree with that. Regarding to the QA team members,
> most of members are not dedicated to the upstream work. So, if we can
> concentrate on it during the rest of 3 days, the days could be really
> productive. And I felt it in the past PTG.
>
> -- Masayuki
>
>
>>
>> -gmann
>>
>>
>> On Mon, Nov 27, 2017 at 7:58 PM, Thierry Carrez  
>> wrote:
>> > Hi everyone,
>> >
>> > We are in the final step in the process of signing the contract with the
>> > PTG venue. We should be able to announce the location this week !
>> >
>> > So it's time to start preparing. We'll have 5 days, like in Denver. One
>> > thing we'd like to change for this round is to give a bit more
>> > flexibility in the topics being discussed, especially in the first two 
>> > days.
>> >
>> > In Denver, we selected a number of general "themes" and gave them all a
>> > room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a
>> > project team meeting could get a room for 2 or 3 days on
>> > Wednesday-Friday. That resulted in a bit of flux during the first two
>> > days, with a lot of empty rooms as most of the themes did not really
>> > need 2 days, and a lot of conflicts were present.
>> >
>> > For Dublin, the idea would be to still predetermine topics (themes and
>> > teams) and assign them rooms in advance. But we would be able to assign
>> > smaller amounts of time (per half-day) based on the expressed needs.
>> > Beyond those pre-assigned themes/teams we'd add flexibility for other
>> > groups to book the remaining available rooms in 90-min slots on-demand.
>> > A bit like how we did reservable rooms in the past, but more integrated
>> > with the rest of the event. It would all be driven by the PTGbot, which
>> > would show which topic is being discussed in which room, in addition to
>> > the current discussion subject within each topic.
>> >
>> > We have two options in how we do the split for predetermined topics. We
>> > used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The
>> > general idea there was to allow some people only interested in a team
>> > meeting to only attend the second part of the week. However most people
>> > attend all 5 days, and during event feedback some people suggested that
>> > "themes" should be in the mornings and "teams" in the afternoons (and
>> > all Friday).
>> >
>> > What would be your preference ? The Mon-Tue/Wed-Fri split means less
>> > room changes, which make it easier on the events team. So all else being
>> > equal we'd rather keep it the way it is, but I'm open to changing it if
>> > attendees think it's a good idea.
>> >
>> > If you have any other suggestion (that we could implement in the 3
>> > months we have between now and the event) please let me know :)
>> >
>> > --
>> > Thierry Carrez (ttx)
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
>
> __
> OpenStack 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
>

I like the 2+3 days format. I'd prefer that to fragmenting. If people
want to roam around they are free.
On top of that PTG bot is a helper to find what's going to happen next.

I heard once (ok, maybe more than once): "If it ain't broke, don't fix it"!

Best regards,
JP

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [all] Community managed tech/dev blog: Call for opinions and ideas

[Jean-Philippe Evrard]

On 29 November 2017 at 11:30, Thierry Carrez  wrote:
> Jimmy McArthur wrote:
>> Thierry Carrez wrote:
>>> Historically blog.o.o used to be our only blog outlet, so almost
>>> anything would go in:
>>>
>>> "OpenStack Events Sponsorship Webinar"
>>> "New Foundation Gold Members & Corporate Sponsors"
>>> "HP Announces Private Beta Program for OpenStack Cloud"
>>> "2016 OpenStack T-Shirt Design Contest"
>>>
>>> What Josh wants is a curated technical blog, so if we reused blog.o.o
>>> for this (and I think it's a good idea), we'd likely want to have a bit
>>> more rules on what's appropriate.
>>
>> Agreed. It's almost solely used for developer digest now and isn't
>> frequently updated. Most of the promotion of sponsors and news goes into
>> o.o/News, SuperUser, or one of our other marketing channels. It's a good
>> time for the community to repurpose it :)
>
> Perfect, we have a plan.
>
> Before we make it tech-only and boring, let us all take a minute to
> remember the OpenStack jingle:
>
> https://www.openstack.org/blog/2011/07/openstack-the-best-sounding-cloud/

I haven't moved. Then I laughed. Thanks for that share Thierry!

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

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

Re: [Openstack-operators] Openstack release compatibility

[Jean-Philippe Evrard]

Hello,

OpenStack-Ansible Mitaka deploys Linux Bridge by default.
This would still happen, but as said, it's not too big of a deal too.

Best regards,
Jean-Philippe (evrardjp)

On 6 November 2017 at 08:10, Kevin Benton <ke...@benton.pub> wrote:
> The Neutron OVS agent should not cause interrupts on restart in the later
> versions (Liberty+ https://review.openstack.org/#/c/215596/) of OpenStack
> since they don't destroy old flows until the new ones are setup so you
> should be able to safely do that.
>
> On Fri, Nov 3, 2017 at 9:22 AM, Jean-Philippe Evrard
> <jean-phili...@evrard.me> wrote:
>>
>> Hello,
>>
>> I think you'll face end user downtime anyway, due to _at least_
>> neutron agents flapping. But yes it can be fairly limited.
>> I can't say for restart or no restart. I think it's possible to do
>> without restarting, but I also think you should have plan for the
>> restarts, else how do you do your critical security updates for things
>> like kernel?
>>
>> Just my 2 cents, it's probably good to have other opinions out there.
>>
>> Best regards,
>> Jean-Philippe Evrard (evrardjp)
>>
>> On 3 November 2017 at 13:19, haad <haa...@gmail.com> wrote:
>> > Hi,
>> >
>> > I have one additional question. What is your experience with updating
>> > OpenStack in place on compute nodes with out rebooting them. Can we
>> > update
>> > e.g. mitaka to newton and leave machines running on compute node running
>> > ?
>> > (if libvirt/kvm/os update is necessary we can do it after.)
>> >
>> > On Fri, Nov 3, 2017 at 8:22 AM, Jean-Philippe Evrard
>> > <jean-phili...@evrard.me> wrote:
>> >>
>> >> On 2 November 2017 at 18:17, Chris Friesen
>> >> <chris.frie...@windriver.com>
>> >> wrote:
>> >> > On 10/31/2017 01:13 AM, haad wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> We have an OSA installation with 10-12 compute nodes running Mitaka
>> >> >> on
>> >> >> Ubuntu
>> >> >> 16.04. As initially we have not prepared any long term update
>> >> >> strategy
>> >> >> we
>> >> >> would
>> >> >> like to create one now. Plan would be to upgrade it to new OSA
>> >> >> release(Ocata/Pike/Queens) in near future.
>> >> >>
>> >> >> Our original plan was to update management/networking/backend at
>> >> >> once
>> >> >> by
>> >> >> using
>> >> >> rolling updates to newer release and then upgrade compute nodes one
>> >> >> by
>> >> >> one
>> >> >> to
>> >> >> new release.. I think that [2] provides a general upgrade manual. Is
>> >> >> there
>> >> >> any
>> >> >> document describing how are different OSA releases compatible ? Is
>> >> >> there
>> >> >> any
>> >> >> policy in place about backward compatibility ?
>> >> >
>> >> >
>> >> > As a general rule, OpenStack only supports an online upgrade of one
>> >> > version
>> >> > at a time.  That is, controller nodes running version N can talk to
>> >> > compute
>> >> > nodes running version N-1.
>> >> >
>> >> > If you can tolerate downtime of the API layer, there has been some
>> >> > discussion around "skip-level" upgrades.
>> >> >
>> >> > Chris
>> >> >
>> >> >
>> >> >
>> >> > ___
>> >> > OpenStack-operators mailing list
>> >> > OpenStack-operators@lists.openstack.org
>> >> >
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >>
>> >> Hello,
>> >>
>> >> Having worked on "skip level" upgrades, I can tell you that it's
>> >> simpler to do the upgrades in a row, because it's a more tested path.
>> >>
>> >> 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
>> >
>> >
>> >
>> >
>> > --
>> >
>> >
>> > Regards.
>> >
>> > Adam
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>

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

Re: [Openstack-operators] Openstack release compatibility

[Jean-Philippe Evrard]

Hello,

I think you'll face end user downtime anyway, due to _at least_
neutron agents flapping. But yes it can be fairly limited.
I can't say for restart or no restart. I think it's possible to do
without restarting, but I also think you should have plan for the
restarts, else how do you do your critical security updates for things
like kernel?

Just my 2 cents, it's probably good to have other opinions out there.

Best regards,
Jean-Philippe Evrard (evrardjp)

On 3 November 2017 at 13:19, haad <haa...@gmail.com> wrote:
> Hi,
>
> I have one additional question. What is your experience with updating
> OpenStack in place on compute nodes with out rebooting them. Can we update
> e.g. mitaka to newton and leave machines running on compute node running ?
> (if libvirt/kvm/os update is necessary we can do it after.)
>
> On Fri, Nov 3, 2017 at 8:22 AM, Jean-Philippe Evrard
> <jean-phili...@evrard.me> wrote:
>>
>> On 2 November 2017 at 18:17, Chris Friesen <chris.frie...@windriver.com>
>> wrote:
>> > On 10/31/2017 01:13 AM, haad wrote:
>> >>
>> >> Hi,
>> >>
>> >> We have an OSA installation with 10-12 compute nodes running Mitaka on
>> >> Ubuntu
>> >> 16.04. As initially we have not prepared any long term update strategy
>> >> we
>> >> would
>> >> like to create one now. Plan would be to upgrade it to new OSA
>> >> release(Ocata/Pike/Queens) in near future.
>> >>
>> >> Our original plan was to update management/networking/backend at once
>> >> by
>> >> using
>> >> rolling updates to newer release and then upgrade compute nodes one by
>> >> one
>> >> to
>> >> new release.. I think that [2] provides a general upgrade manual. Is
>> >> there
>> >> any
>> >> document describing how are different OSA releases compatible ? Is
>> >> there
>> >> any
>> >> policy in place about backward compatibility ?
>> >
>> >
>> > As a general rule, OpenStack only supports an online upgrade of one
>> > version
>> > at a time.  That is, controller nodes running version N can talk to
>> > compute
>> > nodes running version N-1.
>> >
>> > If you can tolerate downtime of the API layer, there has been some
>> > discussion around "skip-level" upgrades.
>> >
>> > Chris
>> >
>> >
>> >
>> > ___
>> > OpenStack-operators mailing list
>> > OpenStack-operators@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>> Hello,
>>
>> Having worked on "skip level" upgrades, I can tell you that it's
>> simpler to do the upgrades in a row, because it's a more tested path.
>>
>> 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
>
>
>
>
> --
>
>
> Regards.
>
> Adam

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

Re: [Openstack-operators] Openstack release compatibility

[Jean-Philippe Evrard]

On 2 November 2017 at 18:17, Chris Friesen <chris.frie...@windriver.com> wrote:
> On 10/31/2017 01:13 AM, haad wrote:
>>
>> Hi,
>>
>> We have an OSA installation with 10-12 compute nodes running Mitaka on
>> Ubuntu
>> 16.04. As initially we have not prepared any long term update strategy we
>> would
>> like to create one now. Plan would be to upgrade it to new OSA
>> release(Ocata/Pike/Queens) in near future.
>>
>> Our original plan was to update management/networking/backend at once by
>> using
>> rolling updates to newer release and then upgrade compute nodes one by one
>> to
>> new release.. I think that [2] provides a general upgrade manual. Is there
>> any
>> document describing how are different OSA releases compatible ? Is there
>> any
>> policy in place about backward compatibility ?
>
>
> As a general rule, OpenStack only supports an online upgrade of one version
> at a time.  That is, controller nodes running version N can talk to compute
> nodes running version N-1.
>
> If you can tolerate downtime of the API layer, there has been some
> discussion around "skip-level" upgrades.
>
> Chris
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Hello,

Having worked on "skip level" upgrades, I can tell you that it's
simpler to do the upgrades in a row, because it's a more tested path.

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] Sydney summit -- We'll be there!

[Jean-Philippe Evrard]

Hello everyone,

A small delegation of our openstack-ansible team will be in Sydney,
and we are looking forward to meeting all of you!

We'll have an ops feedback session during the forum happening on
Monday 6th, 1:30 pm - 2:10 pm.

If you're willing to get started with openstack-ansible, contribute,
or get to know us, please join us on Tuesday 7th,  9:50 - 10:30 AM.

Last, but not least, if you want to know what happened in
openstack-ansible in the last cycle(s) or if you're interested by our
future strategy, that would be on Tuesday 7th, 5:50 pm - 6:10 pm
during our traditional "Project Update" session.

I am looking forward meeting all of you!

Best regards,
Jean-Philippe Evrard (evrardjp)

PS: We have an etherpad listing all these activities and more details
about the ops session here:
https://etherpad.openstack.org/p/osa-sydney-summit-planning

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

[openstack-dev] [openstack-ansible] Sydney summit -- We'll be there!

[Jean-Philippe Evrard]

Hello everyone,

A small delegation of our openstack-ansible team will be in Sydney,
and we are looking forward to meeting all of you!

We'll have an ops feedback session during the forum happening on
Monday 6th, 1:30 pm - 2:10 pm.

If you're willing to get started with openstack-ansible, contribute,
or get to know us, please join us on Tuesday 7th,  9:50 - 10:30 AM.

Last, but not least, if you want to know what happened in
openstack-ansible in the last cycle(s) or if you're interested by our
future strategy, that would be on Tuesday 7th, 5:50 pm - 6:10 pm
during our traditional "Project Update" session.

I am looking forward meeting all of you!

Best regards,
Jean-Philippe Evrard (evrardjp)

PS: We have an etherpad listing all these activities and more details
about the ops session here:
https://etherpad.openstack.org/p/osa-sydney-summit-planning

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

[Jean-Philippe Evrard]

On 31 October 2017 at 07:13, haad <haa...@gmail.com> wrote:
> Hi,
>
> We have an OSA installation with 10-12 compute nodes running Mitaka on
> Ubuntu 16.04. As initially we have not prepared any long term update
> strategy we would like to create one now. Plan would be to upgrade it to new
> OSA release(Ocata/Pike/Queens) in near future.
>
> Our original plan was to update management/networking/backend at once by
> using rolling updates to newer release and then upgrade compute nodes one by
> one to new release.. I think that [2] provides a general upgrade manual. Is
> there any document describing how are different OSA releases compatible ? Is
> there any policy in place about backward compatibility ?
>
>
>
> [1] https://etherpad.openstack.org/p/osa-newton-xenial-upgrade
> [2] https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime
>
> --
>
>
> Regards.
>
> Adam
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

Hello,

I'd advise you to follow the standard OpenStack-Ansible path, which is
upgrading from Mitaka to Newton, then do your ubuntu upgrade to
xenial.
From Newton onwards, we have code taking care of the rolling part of
the upgrade, which should help you getting to Pike, after a series of
upgrades (N->O->P) under ubuntu 16.04.

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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Jean-Philippe Evrard]

t;>>>> considering doing first, because I realized it could bring confusion
>>>>>> in which projects actually follow the real stable policy and the ones
>>>>>> who have exceptions.
>>>>>> That's why I thought having a dedicated tag would help to separate
>>>>>> them.
>>>>>>
>>>>>> Proposal 3: no change anywhere, projects like installer can't claim
>>>>>> stability etiquette (not my best option in my opinion).
>>>>>>
>>>>>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
>>>>>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
>>>>>> this need), please get involved in the review process.
>>>>>
>>>>>
>>>>> My preference goes to proposal 1, however rather than call it "relaxed"
>>>>> I would make it specific to deployment/lifecycle or cycle-trailing
>>>>> projects.
>>>>>
>>>>> Ideally this policy could get adopted by any such project. The
>>>>> discussion started on the review and it's going well, so let's see
>>>>> where
>>>>> it goes :)
>>>>
>>>>
>>>> Thierry, when I read your comment on Gerrit I understand you prefer to
>>>> amend the existing policy and just make a note for installers (which
>>>> is I think the option #2 that I proposed). Can you please confirm
>>>> that?
>>>> So far I see option #1 has large consensus here, I'll wait for
>>>> Thierry's answer to continue to work on it.
>>>>
>>>> Thanks for the feedback so far!
>>>> --
>>>> 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
>>
>>
>>
>>
>> --
>> 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
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

I'll be there too.

@evrardjp
Jean-Philippe Evrard

__
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] Preping for the stable/newton EOL

[Jean-Philippe Evrard]

On 25 October 2017 at 03:57, Tony Breeds <t...@bakeyournoodle.com> wrote:
> On Tue, Oct 24, 2017 at 05:11:15PM +1100, Tony Breeds wrote:
>> On Fri, Oct 06, 2017 at 10:15:56AM +1100, Tony Breeds wrote:
>> > On Wed, Oct 04, 2017 at 02:51:06PM +1100, Tony Breeds wrote:
>> > > I'll prep the list of repos that will be tagged EOL real soon now for
>> > > review.
>> >
>> > As promised here's the list.  The fomat is new, It's grouped by project
>> > team so it should be easy for teams to find repos they care about.
>> >
>> > The only wart may be repos I couldn't find an owning team for, so check
>> > the '-' as the owning team.
>> >
>> > I'm proposing to EOL all projects that meet one or more of the following
>> > criteria:
>> >
>> > - The project is openstack-dev/devstack, openstack-dev/grenade or
>> >   openstack/requirements (although these wil be done last)
>> > - The project has the 'check-requirements' job listed as a template in
>> >   project-config:zuul/layout.yaml
>> > - The project gates with either devstack or grenade jobs
>> > - The project is listed in governance:reference/projects.yaml and is tagged
>> >   with 'stable:follows-policy'.
>> >
>> >
>> > Based on previous cycles I have opted out:
>> > - 'openstack/group-based-policy'
>> > - 'openstack/openstack-ansible' # So they can add EOL tags
>> >
>> > Also based on recent email's with tripleo I have opted out:
>> > - 'openstack/instack'
>> > - 'openstack/instack-undercloud'
>> > - 'openstack/os-apply-config'
>> > - 'openstack/os-collect-config'
>> > - 'openstack/os-net-config'
>> > - 'openstack/os-refresh-config'
>> > - 'openstack/puppet-tripleo'
>> > - 'openstack/python-tripleoclient'
>> > - 'openstack/tripleo-common'
>> > - 'openstack/tripleo-heat-templates'
>> > - 'openstack/tripleo-puppet-elements'
>> > - 'openstack/tripleo-validations'
>> > - 'openstack/tripleo-image-elements'
>> > - 'openstack/tripleo-ui'
>>
>> I've also removed the following repos as the have open release requests
>> for stable/newton
>>  - openstack/nova
>>  - openstack/ironic
>>  - openstack/openstack-ansible*
>>
>> And at the request of the docs team I've omitted:
>>  - openstack/openstack-manuals
>>
>> to facilitate 'badging' of the newton docs.
>
> The repos listed in 
> http://lists.openstack.org/pipermail/openstack-dev/2017-October/123910.html
> have been retired.
>
> There were a couple of issues
> - openstack/deb-python-os-cloud-config
> - openstack/bareon
> My clones of both had stale gerrit remotes that has been corrected
> manually.
>
> The timing of the next phase is uncertain right now but I'd like to take
> care of:
>
> - openstack/nova
> - openstack/ironic
> - openstack/openstack-ansible*
> - openstack/openstack-manuals
>
> before the summit if possible.
>
> Thanks to the infra team for enabling this to happen today.
>
> Tony.
>
> __
> 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
>

Hello Tony,

We'd like to continue doing as before: updating all our upstream
projects to their EOL tag, then creating an EOL release based on our
roles that would successfully deploy those EOL upstream projects.
If any role need a change, due to latest upstream changes, we need to be ready.

TL:DR; I'll submit a patch soon to bump our upstream roles to EOL,
when nova/ironic will have their EOL tag :p

Best regards,
Jean-Philippe Evrard (evrardjp)

PS: The existing newton release to review was the last bump before
EOL, and was submitted during EOL week IIRC. It's good to keep it,
this way we are still following our release train, while some EOL tags
are not yet issued.

__
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][Elections] Vote Vote Vote in the TC election!

[Jean-Philippe Evrard]

On 20 October 2017 at 22:25, Kendall Nelson <kennelso...@gmail.com> wrote:
>
> Hello!
>
> We are coming down to the last hours for voting in the TC election. Voting
> ends 23:45 October 20th, 2017.
>
> Search your gerrit preferred email address[0] for the following subject:
> Poll: Queens TC Election
>
> That is your ballot and links you to the voting application. Please vote. If
> you have voted, please encourage your colleagues to vote.
>
> Candidate statements are linked to the names of all confirmed candidates:
> http://governance.openstack.org/election/#pike-tc-candidates
>
> What to do if you don't see the email and have a commit in at least one of
> the official programs projects[1]:
>   * check the trash of your gerrit Preferred Email address[0], in case it
> went into trash or spam
>   * wait a bit and check again, in case your email server is a bit slow
>   * find the sha of at least one commit from the program project repos[1]
> and email the election officials[2]. If we can confirm that you are entitled
> to vote, we will add you to the voters list and you will be emailed a
> ballot.
>
> Please vote!
>
> Thank you,
>
> Kendall Nelson (diablo_rojo)
>
> [0] Sign into review.openstack.org: Go to Settings > Contact
> Information. Look at the email listed as your Preferred Email.
> That is where the ballot has been sent.
> [1]:https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=oct-2017-elections
> [2] http://governance.openstack.org/election/#election-officials
>
>
> __
> 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
>

Hello,

Thanks Kendall and the elections team.
It looks the reminders have paid off :)

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] [all] [elections] Technical Committee Election Results

[Jean-Philippe Evrard]

On 21 October 2017 at 01:20, Tony Breeds <t...@bakeyournoodle.com> wrote:
>
> Hi All,
> With the election behind us it's somewhat traditional to look at
> some simple stats from the elections:
>
> +--+---+---+---+
> | Election | Electorate  (delta %) | Voted   (delta %) | Turnout %   (delta 
> %) |
> +--+---+---+---+
> |  10/2013 |   1106  (nan) |   342   (nan) | 30.92   (
> nan) |
> |  04/2014 |   1510  (  36.53) |   448   (  30.99) | 29.67   (  
> -4.05) |
> |  10/2014 |   1893  (  25.36) |   506   (  12.95) | 26.73   (  
> -9.91) |
> |  04/2015 |   2169  (  14.58) |   548   (   8.30) | 25.27   (  
> -5.48) |
> |  10/2015 |   2759  (  27.20) |   619   (  12.96) | 22.44   ( 
> -11.20) |
> |  04/2016 |   3284  (  19.03) |   652   (   5.33) | 19.85   ( 
> -11.51) |
> |  10/2016 |   3517  (   7.10) |   801   (  22.85) | 22.78   (  
> 14.71) |
> |  04/2017 |   3191  (  -9.27) |   427   ( -46.69) | 13.38   ( 
> -41.25) |
> |  10/2017 |   2430  ( -23.85) |   420   (  -1.64) | 17.28   (  
> 29.16) |
> +--+---+---+---+
>
> Election CIVS links
>  10/2014: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4
>  04/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688
>  10/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4ef58718618691a0
>  04/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
>  10/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010
>  04/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_072c4cd7ff0673b5
>  10/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae
>
> I don't have a feel for with the Pike electorate decreased but my gut
> feel is that it was organic drop-off possibly in part to the shorter
> Ocata development cycle.  The Queens drop-off was due to a new[1]
> membership API being available that meant we could validate Foundation
> membership instead of using gerrit permission as a proxy.
>
> I'd like to call out that with Pike we had a very dramatic decrease in
> voter turnout both in absolute and relative terms.  As a community it's
> worth trying to understand whether this is a problem and/or a trend that
> needs to change.
>
> Yours Tony.
>
> [1] It wasn't that new it was also used during the PTL election[2]
> [2] See:
> http://lists.openstack.org/pipermail/openstack-dev/2017-July/119786.html 
> ; and
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120544.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
>

Very interesting analysis.
I agree, we should care about not repeating this Pike trend. It looks
like Queens is better in terms of turnout (see the amazing positive
delta!). However, I can't help but noticing that the trend for
turnouts is slowly reducing (excluding some outliers) since the
beginning of these stats.

Any idea on how to improve that?

On top of that, thanks to all the candidates, and congratulations!

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] [ptls] Sydney Forum Project Onboarding Rooms

[Jean-Philippe Evrard]

To be as cool as nova, we'll find nicknames until then.
We can probably start with Kevin "Destroy of Clouds" Carter.

On 17 October 2017 at 15:28, Jean-Philippe Evrard
<jean-phili...@evrard.me> wrote:
> Hello,
>
> I'd be happy to have a room for OpenStack-Ansible.
>
> I'll be there, and probably more ppl, like Kevin Carter(cloudnull) and
> Amy Marrich(spotz).
>
> Thanks!
>
> On 17 October 2017 at 03:39, Jeffrey Zhang <zhang.lei@gmail.com> wrote:
>> I am the speaker. Michal couldn't be Sydney this summit.
>>
>> On Tue, Oct 17, 2017 at 1:05 AM, Kendall Nelson <kennelso...@gmail.com>
>> wrote:
>>>
>>> Added Kolla to my list. Would the speakers be you and Michal?
>>>
>>> -Kendall (diablo_rojo)
>>>
>>>
>>> On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang <zhang.lei@gmail.com>
>>> wrote:
>>>>
>>>> Hi Kendall,
>>>>
>>>> Kolla project would like to have a on-boarding session too.
>>>>
>>>> thanks.
>>>>
>>>> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson <kennelso...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Added Nova to my list with Dan, Melanie, and Ed as speakers.
>>>>>
>>>>> Thanks Matt,
>>>>> -Kendall (diablo_rojo)
>>>>>
>>>>> On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann <mriede...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> On 10/9/2017 4:24 PM, Kendall Nelson wrote:
>>>>>> > Wanted to keep this thread towards the top of inboxes for those I
>>>>>> > haven't heard from yet.
>>>>>> >
>>>>>> > About a 1/4 of the way booked, so there are still slots available!
>>>>>> >
>>>>>> > -Kendall (diablo_rojo)
>>>>>>
>>>>>> I've tricked the following people into running a Nova on-boarding room:
>>>>>>
>>>>>> - "Super" Dan Smith <dansm...@redhat.com>
>>>>>> - Melanie "Structured Settlement" Witt <melwi...@gmail.com>
>>>>>> - Ed "Alternate Hosts" Leafe <e...@leafe.com>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>> __
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Jeffrey Zhang
>>>> Blog: http://xcodest.me
>>>>
>>>> __
>>>> 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
>>>
>>
>>
>>
>> --
>> Regards,
>> Jeffrey Zhang
>> Blog: http://xcodest.me
>>
>> __
>> 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] [ptls] Sydney Forum Project Onboarding Rooms

[Jean-Philippe Evrard]

Hello,

I'd be happy to have a room for OpenStack-Ansible.

I'll be there, and probably more ppl, like Kevin Carter(cloudnull) and
Amy Marrich(spotz).

Thanks!

On 17 October 2017 at 03:39, Jeffrey Zhang  wrote:
> I am the speaker. Michal couldn't be Sydney this summit.
>
> On Tue, Oct 17, 2017 at 1:05 AM, Kendall Nelson 
> wrote:
>>
>> Added Kolla to my list. Would the speakers be you and Michal?
>>
>> -Kendall (diablo_rojo)
>>
>>
>> On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang 
>> wrote:
>>>
>>> Hi Kendall,
>>>
>>> Kolla project would like to have a on-boarding session too.
>>>
>>> thanks.
>>>
>>> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson 
>>> wrote:

 Added Nova to my list with Dan, Melanie, and Ed as speakers.

 Thanks Matt,
 -Kendall (diablo_rojo)

 On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann 
 wrote:
>
> On 10/9/2017 4:24 PM, Kendall Nelson wrote:
> > Wanted to keep this thread towards the top of inboxes for those I
> > haven't heard from yet.
> >
> > About a 1/4 of the way booked, so there are still slots available!
> >
> > -Kendall (diablo_rojo)
>
> I've tricked the following people into running a Nova on-boarding room:
>
> - "Super" Dan Smith 
> - Melanie "Structured Settlement" Witt 
> - Ed "Alternate Hosts" Leafe 
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

>>>
>>>
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me
>>>
>>> __
>>> 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
>>
>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers

[Jean-Philippe Evrard]

On 16 October 2017 at 12:27, Thierry Carrez  wrote:
> Emilien Macchi wrote:
>> [...]
>> ## Proposal
>>
>> Proposal 1: create a new policy that fits for projects like installers.
>> I kicked-off something here: https://review.openstack.org/#/c/511968/
>> (open for feedback).
>> Content can be read here:
>> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
>> Tag created here: https://review.openstack.org/#/c/511969/ (same,
>> please review).
>>
>> The idea is really to not touch the current stable policy and create a
>> new one, more "relax" that suits well for projects like installers.
>>
>> Proposal 2: change the current policy and be more relax for projects
>> like installers.
>> I haven't worked on this proposal while it was something I was
>> considering doing first, because I realized it could bring confusion
>> in which projects actually follow the real stable policy and the ones
>> who have exceptions.
>> That's why I thought having a dedicated tag would help to separate them.
>>
>> Proposal 3: no change anywhere, projects like installer can't claim
>> stability etiquette (not my best option in my opinion).
>>
>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
>> this need), please get involved in the review process.
>
> My preference goes to proposal 1, however rather than call it "relaxed"
> I would make it specific to deployment/lifecycle or cycle-trailing
> projects.
>
> Ideally this policy could get adopted by any such project. The
> discussion started on the review and it's going well, so let's see where
> it goes :)
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks for the work there Emilien!

__
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]: Container errors on task "lxc_container_create : Drop container network file (interfaces)"

[Jean-Philippe Evrard]

On 13 October 2017 at 11:29, andres sanchez ramos
<andressanchezra...@hotmail.com> wrote:
> Hello guys,
>
> I am trying to deploy a lab Openstack environment using ansible in order to
> get acquainted with this tool. Actually i am stuck with an error i am not
> being able to resolve. It happens on the following task:
>
> TASK [lxc_container_create : Drop container network file (interfaces)]
> *
>
> task path:
> /etc/ansible/roles/lxc_container_create/tasks/container_create.yml:262
>
> The console prints out this error for each one of the containers:
>
> container_name: "infra1_cinder_scheduler_container-8054b2be"
> physical_host: "infra1"
> Container confirmed
> <192.168.100.30> ESTABLISH SSH CONNECTION FOR USER: lab232
> An exception occurred during task execution. The full traceback is:
> Traceback (most recent call last):
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/executor/task_executor.py",
> line 98, in run
> item_results = self._run_loop(items)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/executor/task_executor.py",
> line 290, in _run_loop
> res = self._execute(variables=task_vars)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/executor/task_executor.py",
> line 511, in _execute
> result = self._handler.run(task_vars=variables)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/plugins/action/template.py",
> line 149, in run
> tmp = self._make_tmp_path(remote_user)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/plugins/action/__init__.py",
> line 224, in _make_tmp_path
> tmpdir =  self._remote_expand_user(C.DEFAULT_REMOTE_TMP, sudoable=False)
>   File
> "/opt/ansible-runtime/local/lib/python2.7/site-packages/ansible/plugins/action/__init__.py",
> line 506, in _remote_expand_user
> initial_fragment = data['stdout'].strip().splitlines()[-1]
> IndexError: list index out of range
>
> fatal: [infra1_nova_scheduler_container-92a94180]: FAILED! => {
> "failed": true,
> "msg": "Unexpected failure during module execution.",
> "stdout": ""
> }
>
> Regarding my setup i have one infrastructure node and one compute node. I am
> attaching the interface config for each node and the
> openstack_user_config.yml file so you get a complete picture of my setup. I
> would deeply appreciate any help or any pointers that might help me
> troubleshoot this!
>
> I think the only relevant change i make regarding the instructions is my
> management network which is 192.168.100.0./24 since I already have this set
> up for other equipment.
>
>
>
>
> Enviado desde Outlook
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

Sorry, I forgot to reply all.

With the information you gave me, I think the user could be the cause.
Our connection plugin doesn't seem to
work with the sudo trick you did.

May I suggest you to file a bug to list what you did in practice,
explain this issue, and you'd expect?

In the meantime, could you try running as root on your destination
node? And maybe later on your deploy node too, to see the results?

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-dev] [openstack-ansible] Role maturity downgrades: Looking for contributions/maintainers

[Jean-Philippe Evrard]

Hello everyone,

With our role maturity guidelines now in place [1], we can now start
the maturity downgrade procedure [2] for the following roles:
- monasca [3]
- monasca-agent [4]
- octavia [5]
- searchlight [6]

On top of that, the os_freezer role need more love [7], while still in
incubated status.


What does this mean?

It means we are calling out contributors to be maintainers of those roles.
Their goal is to improve the current testing for the role on which
they would be maintainer on.
(Making the role pass functional tests is a first step!)

If you want to be a contributor, please answer on this email or talk
to us on our irc channel #openstack-ansible.

If no contributor step forward for those roles, we'll have no choice
than to downgrade their maturity status during the next community
meeting.

Thank you for your understanding.

Best regards,
Jean-Philippe Evrard (evrardjp)

[1]: https://review.openstack.org/#/c/504279/
[2]: 
https://docs.openstack.org/openstack-ansible/latest/contributor/additional-roles.html#maturity-downgrade-procedure
[3]: https://review.openstack.org/#/c/510497/
[4]: https://review.openstack.org/#/c/510498/
[5]: https://review.openstack.org/#/c/510502/
[6]: https://review.openstack.org/#/c/510505/
[7]: https://review.openstack.org/#/c/510486/

__
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] Looking for help: bug triage meeting organiser

[Jean-Philippe Evrard]

Hello everyone,

I'd be very happy if someone can take over the bug triage czar duty,
and report it in our community meeting end of each month.

It doesn't take too much time in itself (preparing a list of bugs
before the meeting, having an opinion on them, and attend the bug
triage meeting). IMO, it's greatly rewarding (be ahead of bugs).

If you are interested, please contact me on IRC or answer this email.
Thank you.

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] Changes in meetings now in application!

[Jean-Philippe Evrard]

Hello everyone,

From this week on, openstack-ansible will meet in the
#openstack-ansible channel, every Tuesday, 16:00 UTC. No meeting will
happen on Thursdays anymore. The community meeting would happen the
last Tuesday of the month, the bug triages are kept the rest of the
time.

Keep also in mind that daylight saving might apply to you this month,
for example in mainline Europe will be in "winter time" (that's how we
call it in french, please translate to whatever word applies to you!),
starting from the last weekend of October.

See you next week,

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] Thanks for all the fish

[Jean-Philippe Evrard]

On Wed, Oct 11, 2017 at 1:34 AM, Lana Brindley
<openst...@lanabrindley.com> wrote:
> Hi everyone,
>
> As most of you know, I was caught up in the Rackspace layoffs that happened 
> earlier this year, and have been looking for work (in between knee surgery) 
> since then. Well, in good news for my bank account, I have now secured a new 
> job with a startup based here in Brisbane. The bad news is that, while it's 
> working on cool stuff and is likely to be at least partially open sourced at 
> some point, there's currently no scope for me to continue working on 
> OpenStack. Sadly, an OpenStack related position just did not come my way, 
> despite my best efforts.
>
> So, this is goodbye for now. I'm going to unsubscribe from the OpenStack 
> mailing lists, and resign my core positions, but you can still email me at 
> this address if you want to. Feel free to hit me up on LinkedIn or Twitter, 
> if that's your thing.
>
> I'm going to miss being part of the community we built here, and all the 
> fabulous people I've met over my OpenStack years. Keep being awesome, I'll be 
> cheering from the sidelines.
>
> Keep on Doc'ing :)
>
> Lana
>
> --
> Lana Brindley
> Technical Writer
> http://lanabrindley.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
>

Congratulations on the new job.

You'll be missed, for sure! Thanks for the work done.

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] [packaging][all] Sample Config Files in setup.cfg

[Jean-Philippe Evrard]

On Sat, Oct 7, 2017 at 11:30 AM, Thomas Goirand <z...@debian.org> wrote:
> On 10/03/2017 03:07 PM, Luigi Toscano wrote:
>>> Why not? Simply because installing config files in /usr/etc is silly.
>>> The question would rather be: why not accepting the PBR patch...
>>
>> It is silly, but again, people consuming from deb or RPM won't notice it.
>
> Though people doing the packaging will suffer. Please don't throw the
> baby over the wall, and let's fix the issue.
>
>> Sure, having the python tools install the files in the right directory is the
>> ideal final solution.
>
> Let's get there then. In the mean while, don't break stuff.
>
>> My point is that the proposed solution is not worse than
>> the previous one and fixes at least one use case that was not previously
>> covered (the one that can be easily fixed).
>
> You are proposing to induce pain to everyone doing packaging, just
> because it solves your developer pip use case. That's not what OpenStack
> used to do, and that's not fair. Let's fix things properly *first*
> please, maybe by discussing the PBR fix I linked to. Can we agree that
> this is the pragmatic easy (but maybe temporarily) way to fix the issue,
> even if it's not perfect and a setuptools fix would be better?
>
> 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

Hello Thomas,

Yes, some people suffer from changes. But other people already suffer
on a regular basis to NOT change too. There is no easy win here.

IMO, this is fixing things properly. First we make things uniform,
then we improve them. By making things uniform and agreed upon, we
are progressing.

If you want to include the fix for PBR, or refresh it, don't hesitate
to propose a follow-up patch.
In any case, I don't think it's a good idea to wait for things to
happen, and expect that uniformity will happen naturally. This is a
step in the right direction.

On top of that we are still early in the Queens cycle, so it leaves a
chance to the packagers to react. I think it's good timing.

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] [ptl][tc] Accessible upgrade support

[Jean-Philippe Evrard]

On Tue, Oct 3, 2017 at 7:52 PM, Sean McGinnis  wrote:
> I'm hoping this will get a little more attention.
>
> We recently started discussing removing governance tags that did not have any
> projects asserting them. I think this makes a lot of sense. Some tags were
> defined apparently in the hope that it would get projects thinking about them
> and wanting to either apply for the tag, or do the work to be able to meet the
> requirements for that tag.
>
> While this may have worked in some cases, we do have a few that are a little
> unclear and not really getting much attention. We will likely clean up that
> tag list a little, but there was some push back on at least one tag.
>
> The supports-accessible-upgrade tag basically states that a service can be
> upgraded without affecting access to the resources that the service manages
> [1]. This actually fits with how at least Nova and Cinder work, so a patch is
> now out there to assert this for those two projects [2].
>
> I would bet there are several other projects out there that work in this same
> way. Since we are looking between removing tags or using them (use it or lose
> it), I would actually love to see more projects asserting this tag. If your
> project manages a set of resources that are available even when your service
> is down and/or being upgraded, please consider submitting a patch like [2] to
> add your project to the list.
>
> And just a general call out to raise awareness - please take a look through
> the other defined tags and see if there are any others that are applicable to
> your projects [3].
>
> Thanks!
>
> Sean (smcginnis)
>
>
> [1] 
> https://governance.openstack.org/tc/reference/tags/assert_supports-accessible-upgrade.html
> [2] https://review.openstack.org/#/c/509170/
> [3] https://governance.openstack.org/tc/reference/tags/index.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

Hello,

I like the idea.

A few comments, I don't know if it's too late for that, but I shoot anyway:

- I don't see any mention of documentation in the required steps to
get this governance tag.
  I think it can serve the community better if we enforce the
inclusion of the documentation on
  'HOW to trigger this "accessible" upgrade'. What do you think?
- As part of a deployment project team, I like the fact it's easy for
us (and for our users)
  to see which service is behaving "accessibly".
  It sets expectations, both for us and for the deployers.

I have questions on that "expectations" part: Would you like the
deployment projects apply for those tags?
How do you see that going? What are the requirements we have to match
for a deployment project
to be considered "upgrade accessible" ?

In my opinion it should be something along the lines of:
"if an upstream "accessible" project is deployed, it should be
upgraded in an "accessible" way,
while non "accessible" projects would fallback to a standard
'supporting upgrade' pattern?"

Or alternatively, we don't apply this tag to deployment projects.
Opinion?

__
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] Zuul v3 Status - and Rollback Information

[Jean-Philippe Evrard]

On Tue, Oct 3, 2017 at 5:40 PM, Monty Taylor <mord...@inaugust.com> wrote:
> Hey everybody!
>
> Thank you all for your patience over the last week as we've worked through
> the v3 rollout.  While we anticipated some problems, we've run into a number
> of unexpected issues, some of which will take some time to resolve.  It has
> become unreasonable to continue in our current state while they are being
> worked.
>
> With that in mind, we are going to perform a partial rollback to Zuul v2
> while we work on it so that teams can get work done. The details of that are
> as follows:
>
> The project-config repo remains frozen.  Generally we don't want to make
> changes to v2 jobs.  If a change must be made, it will need to be made to
> both v2 and v3 versions.  We will not run the migration script again.
>
> Zuul v3 will continue to run check and periodic jobs on all repos.  It will
> leave review messages, including +1/-1 votes.
>
> Our nodepool quota will be allocated 80% to Zuul v2, and 20% to ZUul v3.
> This will slow v2 down slightly, but allow us to continue to exercise v3
> enough to find problems.
>
> Zuul v2 and v3 can not both gate a project or set of projects.  In general,
> Zuul v2 will be gating all projects, except the few projects that are
> specifically v3-only: zuul-jobs, openstack-zuul-jobs, project-config, and
> zuul itself.
>
> We appreciate that some projects would prefer to use v3 exclusively, even
> while we continue to work to stabilize it.  However, in order to complete
> our work as quickly as possible, we may need to restart frequently or take
> extended v3 downtimes.  Because of this, and the reduced capacity that v3
> will be running with, we will keep the set of projects gating under v3
> limited to only those necessary.  But keep in mind, v3 will still be running
> check jobs on all projects, so you can continue to iterate on v3 job content
> in check.
>
> If you modified a script in your repo that is called from a job to work in
> v3, you may need to modify it to be compatible with both.  If you need to
> determine whether you are running under Zuul v2 or under v3 with legacy
> compatibility shims, check for the LOG_PATH environment variable.  It will
> only be present when running under Zuul v2 (and it is the variable that we
> are least likely to add to the v3 compatibility shim).
>
> Again - thank you all for your patience, and for all of the great work
> people have done working through the issues we've uncovered. As soon as
> we've got a handle on the most critical issues, we'll plan another
> roll-forward ... hopefully in a week or two, but we'll send out status
> updates as we have them.
>
> Thanks!
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Hello,

I'd like to first thank everyone involved, doing this hard work.

As an extra comment, please remember that Newton EOL is next week, so
it's maybe worth waiting after
that for the next full rollout/roll-forward (whatever the term is!) to
avoid the overlap of critical events in the same timeframe.

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] [packaging][all] Sample Config Files in setup.cfg

[Jean-Philippe Evrard]

On Tue, Oct 3, 2017 at 2:07 PM, Luigi Toscano  wrote:
> On Tuesday, 3 October 2017 14:31:05 CEST Thomas Goirand wrote:
>> On 10/02/2017 02:04 PM, Luigi Toscano wrote:
>> > Why not? Even if it does not fix the issue for proper installations,
>> > - it does not provent people from copying the files somewhere else (it
>> > happened in sahara for how long I can remember, we have been using
>> > data_files) - it fixes the deployment when the package is installed in a
>> > virtualenv; - it introduces consistency: the day data_files starts to do
>> > the right thing, everything will work; if it's not possible to fix it
>> > with data_files, it's easy to spot which files should be fixed because
>> > all handled by data_files.
>> >
>> > So definitely go for it.
>> >
>> > Ciao
>>
>> Why not? Simply because installing config files in /usr/etc is silly.
>> The question would rather be: why not accepting the PBR patch...
>
> It is silly, but again, people consuming from deb or RPM won't notice it.
> People using pip and virtualenv will get those files; the others will get them
> (compared to the previous "no available").
>
> Sure, having the python tools install the files in the right directory is the
> ideal final solution. My point is that the proposed solution is not worse than
> the previous one and fixes at least one use case that was not previously
> covered (the one that can be easily fixed).
>
>
> --
> Luigi
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Agreed, let's continue and go ahead.

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

[Jean-Philippe Evrard]

Hello everyone,

Some people on this planet are more aware of others of this fact:
we have too many meetings in our life.

I don't think OpenStack-Ansible should be so greedy to take 8 hours of
your life a month for meetings. I therefore propose the reduction to 4
meetings/month: 3 bug triages and 1 community meeting.

On top of that, attendance in meetings is low, so I'd rather we find,
all together, a timeslot that matches the majority of us.

I started this etherpad [1], to list timeslots. I'd like you to:
1) (Optionally) Add timeslot that would suit you best
2) Vote for a timeslot in which you can regularily attend
OpenStack-Ansible meetings

Please give your irc nick too, that would help.

Thank you in advance.

Best regards,
Jean-Philippe Evrard (evrardjp)

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

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

[openstack-dev] [openstack-ansible] Meetings change

[Jean-Philippe Evrard]

Hello everyone,

Some people on this planet are more aware of others of this fact:
we have too many meetings in our life.

I don't think OpenStack-Ansible should be so greedy to take 8 hours of
your life a month for meetings. I therefore propose the reduction to 4
meetings/month: 3 bug triages and 1 community meeting.

On top of that, attendance in meetings is low, so I'd rather we find,
all together, a timeslot that matches the majority of us.

I started this etherpad [1], to list timeslots. I'd like you to:
1) (Optionally) Add timeslot that would suit you best
2) Vote for a timeslot in which you can regularily attend
OpenStack-Ansible meetings

Please give your irc nick too, that would help.

Thank you in advance.

Best regards,
Jean-Philippe Evrard (evrardjp)

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

__
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 testing with OpenVSwitch

[Jean-Philippe Evrard]

Well, there are ppl already running OpenVSwitch on openstack-ansible,
so I guess it's just a question of a few bug fixes and adding a
scenario to make sure this is working forever :p

On Fri, Sep 29, 2017 at 8:22 AM, Gyorgy Szombathelyi
 wrote:
>
>>
>> Hello JP,
>>
>> Ok, I will do some more testing against the blog post and then hit up the
>> #openstack-ansible channel.
>>
>> I need to finish a presentation on SFC first which is why I am looking into
>> OpenVSwitch.
>
> Hi Michael,
>
> If your goal is not openstack-ansible, here's an AIO installer for Pike with 
> OpenVSwitch:
> https://github.com/DoclerLabs/openstack
> (needs vagrant and VirtualBox)
>
> Br,
> György
>
>>
>> Thanks
>> Michael
>>
>
> __
> 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] [release][ptl] Improving the process for release marketing

[Jean-Philippe Evrard]

On Fri, Sep 29, 2017 at 11:16 PM, Mike Perez  wrote:
> On 14:33 Sep 26, Anne Bertucio wrote:
>> Release marketing is a critical part of sharing what’s new in each release,
>> and we want to rework how the marketing community and projects work together
>> to make the release communications happen.
>>
>> Having multiple, repetetive demands to summarize "top features" during
>> release time can be pestering and having to recollect the information each
>> time isn't an effective use of time. Being asked to make polished,
>> "press-friendly" messages out of release notes can feel too far outside of
>> the PTL's focus areas or skills. At the same time, for technical content
>> marketers, attempting to find the key features from release notes, ML posts,
>> specs, Roadmap, etc., means interesting features are sometimes overlooked.
>> Marketing teams don't have the latest on what features landed and with what
>> caveats.
>>
>> To address this gap, the Release team and Foundation marketing team propose
>> collecting information as part of the release tagging process. Similar to the
>> existing (unused) "highlights" field for an individual tag, we will collect
>> some text in the deliverable file to provide highlights for the series (about
>> 3 items). That text will then be used to build a landing page on
>> release.openstack.org that shows the "key features" flagged by PTLs that
>> marketing teams should be looking at during release communication times. The
>> page will link to the release notes, so marketers can start there to gather
>> additional information, eliminating repetitive asks of PTLs. The "pre
>> selection" of features means marketers can spend more time diving into
>> release note details and less sifting through them.
>>
>> To supplement the written information, the marketing community is also going
>> to work together to consolidate follow up questions and deliver them in
>> "press corps" style (i.e. a single phone call to be asked questions from
>> multiple parties vs. multiple phone calls from individuals).
>>
>> We will provide more details about the implementation for the highlights page
>> when that is ready, but want to gather feedback about both aspects of the
>> plan early.
>
> As being someone who participates in building out that page, I  welcome this 
> to
> represent highlights from the community itself better.
>
> --
> Mike Perez
>
> __
> 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
>

It's a good thing. Thanks for the feature!

__
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 and Trove support

[Jean-Philippe Evrard]

Hello Michael,

On top of that, we intend to have a "role maturity" that will include
when the role was proposed and it's current maturity phase, for more
clarity, not unlike openstack project navigator.

Our os_trove role has not received many commits recently, and the
"maintenance mode" of Trove will probably impact you in the future.
Do you intend to keep a trove installation in production, or do you
want to do a PoC?

Best regards,
JP

On Wed, Sep 27, 2017 at 12:24 AM, Amy Marrich  wrote:
> Michael,
>
> There are release notes for each release that will go over what's new,
> what's on it's way out or even gone as well as bug fixes and other
> information. Here's a link to the Ocata release notes for OpenStack-Ansible
> which includes the announcement of the Trove role.
>
> https://docs.openstack.org/releasenotes/openstack-ansible/ocata.html
>
> Thanks,
>
> Amy (spotz)
>
> On Tue, Sep 26, 2017 at 6:04 PM, Michael Gale 
> wrote:
>>
>> Hello,
>>
>>Based on github and
>> https://docs.openstack.org/openstack-ansible-os_trove/latest/ it looks like
>> OpenStack-Ansible will support Trove under the Ocata release.
>>
>> Is that assumption correct? is there a better method to determine when a
>> software component will likely be included in a release?
>>
>> Michael
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] OpenStack-Ansible testing with OpenVSwitch

[Jean-Philippe Evrard]

Hello,

We currently don't have a full scenario for openvswitch for an easy
"one line" install.
It still deserves more love. You could come on our channel in
#openstack-ansible to discuss about it if you want. But the general
idea should be close to the same explained in the blog post.

Best regards,
JP

On Wed, Sep 27, 2017 at 12:13 AM, Michael Gale  wrote:
> Hello,
>
> I am trying to build a Pike All-in-One instance for OpenStack Ansible
> testing, currently I have a few OpenStack versions being deployed using the
> default Linux Bridge implementation.
>
> However I need a test environment to validate OpenVSwitch implementation, is
> there a simple method to get an AIO installed?
>
> I tried following
> https://medium.com/@travistruman/configuring-openstack-ansible-for-open-vswitch-b7e70e26009d
> however Neutron is blowing up because it can't determine the name for the
> Neutron Server. I am not sure if that is my issue or not, a reference
> implementation of OpenStack AIO with OpenVSwitch would help me a lot.
>
> Thanks
> Michael
>
> __
> 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] [openstack-ansible] PTG Team dinner

[Jean-Philippe Evrard]

Hello guys,

I propose we have a team dinner at casey's this Thursday, at the PTG.

Could you please vote on the following poll, this way I can book?

https://framadate.org/zQPEvPGPOH1u2EU8

Thank you in advance.

Best regards,
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

[openstack-dev] [ptg] [openstack-ansible] [kolla-ansible] [tripleo] Ansible feedback sharing session

[Jean-Philippe Evrard]

Hello,

The OpenStack-Ansible team will have a session to share feedbacks
about ansible 2.4 or ansible+python3.

Anyone welcomed to share their experience and give insights.

It will be on Wednesday 3:30 to 5pm.

See you there!
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] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG

[Jean-Philippe Evrard]

Hello Emilien,

The Discussion room is a good idea. I like it.
Most of the OpenStack-Ansible crew will be available the whole week, so we
can even think of doing a conversation outside the Wed-Friday timeframe.

If you/we all have enough time, maybe we could organise two sessions,
probably with different formats?
For example, a brainstorming session about how we collaborated on previous
cycles and how we could collaborate in the future, and another session with
the real action points based on the first conversation?

On top of that, I have extra points I'd like to discuss with you:
- Architecture of LB + web server + uwsgi
- Possibility of sharing infrastructure (mariadb/rabbitmq/...)
experience/code between projects.

Thank you in advance.

Best regards,
JP

On Fri, Aug 25, 2017 at 8:16 PM, Emilien Macchi  wrote:

> Cool, sounds like some people are interested (I haven't hear from
> Kolla yet but I'm sure they are as well).
>
> I was wondering if we should take benefit of Discussion Rooms, useful
> for inter-projects topics:
> https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms
>
> There is still some place, let me know what you think and we can block
> a slot (maybe 2h?)
> I want to hear from Kolla and OpenStack Ansible at least and know if
> you have schedule constraints otherwise I'll go ahead and block a
> slot.
>
> Thanks,
>
> On Fri, Aug 18, 2017 at 4:37 AM, Flavio Percoco  wrote:
> > On 17/08/17 10:24 -0500, Major Hayden wrote:
> >>
> >> On 08/17/2017 09:30 AM, Emilien Macchi wrote:
> >>>
> >>> If you're working on Kolla / OpenStack-Ansible - please let us know if
> >>> you have specific constraints on the schedule, so we can maybe block a
> >>> timeslot in the agenda from now.
> >>> We'll have a "Packaging" room which is reserved for all topics related
> >>> to OpenStack deployments, so we can use this one.
> >>
> >>
> >> I don't have any constraints (that I'm aware of), but I'd be interested
> in
> >> participating!  Performance in the gate jobs has been one of my tasks
> lately
> >> and I'd like to see if we can collaborate there to make improvements
> without
> >> ruining infra's day. ;)
> >>
> >> As long as you can put up with a few Dad jokes, I'll be there.
> >
> >
> > ++ I'm interested in this topic too!
> >
> > Flavio
> >
> > --
> > @flaper87
> > Flavio Percoco
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> 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] [openstack-ansible] group/host specific config file overrides: how-to?

[Jean-Philippe Evrard]

Hello,

The variables documented in each of the roles defaults/ are generally what
you can consider a user level interface (i.e.: what you can modify), while
the variables from vars/ are generally what's best to avoid overriding.

We've been slowly phasing out variables insides templates, to exclusively
rely on config_template overrides (See also: [1] and [2])
Please note that if a variable is deprecated, we are issuing a release note.

[1]: https://github.com/openstack/openstack-ansible-os_nova/blob/
4b9100a612ba0e9449d792b2783b9ec50a8fb28e/tasks/nova_post_install.yml#L40
[2]: https://docs.openstack.org/project-deploy-guide/
openstack-ansible/ocata/app-advanced-config-override.html

Best regards,
JP


On Tue, Aug 22, 2017 at 1:24 PM, Markus Zoeller  wrote:

> On 22.08.2017 09:46, Flávio Ramalho wrote:
> > Hi Markus,
> >
> > I think you can achieve what you want by simple overriding the host
> > variables, for example:
> >
> > In /etc/openstack_deploy/openstack_user_config.yml:
> > compute_hosts:
> >compute1:
> >  ip: 192.168.100.12
> >  host_vars:
> >nova_reserved_host_memory_mb: 256
> >compute2:
> >  ip: 192.168.100.10
> >
> > In this case you would have compute1 with reserved_host_memory_mb = 256
> and
> > compute2 with the default value set for nova_reserved_host_memory_mb.
> >
> >
> > Flávio
>
> Oh, I didn't see those variables, good hint! I'll give it a try, maybe
> that's good enough for me. Thanks a lot Flavio!
>
> http://git.openstack.org/cgit/openstack/openstack-ansible-os
> _nova/tree/templates/nova.conf.j2
>
> Despite that this will probably work, is that an "interface" I'm allowed
> to touch or is it considered an "internal/private" part of
> OpenStack-Ansible (and/or its roles)?
>
> --
> Regards, Markus Zoeller (markus_z)
>
>
> > On Mon, Aug 21, 2017 at 6:09 PM Markus Zoeller <
> mzoel...@linux.vnet.ibm.com>
> > wrote:
> >
> >> On 21.08.2017 16:40, Andy McCrae wrote:
> >>> Hey Markus,
> >>>
> >>>
>  I'm wondering which possibilities I have to do group/host specific
>  config file overrides. After reading [1], I'm still a little clueless.
>  To be specific, I have this setup (expressed as Ansible inventory
> file):
> 
>  [z_compute_nodes]
>  compute1
>  # more nodes
>  [x_compute_nodes]
>  compute2
>  # more nodes
>  [computes:children]
>  z_compute_nodes
>  x_compute_nodes
> 
>  As an example, I want to set Nova's config option
>  `reserved_host_memory_mb` of the `DEFAULT` config file section:
> 
>  ### nova.conf
>  [DEFAULT]
>  reserved_host_memory_mb=$VALUE
> 
>  My goal is this:
> 
>   | reserved_host_memory_mb
>  --
>  compute1 | 256
>  compute2 | 512
> 
>  I know there are overrides like `nova_nova_conf_overrides`.
>  So I tried to set a default override in `user_variables.yml`:
> 
>  ### /etc/openstack_deploy/user_variables.yml 
> 
>  nova_nova_conf_overrides:
>    DEFAULT:
>  reserved_host_memory_mb: 512
> 
>  But I wanted to override this depending on the host in
>  `openstack_user_config.yml`:
> 
>  ### /etc/openstack_deploy/openstack_user_config.yml 
>  # [...]
>  # nova hypervisors
>  compute_hosts:
>    compute1:
>  ip: 192.168.100.12
>  host_vars:
>    nova_nova_conf_overrides:
>  DEFAULT:
>    reserved_host_memory_mb: 256
>    compute2:
>  ip: 192.168.100.10
> 
> >>>
> >>> Try change "host_vars" to "container_vars".
> >>> If that doesn't work let me know, I'll spin up a test to recreate the
> >>> actual problem, but at a glance that looks correct otherwise.
> >>>
> >>
> >>
> >> Replacing `host_vars` with `container_vars` didn't have an effect:
> >>
> >> ### controller1: /etc/openstack_deploy/openstack_user_config.yml
> >> # nova hypervisors
> >> compute_hosts:
> >>   compute1:
> >> ip: 192.168.100.12
> >> container_vars:
> >>   nova_nova_conf_overrides:
> >> DEFAULT:
> >> reserved_host_memory_mb: 256
> >>   compute2:
> >> ip: 192.168.100.10
> >>
> >> Both compute nodes still have the same $VALUE, although `compute1`
> >> should have 256:
> >>
> >> ### compute1: /etc/nova/nova.conf
> >> root@compute1:~# grep reserved_host_memory_mb /etc/nova/nova.conf
> >> reserved_host_memory_mb = 512
> >>
> >>
> >> ### compute2: /etc/nova/nova.conf
> >> root@compute2:~# grep reserved_host_memory_mb /etc/nova/nova.conf
> >> reserved_host_memory_mb = 512
> >>
> >> I'd like to avoid to introduce some "clever" dict merging algorithm I
> >> won't understand anymore after a few weeks. :/
> >>

Re: [openstack-dev] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG

[Jean-Philippe Evrard]

I'd be happy to join.

I don't think we have constraints on the schedule yet, and we can indeed
book slot(s).

Best regards,
JP.

On Thu, Aug 17, 2017 at 3:30 PM, Emilien Macchi  wrote:

> Hey folks,
>
> As usual, we'll meet in Denver and I hope we can spend some time
> together (in a meeting room first) to have face to face discussions on
> the recent topics that we had.
> Right now, TripleO sessions are not scheduled in our agenda, so we're
> pretty flexible: https://etherpad.openstack.org/p/tripleo-ptg-queens
>
> I would like to propose one topic (happy to coordinate the discussion)
> on some efforts regarding doing configuration management with Ansible,
> and k8s integration as well.
> Flavio made some progress [1] - I really hope we can make progress here.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-
> July/119696.html
>
> If you're working on Kolla / OpenStack-Ansible - please let us know if
> you have specific constraints on the schedule, so we can maybe block a
> timeslot in the agenda from now.
> We'll have a "Packaging" room which is reserved for all topics related
> to OpenStack deployments, so we can use this one.
>
> Looking forward to meeting you at PTG!
> Thanks,
> --
> 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-dev] [openstack-ansible] Queens PTL candidacy

[Jean-Philippe Evrard]

Hello everyone,

I would like to announce my candidacy for PTL of the
OpenStack-Ansible project for the Queens cycle.

I will focus on the following themes:

1) Improve the usability

It can be difficult for a newcomer to fully grasp the way
OpenStack-Ansible works, and the first experience can be daunting.
The deploy and operator's guides are a step in the right direction,
and we must continue that documentation effort to show that our
solution can scale up to any operator's size.

OpenStack-Ansible has largely grown since its creation, and we support
much more roles now. That is a positive improvement. We now have more
features that people want to use. As a consequence, we also carry less
used roles that are less maintained. My objective is to reduce our
technical debt if possible, standardize more, and make sure the less
maintained roles don't have a negative impact on our image.
For that, I'd like to formalize our role maturity index as a way to
show role adoption, and to easily spot if the role is meeting
our latest testing/coding standards.

2) Redesign for the future, while still improving operator's experience

We've always taken the decision to go for proven technology/low risks/
low maintenance solutions.
I intend to keep this mindset, but also introduce newer architecture:

* Re-design the placement of web servers/reverse proxy, thanks to the
  recent work done for UWSGI support.
* Introduce systemd-nspawn, next to LXC.
* Change our default deployments to be more converged, to reduce
  the amount of containers to manage.
* Separate the installation and configuration steps of a deploy,
  and test it in our gates. This would allow larger operators to build
  their own "artifacts" separately of their consumption in a standard
  way, and share experience in the larger community.
* Upgrade to Ansible 2.4.

I look forward to working with you all, and it would be my honor
to serve as PTL for the next cycle.

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][security] To firewalld, or not to firewalld

[Jean-Philippe Evrard]

Hello,

A few additions for/against firewalld, linked to ansible's firewalld
module: http://docs.ansible.com/ansible/latest/firewalld_module.html

+:
The module is built-in, so no need to ship it. It provides idempotency, and
is easy to use.

-:
The module is: "Not tested on any Debian based system.
Requires the python2 bindings of firewalld, which may not be installed by
default if the distribution switched to python 3".

My take:

For ppl who aren't iptables experts, firewalld module brings a lot of
readability.
If we are doing the tasks equivalent with iptables, the readability will be
brought in by variables (I mean variables to list ports_to_open are fairly
easy to understand).

I am myself preferring to always use modules, and so, use the firewalld
module (because it's already upstream, less tasks and therefore less error
prone).
However, that would mean that we improve the module itself to grant what we
need: Real ubuntu and python3 support.
Maybe it's a crusade that nobody wants to partake in, and using iptables
would mean a path to least resistance, therefore easier to ship.
On top of it, if it's more a hassle to use the module due to complex rules
(do we even need that?), I'd understand the move to iptables management. Is
there already a role to handle this?

Best regards,
JP

On Wed, Jul 26, 2017 at 3:59 PM, Major Hayden  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hey there,
>
> I'm working through some drafts of a spec[0] (rendered[1]) that aims to
> deploy software firewalls within an OpenStack-Ansible deployment. The goal
> is to increase security by restricting lateral movement.
>
> One of the questions that was raised was the method for managing firewall
> rules. The spec lays out a plan for firewalld since it is available in the
> supported operating systems (Ubuntu 16.04, CentOS 7, OpenSUSE 42.x) and it
> allows us to control IPv4/IPv6 rules in the same place.
>
> However, Logan makes a good point about using a jinja template to write
> firewall rules to a file and load that via normal iptables service
> mechanisms. I definitely see merit to that approach, too.
>
> I'd really like feedback from developers/operators of OpenStack-Ansible to
> determine the best method to proceed. Here's what I've come up with so far:
>
> firewalld advantages
> - 
> 1) Available in all distributions we support
> 2) Provides simple commands to interface with firewall rules
> 3) Manages IPv4/IPv6 iptables rules at the same time
>
> firewalld disadvantages
> - ---
> 1) Different distributions have different base rule sets
> 2) Medium/High complexity rules require --direct, which is like using
> iptables anyway
> 3) It's another daemon to manage/monitor
> 4) We wouldn't be able to use firewalld's "zones" very heavily
> 5) Saving/restoring iptables rules is battle-tested already
>
>
> [0] https://review.openstack.org/#/c/479415/
> [1] http://docs-draft.openstack.org/15/479415/5/check/gate-
> openstack-ansible-specs-docs-ubuntu-xenial/6a50e01//doc/
> build/html/specs/pike/software-firewall.html
>
> - --
> Major Hayden
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAll4rkwACgkQc3BR4MEB
> H7G3ThAAkYfAGPThoaLK+a+xSZjQrrDYo3T2Q8h/nCVdSbXU1npfv0wnIUcpezH7
> a2bq4tSOX53tupUtvtMXK1VzSh5zQbohewfndmAOpwH8yNJ6UdnBjTfNXbs1WU05
> ke6X/RIvkNEKO4q5RvO3hbgKFKtLFdDVWRa7m6ORM2UaN2QXRrr85Cs0GrS0wWJq
> XDLVf5277VPXiobntUkdSdVAHfPX0QULMUBxSbnhAjGhLWfZnGiyInntHAu0rGqj
> xhkZNT3wuEMmorbIfUkY1NhjWJyy5LyjCar+hpJKRz/pNlFiOiF36Ps4PLNBW06P
> IwL3IbTkOwI6KPffFBqmMYb2AHsbqpnwxjBjoUQv1YvW55IZn3EliUY0t05JBFZ0
> N4EDNplyX9UhEQdFQrKHkOjCzADuuI/nnngfsZiCziiU068mRYIp4S3phj6QiOZP
> bHdjQDUx3X7rk1s6i7SdLPxPYNPxEs6wipXzofjB4STwDYqFKmpSNOTecLVN64PE
> H1bmt/lOfSpl05jjwhk8Jaxd0RgMAM2a7pA7nsTpFqRG4v7VaucewGaCRypCvAUD
> JiuQ+RYCNifEBb8nX6lx8TnJLCzaFK4xZuEdpBqGCwKaXRYUqdS+W2bRPqRY6EmF
> 5jYN1d2U0rxyYmQ1cH921VQPhA8K142FoUgq+oqiaH/8cqeWr9o=
> =lwtm
> -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
>
__
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] Bug smash

[Jean-Philippe Evrard]

Hello team,

We've talked about a few times in our channels about a bug smash.

I think it's time to do it:
- We have 9 bugs triaged as highly important
- We have 21 bugs of medium importance
- We have 30 bugs classified as low.

That's 60 bugs we've agreed to fix, ranging from "when convenient" to "hey,
we should do it very much... now", which is probably enough for having bug
smash session(s).

So, I'll freeze two of my afternoons to fix what I can, and I'd be happy if
you could join me in the effort.

Here are two weeks that would fit best for the bug smash, IMO (see also
pike schedule, [2]):
- Aug 14 - Aug 18 (after RC and after our feature freeze)
- Sep 04 - Sep 08 (just after our RC and after our other projects releases,
just before the PTG/our release deadline)
I'd be happy if you could vote on the doodle here [1] to show your
availability.

If we have extra time on the Sep 04-Sep 08, we could also talk about our 54
wishlist bugs, because we'll have these in mind when bringing ideas at the
PTG.

For the technical details, I think we should gather at least online.
I have a meeting room (zoom, a skype-like thing) we could all join, which
makes it more friendly.

Alternatively, if there is an organisation willing to host the bug smash in
their offices, please come forward. I think the only requirement would be
to have a meeting room system where the participants can join remotely if
they can't join physically.

Sorry for the long mail and thank you in advance.

Best regards,

JP (evrardjp)

[1]: https://framadate.org/osa-pike-bug-smash
[2]: https://releases.openstack.org/pike/schedule.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Ansible] Proposing Markos Chandras for osa-core

[Jean-Philippe Evrard]

+1 Thanks for all the work!

On Tue, Jul 18, 2017 at 10:33 AM, Nicolas Bock <
nicolasbock.openst...@gmail.com> wrote:

> On Tue, Jul 18, 2017 at 10:23:46AM +0100, Andy McCrae wrote:
>
>> Following on from last week's meeting I'd like to propose Markos
>> (hwoarang)
>> for OSA core.
>>
>
> +1 !!
>
> Markos has done a lot of good reviews and commits over an extended period
>> of time, and has shown interest in the project as a whole. (Not to mention
>> the addition of SUSE support)
>>
>> We already have quite a few +1's from the meeting itself, but opening up
>> to
>> everybody who wasn't available at the meeting!
>>
>> Thanks,
>> Andy
>>
>
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-ansible] Next bug triages

[Jean-Philippe Evrard]

Hello everyone,

I won't be able to hold the bug triage meeting for OpenStack-Ansible, this
week and next week.
I'd be super happy if someone could replace me.

On top of that, I suggest to cancel the bug triage for the 4th of July.

Thank you for your help/understanding!

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] mount ceph block from an instance

[Jean-Philippe Evrard]

Hello, 

That was indeed my suggestion.
The alternative would be to make sure your ceph can be routed through your 
public network. But it’s not my infrastructure, I don’t know what you store as 
data, etc…

In either case, you’re making possible for your tenants to access a part of 
your infra (the ceph cluster that’s used for openstack too), so you should 
think of the implications twice (bad neighbours, security intrusions…).
 
Best regards,
JP


On 29/05/2017, 10:27, "fabrice grelaud" <fabrice.grel...@u-bordeaux.fr> wrote:

Thanks for the answer.

My use case is for a file-hosting software system like « Seafile »  which 
can use a ceph backend (swift too but we don’t deploy swift on our infra).

Our network configuration of our infra is identical as your OSA 
documentation. So, on our compute node we have two bonding interface (bond0 and 
bond1).
The ceph vlan is actually propagate on bond0 (where is attach br-storage) 
to have ceph backend for our openstack.
And on bond1, among other, we have br-vlan for ours vlans providers.

If i understood correctly, the solution is to propagate too on our switch 
the ceph vlan on bond1, and create by neutron the provider network to be 
reachable in the tenant by our file-hosting software.

For security issues, using neutron rbac tool to share only this provider 
network to the tenant in question, could be sufficient ?

I’m all ears ;-) if you have another alternative.

Regards,
Fabrice


> Le 25 mai 2017 à 14:01, Jean-Philippe Evrard 
<jean-philippe.evr...@rackspace.co.uk> a écrit :
> 
> I doubt many people have tried this, because 1) cinder/nova/glance 
probably do the job well in a multi-tenant fashion 2) you’re poking holes into 
your ceph cluster security.
> 
> Anyway, if you still want it, you would need (I guess) have to create a 
provider network that will be allowed to access your ceph network.
> 
> You can either route it from your current public network, or create 
another network. It’s 100% up to you, and not osa specific.
> 
> Best regards,
> JP
> 
> On 24/05/2017, 15:02, "fabrice grelaud" <fabrice.grel...@u-bordeaux.fr> 
wrote:
> 
>Hi osa team,
> 
>i have a multimode openstack-ansible deployed, ocata 15.1.3, with ceph 
as backend for cinder (with our own ceph infra).
> 
>After create an instance with root volume, i would like to mount a 
ceph block or cephfs directly to the vm (not a cinder volume). So i want to 
attach a new interface to the vm that is in the ceph vlan.
>How can i do that ?
> 
>We have our ceph vlan propagated on bond0 interface (bond0.xxx and 
br-storage configured as documented) for openstack infrastructure.
> 
>Should i have to propagate this vlan on the bond1 interface where my 
br-vlan is attach ?
>Should i have to use the existing br-storage where the ceph vlan is 
already propagated (bond0.xxx) ? And how i create the ceph vlan network in 
neutron (by neutron directly or by horizon) ?
> 
>Has anyone ever experienced this ?
> 
>
__
>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] [openstack-ansible] mount ceph block from an instance

[Jean-Philippe Evrard]

I doubt many people have tried this, because 1) cinder/nova/glance probably do 
the job well in a multi-tenant fashion 2) you’re poking holes into your ceph 
cluster security.

Anyway, if you still want it, you would need (I guess) have to create a 
provider network that will be allowed to access your ceph network.

You can either route it from your current public network, or create another 
network. It’s 100% up to you, and not osa specific.

Best regards,
JP

On 24/05/2017, 15:02, "fabrice grelaud"  wrote:

Hi osa team,

i have a multimode openstack-ansible deployed, ocata 15.1.3, with ceph as 
backend for cinder (with our own ceph infra).

After create an instance with root volume, i would like to mount a ceph 
block or cephfs directly to the vm (not a cinder volume). So i want to attach a 
new interface to the vm that is in the ceph vlan.
How can i do that ?

We have our ceph vlan propagated on bond0 interface (bond0.xxx and 
br-storage configured as documented) for openstack infrastructure.

Should i have to propagate this vlan on the bond1 interface where my 
br-vlan is attach ?
Should i have to use the existing br-storage where the ceph vlan is already 
propagated (bond0.xxx) ? And how i create the ceph vlan network in neutron (by 
neutron directly or by horizon) ?

Has anyone ever experienced this ?

__
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