Re: [Openstack-operators] [User-committee] [publiccloud-wg] Meeting tomorrow

[Zhipeng Huang]

cc'ed sig list.

Kind reminder for the meeting about 2 and half hours away, we will do a
review of the denver ptg summary [0] and then go over the forum sessions
which we want to propose [1]

This is an EU/APAC friendly meeting so please do join us if you are in the
region :)

[0]https://etherpad.openstack.org/p/publiccloud-wg-stein-ptg-summary
[1]https://etherpad.openstack.org/p/BER-forum-public-cloud

On Tue, Sep 18, 2018 at 8:05 PM Tobias Rydberg <
tobias.rydb...@citynetwork.eu> wrote:

> Hi everyone,
>
> Don't forget that we have a meeting tomorrow at 0700 UTC at IRC channel
> #openstack-publiccloud.
>
> See you all there!
>
> Cheers,
> Tobias
>
> --
> Tobias Rydberg
> Senior Developer
> Twitter & IRC: tobberydberg
>
> www.citynetwork.eu | www.citycloud.com
>
> INNOVATION THROUGH OPEN IT INFRASTRUCTURE
> ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED
>
>
> ___
> User-committee mailing list
> user-commit...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Ops Forum Session Brainstorming

[Erik McCormick]

This is a friendly reminder for anyone wishing to see Ops-focused sessions
in Berlin to get your submissions in soon. We have a couple things there
that came out of the PTG, but that's it so far. See below for details.

Cheers,
Erik



On Wed, Sep 12, 2018, 5:07 PM Erik McCormick 
wrote:

> Hello everyone,
>
> I have set up an etherpad to collect Ops related session ideas for the
> Forum at the Berlin Summit. Please suggest any topics that you would
> like to see covered, and +1 existing topics you like.
>
> https://etherpad.openstack.org/p/ops-forum-stein
>
> Cheers,
> Erik
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] Forum Topic Submission Period

[Jimmy McArthur]

Hey Matt,


Matt Riedemann wrote:


Just a process question.


Good question.
I submitted a presentation for the normal marketing blitz part of the 
summit which wasn't accepted (I'm still dealing with this emotionally, 
btw...) 

If there's anything I can do...
but when I look at the CFP link for Forum topics, my thing shows up 
there as "Received" so does that mean my non-Forum-at-all submission 
is now automatically a candidate for the Forum because that would not 
be my intended audience (only suits and big wigs please).
Forum Submissions would be considered separate and non-Forum submissions 
will not be considered for the Forum. The submission process is based on 
the track you submit to and, in the case of the Forum, we separate this 
track out from the rest of the submission process.


If you think there is still something funky, send me a note via 
speakersupp...@openstack.org or ji...@openstack.org and I'll work 
through it with you.


Cheers,
Jimmy




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

Re: [Openstack-operators] [tripleo]Pacemaker in split controller mode

[Cody]

Hello,

I have a follow up question.

According to the TripleO docs for RHOPS 13/Queens, "you cannot scale
up or scale down a custom role that contains
OS::TripleO::Services::Pacemaker or
OS::TripleO::Services::PacemakerRemote services." Does that only apply
to the role itself or all the pcmk-managed services within the role?
For instance, if I already split out the DB and messaging services
with a custom role, can I later create another custom role just to
scale up the DB service?

Thank you very much.

Regards,
Cody

On Fri, Aug 31, 2018 at 3:52 PM Cody  wrote:
>
> Got it! Thank you, Michele.
>
> Cheers,
> Cody
> On Fri, Aug 31, 2018 at 3:07 PM Michele Baldessari  wrote:
> >
> > Hi,
> >
> > On Fri, Aug 31, 2018 at 01:46:43PM -0400, Cody wrote:
> > > A quick question on TripleO. If I take any pacemaker managed services
> > > (e.g. database) from the monolithic controller role and put them onto
> > > another cluster, would that cluster be managed as a separate pacemaker
> > > cluster?
> >
> > No, if you split off any pcmk-managed services to a separate role they
> > will still be managed by a single pacemaker cluster. Since Ocata we have
> > composable HA roles, so you can split off DB/messaging/etc to separate
> > nodes (roles). They will be all part of a single cluster.
> >
> > cheers,
> > Michele
> > --
> > Michele Baldessari
> > C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D
> >
> > ___
> > 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-dev] Are we ready to put stable/ocata into extended maintenance mode?

[Alex Schultz]

On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann  wrote:
> The release page says Ocata is planned to go into extended maintenance mode
> on Aug 27 [1]. There really isn't much to this except it means we don't do
> releases for Ocata anymore [2]. There is a caveat that project teams that do
> not wish to maintain stable/ocata after this point can immediately end of
> life the branch for their project [3]. We can still run CI using tags, e.g.
> if keystone goes ocata-eol, devstack on stable/ocata can still continue to
> install from stable/ocata for nova and the ocata-eol tag for keystone.
> Having said that, if there is no undue burden on the project team keeping
> the lights on for stable/ocata, I would recommend not tagging the
> stable/ocata branch end of life at this point.
>
> So, questions that need answering are:
>
> 1. Should we cut a final release for projects with stable/ocata branches
> before going into extended maintenance mode? I tend to think "yes" to flush
> the queue of backports. In fact, [3] doesn't mention it, but the resolution
> said we'd tag the branch [4] to indicate it has entered the EM phase.
>
> 2. Are there any projects that would want to skip EM and go directly to EOL
> (yes this feels like a Monopoly question)?
>

I believe TripleO would like to EOL instead of EM for Ocata as
indicated by the thead
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134671.html

Thanks,
-Alex

> [1] https://releases.openstack.org/
> [2]
> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
> [3]
> https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
> [4]
> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life
>
> --
>
> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Openstack-sigs] Are we ready to put stable/ocata into extended maintenance mode?

[Sean McGinnis]

On Tue, Sep 18, 2018 at 02:27:03PM -0500, Matt Riedemann wrote:
> The release page says Ocata is planned to go into extended maintenance mode
> on Aug 27 [1]. There really isn't much to this except it means we don't do
> releases for Ocata anymore [2]. There is a caveat that project teams that do
> not wish to maintain stable/ocata after this point can immediately end of
> life the branch for their project [3]. We can still run CI using tags, e.g.
> if keystone goes ocata-eol, devstack on stable/ocata can still continue to
> install from stable/ocata for nova and the ocata-eol tag for keystone.
> Having said that, if there is no undue burden on the project team keeping
> the lights on for stable/ocata, I would recommend not tagging the
> stable/ocata branch end of life at this point.
> 
> So, questions that need answering are:
> 
> 1. Should we cut a final release for projects with stable/ocata branches
> before going into extended maintenance mode? I tend to think "yes" to flush
> the queue of backports. In fact, [3] doesn't mention it, but the resolution
> said we'd tag the branch [4] to indicate it has entered the EM phase.
> 
> 2. Are there any projects that would want to skip EM and go directly to EOL
> (yes this feels like a Monopoly question)?
> 
> [1] https://releases.openstack.org/
> [2] 
> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
> [3] 
> https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
> [4] 
> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life
> 
> -- 
> 
> Thanks,
> 
> Matt

I have a patch that's been pending for marking it as extended maintenance:

https://review.openstack.org/#/c/598164/

That's just the state for Ocata. You raise some other good points here that I
am curious to see input on.

Sean


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

[Openstack-operators] Are we ready to put stable/ocata into extended maintenance mode?

[Matt Riedemann]

The release page says Ocata is planned to go into extended maintenance 
mode on Aug 27 [1]. There really isn't much to this except it means we 
don't do releases for Ocata anymore [2]. There is a caveat that project 
teams that do not wish to maintain stable/ocata after this point can 
immediately end of life the branch for their project [3]. We can still 
run CI using tags, e.g. if keystone goes ocata-eol, devstack on 
stable/ocata can still continue to install from stable/ocata for nova 
and the ocata-eol tag for keystone. Having said that, if there is no 
undue burden on the project team keeping the lights on for stable/ocata, 
I would recommend not tagging the stable/ocata branch end of life at 
this point.


So, questions that need answering are:

1. Should we cut a final release for projects with stable/ocata branches 
before going into extended maintenance mode? I tend to think "yes" to 
flush the queue of backports. In fact, [3] doesn't mention it, but the 
resolution said we'd tag the branch [4] to indicate it has entered the 
EM phase.


2. Are there any projects that would want to skip EM and go directly to 
EOL (yes this feels like a Monopoly question)?


[1] https://releases.openstack.org/
[2] 
https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
[3] 
https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
[4] 
https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life


--

Thanks,

Matt

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

[Openstack-operators] Denver Ops Meetup post-mortem

[Chris Morgan]

 Hello All,
  Last week we had a successful Ops Meetup embedded in the OpenStack
Project Team Gathering in Denver.

Despite generally being a useful gathering, there were definitely lessons
learned and things to work on, so I thought it would be useful to share a
post-mortem. I encourage everyone to share their thoughts on this as well.

What went well:

- some of the sessions were great and a lot of progress was made
- overall attendance in the ops room was good
- more developers were able to join the discussions
- facilities were generally fine
- some operators leveraged being at PTG to have useful involvement in other
sessions/discussions such as Keystone, User Committee, Self-Healing SIG,
not to mention the usual "hallway conversations", and similarly some
project devs were able to bring pressing questions directly to operators.

What didn't go so well:

- Merging into upgrade SIG didn't go particularly well
- fewer ops attended (in particular there were fewer from outside the US)
- Some of the proposed sessions were not well vetted
- some ops who did attend stated the event identity was diluted, it was
less attractive
- we tried to adjust the day 2 schedule to include late submissions,
however it was probably too late in some cases

I don't think it's so important to drill down into all the whys and
wherefores of how we fell down here except to say that the ops meetups team
is a small bunch of volunteers all with day jobs (presumably just like
everyone else on this mailing list). The usual, basically.

Much more important : what will be done to improve things going forward:

- The User Committee has offered to get involved with the technical
content. In particular to bring forward topics from other relevant events
into the ops meetup planning process, and then take output from ops meetups
forward to subsequent events. We (ops meetup team) have welcomed this.

- The Ops Meetups Team will endeavor to start topic selection earlier and
have a more critical approach. Having a longer list of possible sessions
(when starting with material from earlier events) should make it at least
possible to devise a better agenda. Agenda quality drives attendance to
some extent and so can ensure a virtuous circle.

- We need to work out whether we're doing fixed schedule events (similar to
previous mid-cycle Ops Meetups) or fully flexible PTG-style events, but
grafting one onto the other ad-hoc clearly is a terrible idea. This needs
more discussion.

- The Ops Meetups Team continues to explore strange new worlds, or at least
get in touch with more and more OpenStack operators to find out what the
meetups team and these events could do for them and hence drive the process
better. One specific work item here is to help the (widely disparate)
operator community with technical issues such as getting setup with the
openstack git/gerrit and IRC. The latter is the preferred way for the
community to meet, but is particularly difficult now with the registered
nickname requirement. We will add help documentation on how to get over
this hurdle.

- YOUR SUGGESTION HERE

Chris

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

Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] [tc]Global Reachout Proposal

[Thierry Carrez]

Sylvain Bauza wrote:



Le mar. 18 sept. 2018 à 14:41, Jeremy Stanley > a écrit :


On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
[...]
 > I can understand that IRC cannot be used in China which is very
 > painful and mostly it is used weChat.
[...]

I have yet to hear anyone provide first-hand confirmation that
access to Freenode's IRC servers is explicitly blocked by the
mainland Chinese government. There has been a lot of speculation
that the usual draconian corporate firewall policies (surprise, the
rest of the World gets to struggle with those too, it's not just a
problem in China) are blocking a variety of messaging protocols from
workplace networks and the people who encounter this can't tell the
difference because they're already accustomed to much of their other
communications being blocked at the border. I too have heard from
someone who's heard from someone that "IRC can't be used in China"
but the concrete reasons why continue to be missing from these
discussions.

Thanks fungi, that's the crux of the problem I'd like to see discussed 
in the governance change.
In this change, it states the non-use of existing and official 
communication tools as to be "cumbersome". See my comment on PS1, I 
thought the original concern was technical.


Why are we discussing about WeChat now ? Is that because a large set of 
our contributors *can't* access IRC or because they *prefer* any other ?
In the past, we made clear for a couple of times why IRC is our 
communication channel. I don't see those reasons to be invalid now, but 
I'm still open to understand the problems about why our community 
becomes de facto fragmented.


Agreed, I'm still trying to grasp the issue we are trying to solve here.

We really need to differentiate between technical blockers (firewall), 
cultural blockers (language) and network effect preferences (preferred 
platform).


We should definitely try to address technical blockers, as we don't want 
to exclude anyone. We can also allow for a bit of flexibility in the 
tools used in our community, to accommodate cultural blockers as much as 
we possibly can (keeping in mind that in the end, the code has to be 
written, proposed and discussed in a single language). We can even 
encourage community members to reach out on local social networks... But 
I'm reluctant to pass an official resolution to recommend that TC 
members engage on specific platforms because "everyone is there".


--
Thierry Carrez (ttx)

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

Re: [Openstack-operators] [openstack-dev] [Openstack-sigs] [tc]Global Reachout Proposal

[Jeremy Stanley]

On 2018-09-18 14:52:28 +0200 (+0200), Sylvain Bauza wrote:
[...]
> Why are we discussing about WeChat now? Is that because a large
> set of our contributors *can't* access IRC or because they
> *prefer* any other?

Until we get confirmation either way, I'm going to work under the
assumption that there are actual network barriers to using IRC for
these contributors and that it's not just a matter of preference. I
mainly want to know the source of these barriers because that will
determine how to go about addressing them.

If it's restrictions imposed by employers, it may be hard for
employees to raise the issue in predominantly confrontation-averse
cultures. The First Contact SIG is working on a document which
outlines the communications and workflows used by our community with
a focus on explaining to managers and other staff at contributing
organizations what allowances they can make to ease and improve the
experience of those they've tasked with working upstream.

If the barriers are instead imposed by national government, then
urging contributors within those borders to flaunt the law and
interact with the rest of our community over IRC is not something
which should be taken lightly. That's not to say it can't be solved,
but the topic then is a much more political one and our community
may not be an appropriate venue for those discussions.

> In the past, we made clear for a couple of times why IRC is our
> communication channel. I don't see those reasons to be invalid
> now, but I'm still open to understand the problems about why our
> community becomes de facto fragmented.

I think the extended community is already fragmented across a
variety of discussion fora. Some watch for relevant hashtags on
Twitter and engage in discussions there. I gather there's an
unofficial OpenStack Slack channel where lots of newcomers show up
to ask questions because they assume the OpenStack community relies
on Slack the same way the Kubernetes community does, and so a few
volunteers from our community hang out there and try to redirect
questions to more appropriate places. I've also heard tell of an
OpenStack subReddit which some stackers help moderate and try to
provide damage control/correct misstatements there. I don't think
these are necessarily a problem, and the members of our community
who work to spread accurate information to these places are in many
cases helping reduce the actual degree of fragmentation.

I'm still trying to make up my mind on 602697 which is why I haven't
weighed in on the proposal yet. So far I feel like it probably
doesn't bring anything new, since we already declare how and where
official discussion takes place and the measure doesn't make any
attempt to change that. We also don't regulate where unofficial
discussions are allowed to take place, and so it doesn't open up any
new possibilities which were previously disallowed.
-- 
Jeremy Stanley


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

[Openstack-operators] OpenStack Ops Meetups team meeting in ~40 minutes

[Chris Morgan]

Calendar link http://eavesdrop.openstack.org/calendars/ops-meetup-team.ics

Join us on #openstack-operators to discuss last weeks embedded ops meetup
at the Denver PTG, the upcoming Forum at the Summit in Berlin this November
and possible meetups in 2019.

Chris

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

Re: [Openstack-operators] [Openstack-sigs] [tc]Global Reachout Proposal

[Jeremy Stanley]

On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote:
[...]
> I can understand that IRC cannot be used in China which is very
> painful and mostly it is used weChat.
[...]

I have yet to hear anyone provide first-hand confirmation that
access to Freenode's IRC servers is explicitly blocked by the
mainland Chinese government. There has been a lot of speculation
that the usual draconian corporate firewall policies (surprise, the
rest of the World gets to struggle with those too, it's not just a
problem in China) are blocking a variety of messaging protocols from
workplace networks and the people who encounter this can't tell the
difference because they're already accustomed to much of their other
communications being blocked at the border. I too have heard from
someone who's heard from someone that "IRC can't be used in China"
but the concrete reasons why continue to be missing from these
discussions.
-- 
Jeremy Stanley


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