From kennelson11 at gmail.com  Fri Nov  2 00:22:49 2018
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Thu, 1 Nov 2018 17:22:49 -0700
Subject: [OpenStack-Infra] StoryBoard Forum Session: Remaining Blockers
Message-ID: <CAJ6yrQjqKNhCBzoP1szHoryQyE4ROV8YwSzajT-gPEuuY9kJ=A@mail.gmail.com>

Hello Everyone!

We've made a lot of progress in StoryBoard-land over the last couple of
releases cleaning up bugs, fixing UI annoyances, and adding features that
people have requested. All along we've also continued to migrate projects
as they've become unblocked. While there are still a few blockers on our
to-do list, we want to make sure our list is complete[1].

We have a session at the upcoming forum to collect any remaining blockers
that you may have encountered while messing around with the dev
storyboard[2] site or using the real storyboard interacting with projects
that have already migrated. If you encountered any issues that  are
blocking your project from migrating, please come share them with with
us[3]. Hope to see you there!

-Kendall (diablo_rojo) & the StoryBoard team

[1] https://storyboard.openstack.org/#!/worklist/493
[2] https://storyboard-dev.openstack.org/
[2]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22839/storyboard-migration-the-remaining-blockers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20181101/2b40306a/attachment.html>

From cboylan at sapwetik.org  Mon Nov 12 10:33:49 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Mon, 12 Nov 2018 02:33:49 -0800
Subject: [OpenStack-Infra] Meeting up Tuesday Evening for a Team Dinner (7pm
 outside main doors of citycube, near reg desk)
Message-ID: <1542018829.1477782.1573785064.15DACD43@webmail.messagingengine.com>

Hello everyone,

I'd mentioned last week that we could try and cobble together an informal team dinner Tuesday night. The marketplace mixer runs until 7:30pm Tuesday night. Why don't we pop out of that a little early and meet at 7:00 pm Tuesday night outside the main doors of the City Cube (just outside of registration desk).

>From there we can take the S-bahn back towards town and find one or more places that will sit us. On an effort level, informal and going with what works is what I have in mind. I think we should be able to find a gasthaus/brewpub type setup that will work.

I'm totally open to location ideas if anyone wants to suggest them too.

Hope to see you there,
Clark


From aj at suse.com  Tue Nov 13 18:07:05 2018
From: aj at suse.com (Andreas Jaeger)
Date: Tue, 13 Nov 2018 18:07:05 +0000
Subject: [OpenStack-Infra] Meeting up Tuesday Evening for a Team Dinner
 (7pm outside main doors of citycube, near reg desk)
In-Reply-To: <1542018829.1477782.1573785064.15DACD43@webmail.messagingengine.com>
References: <1542018829.1477782.1573785064.15DACD43@webmail.messagingengine.com>
Message-ID: <CF067D9C188A6540B840DAE0DCBEA7A658B07BC3@NWBXMB02.microfocus.com>

We are leaving now for https://www.suksan.de/

Andreas
--
Andreas Jaeger aj at suse.com
Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
 GF: Felix Imendörffer, Jane Smithard, Graham Norton,
 HRB 21284 (AG Nürnberg)
 GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126



Am 12. November 2018 11:34:58 schrieb Clark Boylan <cboylan at sapwetik.org>:

> Hello everyone,
>
> I'd mentioned last week that we could try and cobble together an informal team dinner Tuesday night. The marketplace mixer runs until 7:30pm Tuesday night. Why don't we pop out of that a little early and meet at 7:00 pm Tuesday night outside the main doors of the City Cube (just outside of registration desk).
>
> From there we can take the S-bahn back towards town and find one or more places that will sit us. On an effort level, informal and going with what works is what I have in mind. I think we should be able to find a gasthaus/brewpub type setup that will work.
>
> I'm totally open to location ideas if anyone wants to suggest them too.
>
> Hope to see you there,
> Clark
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



From aj at suse.com  Wed Nov 14 07:53:43 2018
From: aj at suse.com (Andreas Jaeger)
Date: Wed, 14 Nov 2018 08:53:43 +0100
Subject: [OpenStack-Infra] https on eavesdrop.o.o broken
Message-ID: <3058de72-ab20-b512-127d-3f240f503bff@suse.com>

Reviewing a patch that changed http://eavesdrop.o.o to https, I checked
and noticed that the URL gives a misconfiguration error. Should we stop
running Apache on port 443 for eavesdrop - or configure the server
properly with https?

Sending it here so that somebody can clean it up later and we don't
forget it...

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
       HRB 21284 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126



From cboylan at sapwetik.org  Wed Nov 14 12:24:52 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Wed, 14 Nov 2018 04:24:52 -0800
Subject: [OpenStack-Infra] https on eavesdrop.o.o broken
In-Reply-To: <3058de72-ab20-b512-127d-3f240f503bff@suse.com>
References: <3058de72-ab20-b512-127d-3f240f503bff@suse.com>
Message-ID: <1542198292.2850087.1576581160.2C2D0BC5@webmail.messagingengine.com>

On Tue, Nov 13, 2018, at 11:53 PM, Andreas Jaeger wrote:
> Reviewing a patch that changed http://eavesdrop.o.o to https, I checked
> and noticed that the URL gives a misconfiguration error. Should we stop
> running Apache on port 443 for eavesdrop - or configure the server
> properly with https?
> 
> Sending it here so that somebody can clean it up later and we don't
> forget it...
> 

Looking at the server very quickly it appears that the only thing listening on 443 there is the default vhost from apache. Maybe we should try and cleanup/remove the default vhost from all our apache web server installations?

Then separately we can add https to eavesdrop.openstack.org if we like.

Clark


From mathias at dm3.io  Sat Nov 17 17:34:35 2018
From: mathias at dm3.io (=?UTF-8?Q?Mathias_Gutehall?=)
Date: Sat, 17 Nov 2018 17:34:35 +0000
Subject: [OpenStack-Infra] Sysadmin
References: <A2EF5255-B786-4F61-819D-D2A45959A9D3@dm3.io>
Message-ID: <0100016722bd12de-924a04cc-be22-46af-8ad4-6b9dc5b929ab-000000@email.amazonses.com>

Hi all,

I just wanted to check if there’s any need for a sysadmin with long experience with Unix/Linux systems in this project? I’m based in Sweden and have been working as a sysadmin since 1995 and since the 3 years with cloud services.

Best regards Mathias


From cboylan at sapwetik.org  Sun Nov 18 18:59:46 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Sun, 18 Nov 2018 10:59:46 -0800
Subject: [OpenStack-Infra] Sysadmin
In-Reply-To: <0100016722bd12de-924a04cc-be22-46af-8ad4-6b9dc5b929ab-000000@email.amazonses.com>
References: <A2EF5255-B786-4F61-819D-D2A45959A9D3@dm3.io>
 <0100016722bd12de-924a04cc-be22-46af-8ad4-6b9dc5b929ab-000000@email.amazonses.com>
Message-ID: <1542567586.2487671.1581049536.3C0E9E3D@webmail.messagingengine.com>

On Sat, Nov 17, 2018, at 9:34 AM, Mathias Gutehall wrote:
> Hi all,
> 
> I just wanted to check if there’s any need for a sysadmin with long 
> experience with Unix/Linux systems in this project? I’m based in Sweden 
> and have been working as a sysadmin since 1995 and since the 3 years 
> with cloud services.

We are always happy to have more help running the community developer infrastructure. A good place to start is probably with this document, https://docs.openstack.org/infra/system-config/project.html, as it gives a high level overview of how we operate and are organized.

To summarize here quickly, we are a community effort to build and run developer tooling. We use code review and automated deployment tooling which allows people to contribute without having root. If you'd like to get involved and become a root the process for that is to start through the code review system and take advantage of our automated deployments.

I like to encourage individuals find a task that interests them and start from there. Some of the big efforts we currently have are:

1. Modernize configuration management
1a. Convert to ansible for configuration management (gerrit topic:update-cfg-mgmt)
1b. Update puppet 3 to puppet 4 since the ansible conversion won't happen immediately (gerrit topic:puppet-4)
1c. Use docker images and containers to deploy software, particularly that which we install from source
2. IRC bot update to handle the large number of channels we talk to with common tooling
3. Gerrit upgrade to 2.15 (may be related to 1a and 1c)
4. OpenDev transition, though this is new and doesn't have many concrete actions yet.

There are other items as well. Feel free to follow up with this list, myself or on IRC if any of this does interest you and we can go from there.

Hope this helps,
Clark


From cboylan at sapwetik.org  Sun Nov 18 19:09:29 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Sun, 18 Nov 2018 11:09:29 -0800
Subject: [OpenStack-Infra] Proposed changes to how we run our meeting
Message-ID: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>

Hello everyone,

In Berlin there was a forum session on dealing with timezones and language barriers. There were a couple related ideas that came out of that session. In particular that having meetings only when there is a strong agenda helps people avoid staying up all night for nothing and that listing an agenda ahead of time can help non english speakers better prepare for the meeting.

Both ideas seem sound to me and I think we should try to implement them for the Infra team. I propose that we require agenda updates 24 hours prior to the meeting start time and if there are no agenda updates we cancel the meeting. Curious to hear if others think this will be helpful and if 24 hours is enough lead time to be helpful.

We'll have our meeting this Tuesday (with this item on the agenda), but it would probably also be good to use the mailing list for feedback as I think that gives us a broader set of potential feedback.

Thank you,
Clark


From fungi at yuggoth.org  Sun Nov 18 20:31:33 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Sun, 18 Nov 2018 20:31:33 +0000
Subject: [OpenStack-Infra] Proposed changes to how we run our meeting
In-Reply-To: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
References: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
Message-ID: <20181118203132.nehsu4cu7gw3q3cc@yuggoth.org>

On 2018-11-18 11:09:29 -0800 (-0800), Clark Boylan wrote:
[...]
> I propose that we require agenda updates 24 hours prior to the
> meeting start time and if there are no agenda updates we cancel
> the meeting. Curious to hear if others think this will be helpful
> and if 24 hours is enough lead time to be helpful.
[...]

Sounds great to me, thanks for considering putting these ideas into
practice!
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20181118/aa812f5d/attachment.sig>

From mrhillsman at gmail.com  Sun Nov 18 20:54:04 2018
From: mrhillsman at gmail.com (Melvin Hillsman)
Date: Sun, 18 Nov 2018 14:54:04 -0600
Subject: [OpenStack-Infra] Proposed changes to how we run our meeting
In-Reply-To: <20181118203132.nehsu4cu7gw3q3cc@yuggoth.org>
References: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
 <20181118203132.nehsu4cu7gw3q3cc@yuggoth.org>
Message-ID: <CAMVtB2ES-LSW3kKDUC-ACjFwr6siV=OtjrvpL+qjwHpdajE0qg@mail.gmail.com>

++

On Sun, Nov 18, 2018 at 2:32 PM Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2018-11-18 11:09:29 -0800 (-0800), Clark Boylan wrote:
> [...]
> > I propose that we require agenda updates 24 hours prior to the
> > meeting start time and if there are no agenda updates we cancel
> > the meeting. Curious to hear if others think this will be helpful
> > and if 24 hours is enough lead time to be helpful.
> [...]
>
> Sounds great to me, thanks for considering putting these ideas into
> practice!
> --
> Jeremy Stanley
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20181118/712fdce2/attachment.html>

From jimmy at tipit.net  Mon Nov 19 01:26:30 2018
From: jimmy at tipit.net (Jimmy Mcarthur)
Date: Sun, 18 Nov 2018 19:26:30 -0600
Subject: [OpenStack-Infra] Proposed changes to how we run our meeting
In-Reply-To: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
References: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
Message-ID: <5BF21146.6010908@tipit.net>



> Clark Boylan <mailto:cboylan at sapwetik.org>
> November 18, 2018 at 1:09 PM
> Hello everyone,
>
> In Berlin there was a forum session on dealing with timezones and 
> language barriers. There were a couple related ideas that came out of 
> that session. In particular that having meetings only when there is a 
> strong agenda helps people avoid staying up all night for nothing and 
> that listing an agenda ahead of time can help non english speakers 
> better prepare for the meeting.
This is a GREAT idea.  Not just for English speakers, but for everyone. 
I'm a big fan of not having meetings just to fill time.
>
> Both ideas seem sound to me and I think we should try to implement 
> them for the Infra team. I propose that we require agenda updates 24 
> hours prior to the meeting start time and if there are no agenda 
> updates we cancel the meeting. Curious to hear if others think this 
> will be helpful and if 24 hours is enough lead time to be helpful.
Love the 24 hour lead time. Looking forward to seeing how this works and 
hope it can be adopted across other projects.
>
> We'll have our meeting this Tuesday (with this item on the agenda), 
> but it would probably also be good to use the mailing list for 
> feedback as I think that gives us a broader set of potential feedback.

Thanks for taking the lead on this Clark!  Nice work :)
>
> Thank you,
> Clark
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20181118/d2dce680/attachment.html>

From iwienand at redhat.com  Tue Nov 20 19:49:31 2018
From: iwienand at redhat.com (Ian Wienand)
Date: Wed, 21 Nov 2018 06:49:31 +1100
Subject: [OpenStack-Infra] Proposed changes to how we run our meeting
In-Reply-To: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
References: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
Message-ID: <20181120194931.GA7721@fedora19.localdomain>

On Sun, Nov 18, 2018 at 11:09:29AM -0800, Clark Boylan wrote:
> Both ideas seem sound to me and I think we should try to implement
> them for the Infra team. I propose that we require agenda updates 24
> hours prior to the meeting start time and if there are no agenda
> updates we cancel the meeting. Curious to hear if others think this
> will be helpful and if 24 hours is enough lead time to be helpful.

My concern here is that we have standing items of priority tasks
updates that are essentially always there, and action item follow-up
from the prior meeting.  Personally I often find them very useful.

Having attended many in-person waffling weekly "status update"
meetings etc. I feel the infra one *is* very agenda focused.  I also
think there is never an expectation anyone is in the meeting; in fact
more so that we actively understand and expect people aren't there.

So I think it would be fine to send out the agenda 24 hours in
advance, and make a rule that new items post that will skip to the
next week, so that if there's nothing of particular interest people
can plan to skip.

This would involve managing the wiki page better IMO.  I always try to
tag my items with my name and date for discussion because clearing it
out is an asychronous operation.  What if we made the final thing in
the meeting after general discussion "reset agenda" so we have a
synchronisation point, and then clearly mark on the wiki page that
it's now for the next meeting date?

But I don't like that infra in general skips the meeting.  Apart from
the aforementioned standing items, people start thinking "oh my thing
is just little, I don't want to call a meeting for it" which is the
opposite of what we want to keep communication flowing.  For people
actively involved but remote like myself, it's a loss of a very
valuable hour to catch up on what's happening even with just the
regular updates.

-i


From cboylan at sapwetik.org  Tue Nov 20 20:53:42 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Tue, 20 Nov 2018 12:53:42 -0800
Subject: [OpenStack-Infra] Proposed changes to how we run our meeting
In-Reply-To: <20181120194931.GA7721@fedora19.localdomain>
References: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
 <20181120194931.GA7721@fedora19.localdomain>
Message-ID: <1542747222.1362720.1583689936.5F9FFC66@webmail.messagingengine.com>

On Tue, Nov 20, 2018, at 11:49 AM, Ian Wienand wrote:
> On Sun, Nov 18, 2018 at 11:09:29AM -0800, Clark Boylan wrote:
> > Both ideas seem sound to me and I think we should try to implement
> > them for the Infra team. I propose that we require agenda updates 24
> > hours prior to the meeting start time and if there are no agenda
> > updates we cancel the meeting. Curious to hear if others think this
> > will be helpful and if 24 hours is enough lead time to be helpful.
> 
> My concern here is that we have standing items of priority tasks
> updates that are essentially always there, and action item follow-up
> from the prior meeting.  Personally I often find them very useful.
> 
> Having attended many in-person waffling weekly "status update"
> meetings etc. I feel the infra one *is* very agenda focused.  I also
> think there is never an expectation anyone is in the meeting; in fact
> more so that we actively understand and expect people aren't there.
> 
> So I think it would be fine to send out the agenda 24 hours in
> advance, and make a rule that new items post that will skip to the
> next week, so that if there's nothing of particular interest people
> can plan to skip.
> 
> This would involve managing the wiki page better IMO.  I always try to
> tag my items with my name and date for discussion because clearing it
> out is an asychronous operation.  What if we made the final thing in
> the meeting after general discussion "reset agenda" so we have a
> synchronisation point, and then clearly mark on the wiki page that
> it's now for the next meeting date?
> 
> But I don't like that infra in general skips the meeting.  Apart from
> the aforementioned standing items, people start thinking "oh my thing
> is just little, I don't want to call a meeting for it" which is the
> opposite of what we want to keep communication flowing.  For people
> actively involved but remote like myself, it's a loss of a very
> valuable hour to catch up on what's happening even with just the
> regular updates.
> 
> -i

Given that the goal here is to better accommodate those in timezones where the meeting may not be the easiest to attend I think this feedback is important.

What if instead of canceling meetings we allowed for standing agenda items with the expectation that the meeting continues to be weekly, but ask that any new agenda items be in place 24 hours before the meeting start time. Anything that comes in after that can be deferred to the next meeting.

This allows people to prepare as necessary and skip the meeting if it doesn't directly impact them.

To summarize: "Meeting agenda items should be in place 24 hours prior to meeting start. We will continue to have standing items for priority efforts and meetings will occur weekly. If a specific agenda doesn't directly affect you, you should feel free to skip the meeting and eat dinner or get some rest"

Clark


From fungi at yuggoth.org  Tue Nov 20 21:03:36 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 20 Nov 2018 21:03:36 +0000
Subject: [OpenStack-Infra] Proposed changes to how we run our meeting
In-Reply-To: <20181120194931.GA7721@fedora19.localdomain>
References: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
 <20181120194931.GA7721@fedora19.localdomain>
Message-ID: <20181120210336.qdt355doc25nicrc@yuggoth.org>

On 2018-11-21 06:49:31 +1100 (+1100), Ian Wienand wrote:
> On Sun, Nov 18, 2018 at 11:09:29AM -0800, Clark Boylan wrote:
> > Both ideas seem sound to me and I think we should try to implement
> > them for the Infra team. I propose that we require agenda updates 24
> > hours prior to the meeting start time and if there are no agenda
> > updates we cancel the meeting. Curious to hear if others think this
> > will be helpful and if 24 hours is enough lead time to be helpful.
> 
> My concern here is that we have standing items of priority tasks
> updates that are essentially always there, and action item follow-up
> from the prior meeting.  Personally I often find them very useful.
[...]

Back when I was chairing these meetings regularly, I urged
participants to add info within each priority effort (or added some
myself) in advance of the meeting. If there was nothing called out
in our agenda under a given priority effort entry, I skipped over
it. Going back to something like that could help us figure out when
a meeting is warranted rather than ending up as a series of "nothing
new here" comments.

But this aside, I think the frequency with which we'd end up
skipping meetings (based on history of our agenda updates) will be
low enough that we shouldn't really focus on that part of the
proposal. I agree what's important is having our agenda nailed down
in advance so people can decide whether or not it's important for
them to attend. We do sometimes skip meetings for various reasons
anyway, so rarely announcing we won't hold one because nobody has
any updates or topics on the agenda feels like an incentive for
people to find relevant topics so that doesn't happen often.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20181120/998d3803/attachment.sig>

From joshua.hesketh at gmail.com  Wed Nov 21 01:43:44 2018
From: joshua.hesketh at gmail.com (Joshua Hesketh)
Date: Wed, 21 Nov 2018 12:43:44 +1100
Subject: [OpenStack-Infra] Proposed changes to how we run our meeting
In-Reply-To: <1542747222.1362720.1583689936.5F9FFC66@webmail.messagingengine.com>
References: <1542568169.2489726.1581053632.6B1EA950@webmail.messagingengine.com>
 <20181120194931.GA7721@fedora19.localdomain>
 <1542747222.1362720.1583689936.5F9FFC66@webmail.messagingengine.com>
Message-ID: <CA+DTi5z=uTn_7R0jef2+X7+KnXxuAPM+p0U291vSAPxrZa73+A@mail.gmail.com>

I admit that I rarely attend the meeting these days but I do generally keep
an eye on the agenda and minutes. So for me I really appreciate that we
have an agenda and generally follow it. Being more structured and prepared
with it though would allow me to see which meetings I should make an effort
to attend. I have no objection to the meeting being held each week with any
standing items or even items from the floor, but clearly those that are
published with enough notice are more likely to get attendance.

Cheers,
Josh

On Wed, Nov 21, 2018 at 7:55 AM Clark Boylan <cboylan at sapwetik.org> wrote:

> On Tue, Nov 20, 2018, at 11:49 AM, Ian Wienand wrote:
> > On Sun, Nov 18, 2018 at 11:09:29AM -0800, Clark Boylan wrote:
> > > Both ideas seem sound to me and I think we should try to implement
> > > them for the Infra team. I propose that we require agenda updates 24
> > > hours prior to the meeting start time and if there are no agenda
> > > updates we cancel the meeting. Curious to hear if others think this
> > > will be helpful and if 24 hours is enough lead time to be helpful.
> >
> > My concern here is that we have standing items of priority tasks
> > updates that are essentially always there, and action item follow-up
> > from the prior meeting.  Personally I often find them very useful.
> >
> > Having attended many in-person waffling weekly "status update"
> > meetings etc. I feel the infra one *is* very agenda focused.  I also
> > think there is never an expectation anyone is in the meeting; in fact
> > more so that we actively understand and expect people aren't there.
> >
> > So I think it would be fine to send out the agenda 24 hours in
> > advance, and make a rule that new items post that will skip to the
> > next week, so that if there's nothing of particular interest people
> > can plan to skip.
> >
> > This would involve managing the wiki page better IMO.  I always try to
> > tag my items with my name and date for discussion because clearing it
> > out is an asychronous operation.  What if we made the final thing in
> > the meeting after general discussion "reset agenda" so we have a
> > synchronisation point, and then clearly mark on the wiki page that
> > it's now for the next meeting date?
> >
> > But I don't like that infra in general skips the meeting.  Apart from
> > the aforementioned standing items, people start thinking "oh my thing
> > is just little, I don't want to call a meeting for it" which is the
> > opposite of what we want to keep communication flowing.  For people
> > actively involved but remote like myself, it's a loss of a very
> > valuable hour to catch up on what's happening even with just the
> > regular updates.
> >
> > -i
>
> Given that the goal here is to better accommodate those in timezones where
> the meeting may not be the easiest to attend I think this feedback is
> important.
>
> What if instead of canceling meetings we allowed for standing agenda items
> with the expectation that the meeting continues to be weekly, but ask that
> any new agenda items be in place 24 hours before the meeting start time.
> Anything that comes in after that can be deferred to the next meeting.
>
> This allows people to prepare as necessary and skip the meeting if it
> doesn't directly impact them.
>
> To summarize: "Meeting agenda items should be in place 24 hours prior to
> meeting start. We will continue to have standing items for priority efforts
> and meetings will occur weekly. If a specific agenda doesn't directly
> affect you, you should feel free to skip the meeting and eat dinner or get
> some rest"
>
> Clark
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20181121/4d1a02e0/attachment.html>

From honjo.rikimaru at po.ntt-tx.co.jp  Mon Nov 26 11:05:07 2018
From: honjo.rikimaru at po.ntt-tx.co.jp (Rikimaru Honjo)
Date: Mon, 26 Nov 2018 20:05:07 +0900
Subject: [OpenStack-Infra] Can you add my CI account to Third-Party CI group?
Message-ID: <c6b03b51-15dc-64a9-4221-ea87f28c2c50@po.ntt-tx.co.jp>

Hello,

I prepared a third party CI for masakari project.
And, it is already enabled.

https://wiki.openstack.org/wiki/ThirdPartySystems/NTT_SystemFault_MasakariIntegration_CI

Can you add the following account to Third-Party CI group[1]?

NTT SystemFault MasakariIntegration CI: masakari.integration.test at gmail.com

[1]https://review.openstack.org/#/admin/groups/270

Best Regards,
-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Rikimaru Honjo
E-mail:honjo.rikimaru at po.ntt-tx.co.jp




From mihailmed at gmail.com  Mon Nov 26 18:22:14 2018
From: mihailmed at gmail.com (Mikhail M)
Date: Mon, 26 Nov 2018 12:22:14 -0600
Subject: [OpenStack-Infra] Can you add my CI account to Third-Party CI
	group?
In-Reply-To: <c6b03b51-15dc-64a9-4221-ea87f28c2c50@po.ntt-tx.co.jp>
References: <c6b03b51-15dc-64a9-4221-ea87f28c2c50@po.ntt-tx.co.jp>
Message-ID: <CAOKdo97FC0=stDwu0qg8E22KOD_uDHth7Ewn2F1ScfmjvWr7KA@mail.gmail.com>

Hi Rikimaru,

NTT SystemFault MasakariIntegration CI
<masakari.integration.test at gmail.com> has been added to the
third-party CI email filter group.

---
Mikhail Medvedev
IBM
On Mon, Nov 26, 2018 at 5:07 AM Rikimaru Honjo
<honjo.rikimaru at po.ntt-tx.co.jp> wrote:
>
> Hello,
>
> I prepared a third party CI for masakari project.
> And, it is already enabled.
>
> https://wiki.openstack.org/wiki/ThirdPartySystems/NTT_SystemFault_MasakariIntegration_CI
>
> Can you add the following account to Third-Party CI group[1]?
>
> NTT SystemFault MasakariIntegration CI: masakari.integration.test at gmail.com
>
> [1]https://review.openstack.org/#/admin/groups/270
>
> Best Regards,
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> Rikimaru Honjo
> E-mail:honjo.rikimaru at po.ntt-tx.co.jp
>
>
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


From graham.whaley at intel.com  Tue Nov 27 18:53:16 2018
From: graham.whaley at intel.com (Whaley, Graham)
Date: Tue, 27 Nov 2018 18:53:16 +0000
Subject: [OpenStack-Infra] Adding index and views/dashboards for Kata to
	ELK stack
In-Reply-To: <1540314157.1272773.1551970776.0C80340F@webmail.messagingengine.com>
References: <01D2D3EEA433C0419A12152B3A36557E204E9663@IRSMSX101.ger.corp.intel.com>
 <01D2D3EEA433C0419A12152B3A36557E204F18E7@IRSMSX101.ger.corp.intel.com>
 <1539879007.3697557.1546669152.55C51D64@webmail.messagingengine.com>
 <01D2D3EEA433C0419A12152B3A36557E204F3B6D@IRSMSX101.ger.corp.intel.com>
 <1540314157.1272773.1551970776.0C80340F@webmail.messagingengine.com>
Message-ID: <01D2D3EEA433C0419A12152B3A36557E2051318D@IRSMSX101.ger.corp.intel.com>

(back to an old thread... this has rippled near the top of my pile again)

> -----Original Message-----
> From: Clark Boylan [mailto:cboylan at sapwetik.org]
> Sent: Tuesday, October 23, 2018 6:03 PM
> To: Whaley, Graham <graham.whaley at intel.com>; openstack-
> infra at lists.openstack.org; thierry at openstack.org
> Cc: Ernst, Eric <eric.ernst at intel.com>; fungi at yuggoth.org
> Subject: Re: Adding index and views/dashboards for Kata to ELK stack
[snip]
> > I don't think the Zuul Ansible role will be applicable - the metrics run
> > on bare metal machines running Jenkins, and export their JSON results
> > via a filebeat socket. My theory was we'd then add the socket input to
> > the logstash server to receive from that filebeat - as in my gist at
> >
> https://gist.github.com/grahamwhaley/aa730e6bbd6a8ceab82129042b186467
> 
> I don't think we would want to expose write access to the unauthenticated
> logstash and elasticsearch system to external systems. The thing that makes this
> secure today is we (community infrastructure team) control the existing writers.
> The existing writers are available for your use (see below) should you decide to
> use them.

My theory was we'd secure the connection at least using the logstash/beat SSL connection, and only we/the infra group would have access to the keys:
https://www.elastic.co/guide/en/beats/filebeat/current/configuring-ssl-logstash.html

The machines themselves are only accessible by the CNCF CIL owners and nominated Kata engineers with the keys.
> 
> >
> > One crux here is that the metrics have to run on a machine with
> > guaranteed performance (so not a shared/virtual cloud instance), and
> > hence currently run under Jenkins and not on the OSF/Zuul CI infra.
> 
> Zuul (by way of Nodepool) can speak to arbitrary machines as long as they speak
> an ansible connection protocol. In this case the default of ssh would probably
> work when tied to nodepool's static instance driver. The community
> infrastructure happens to only talk to cloud VMs today because that is what we
> have been given access to, but should be able to talk to other resources if
> people show up with them.

If we ignore the fact that all current Kata CI is running on Jenkins, and we are not presently transitioning to Zuul afaik, then....
Even if we did integrate the bare metal CNCF CIL packet.net machines vi ansible/SSH/nodepool/Zuul, then afaict you'd still be running the same CI tasks on the same machines and injecting the Elastic data through the same SSL socket/tunnel into Elastic.
I know you'd like to keep as much of the infra under your control, but the only bit I think that would be different is the Jenkins Master. Given the Jenkins job running the slave only executes master branch merges, which have undergone peer review (which would be the same jobs that Zuul would run), then I'm not sure there is any security difference here in reality between having the Kata Jenkins master or Zuul drive the slaves.

> 
> >
> > Let me know you see any issues with that Jenkins/filebeat/socket/JSON flow.
> >
> > I need to deploy a new machine to process master branch merges to
> > generate the data (currently we have a machine that is processing PRs at
> > submission, not merge, which is not the data we want to track long
> > term). I'll let you know when I have that up and running. If we wanted
> > to move on this earlier, then I could inject data to a test index from
> > my local test setup - all it would need I believe is the valid keys for
> > the filebeat->logstash connection.

Oh, I've deployed a Jenkins slave and job to test out the first stage of the flow btw:
http://jenkins.katacontainers.io/job/kata-metrics-runtime-ubuntu-16-04-master/

> >
> > > Clark
> > Thanks!
> >   Graham (now on copy ;-)
> 
> Ideally we'd make use of the existing community infrastructure as much as
> possible to make this sustainable and secure. We are happy to modify our
> existing tooling as necessary to do this. Update the logstash configuration, add
> Nodepool resources, have grafana talk to elasticsearch, and so on.

I think the only key decision is if we can use the packet.net slaves as driven by the kata Jenkins master, or if we have to move the management of those into Zuul.
For expediency and consistency with the rest of the Kata CI, obviously I lean heavily towards Jenkins.
If we do have to go with Zuul, then I think we'll have to work out who has access to and how they can modify the Zuul job configs for Kata.

(adding Salvador to CC, as he is the Kata Jenkins owner mostly, and has also worked on the Zuul PoC for Kata before).

 Graham (hoping we can come to some agreement :-) )
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

From pabelanger at redhat.com  Tue Nov 27 22:00:20 2018
From: pabelanger at redhat.com (Paul Belanger)
Date: Tue, 27 Nov 2018 17:00:20 -0500
Subject: [OpenStack-Infra] Adding index and views/dashboards for Kata to
 ELK stack
In-Reply-To: <01D2D3EEA433C0419A12152B3A36557E2051318D@IRSMSX101.ger.corp.intel.com>
References: <01D2D3EEA433C0419A12152B3A36557E204E9663@IRSMSX101.ger.corp.intel.com>
 <01D2D3EEA433C0419A12152B3A36557E204F18E7@IRSMSX101.ger.corp.intel.com>
 <1539879007.3697557.1546669152.55C51D64@webmail.messagingengine.com>
 <01D2D3EEA433C0419A12152B3A36557E204F3B6D@IRSMSX101.ger.corp.intel.com>
 <1540314157.1272773.1551970776.0C80340F@webmail.messagingengine.com>
 <01D2D3EEA433C0419A12152B3A36557E2051318D@IRSMSX101.ger.corp.intel.com>
Message-ID: <20181127220020.GA12781@localhost.localdomain>

On Tue, Nov 27, 2018 at 06:53:16PM +0000, Whaley, Graham wrote:
> (back to an old thread... this has rippled near the top of my pile again)
> 
> > -----Original Message-----
> > From: Clark Boylan [mailto:cboylan at sapwetik.org]
> > Sent: Tuesday, October 23, 2018 6:03 PM
> > To: Whaley, Graham <graham.whaley at intel.com>; openstack-
> > infra at lists.openstack.org; thierry at openstack.org
> > Cc: Ernst, Eric <eric.ernst at intel.com>; fungi at yuggoth.org
> > Subject: Re: Adding index and views/dashboards for Kata to ELK stack
> [snip]
> > > I don't think the Zuul Ansible role will be applicable - the metrics run
> > > on bare metal machines running Jenkins, and export their JSON results
> > > via a filebeat socket. My theory was we'd then add the socket input to
> > > the logstash server to receive from that filebeat - as in my gist at
> > >
> > https://gist.github.com/grahamwhaley/aa730e6bbd6a8ceab82129042b186467
> > 
> > I don't think we would want to expose write access to the unauthenticated
> > logstash and elasticsearch system to external systems. The thing that makes this
> > secure today is we (community infrastructure team) control the existing writers.
> > The existing writers are available for your use (see below) should you decide to
> > use them.
> 
> My theory was we'd secure the connection at least using the logstash/beat SSL connection, and only we/the infra group would have access to the keys:
> https://www.elastic.co/guide/en/beats/filebeat/current/configuring-ssl-logstash.html
> 
> The machines themselves are only accessible by the CNCF CIL owners and nominated Kata engineers with the keys.
>
> > 
> > >
> > > One crux here is that the metrics have to run on a machine with
> > > guaranteed performance (so not a shared/virtual cloud instance), and
> > > hence currently run under Jenkins and not on the OSF/Zuul CI infra.
> > 
> > Zuul (by way of Nodepool) can speak to arbitrary machines as long as they speak
> > an ansible connection protocol. In this case the default of ssh would probably
> > work when tied to nodepool's static instance driver. The community
> > infrastructure happens to only talk to cloud VMs today because that is what we
> > have been given access to, but should be able to talk to other resources if
> > people show up with them.
> 
> If we ignore the fact that all current Kata CI is running on Jenkins, and we are not presently transitioning to Zuul afaik, then....
> Even if we did integrate the bare metal CNCF CIL packet.net machines vi ansible/SSH/nodepool/Zuul, then afaict you'd still be running the same CI tasks on the same machines and injecting the Elastic data through the same SSL socket/tunnel into Elastic.

John Studarus at OpenStack summit gave a talk about using zuul and
packet.net, during the talk he mentioned starting to work on a nodepool
driver for packet.net bare metal servers.  I believe the plan is to
upstream it, which then allows for both static and packet.net dynamic
provider.

> I know you'd like to keep as much of the infra under your control, but the only bit I think that would be different is the Jenkins Master. Given the Jenkins job running the slave only executes master branch merges, which have undergone peer review (which would be the same jobs that Zuul would run), then I'm not sure there is any security difference here in reality between having the Kata Jenkins master or Zuul drive the slaves.
> 
> > 
> > >
> > > Let me know you see any issues with that Jenkins/filebeat/socket/JSON flow.
> > >
> > > I need to deploy a new machine to process master branch merges to
> > > generate the data (currently we have a machine that is processing PRs at
> > > submission, not merge, which is not the data we want to track long
> > > term). I'll let you know when I have that up and running. If we wanted
> > > to move on this earlier, then I could inject data to a test index from
> > > my local test setup - all it would need I believe is the valid keys for
> > > the filebeat->logstash connection.
> 
> Oh, I've deployed a Jenkins slave and job to test out the first stage of the flow btw:
> http://jenkins.katacontainers.io/job/kata-metrics-runtime-ubuntu-16-04-master/
> 
> > >
> > > > Clark
> > > Thanks!
> > >   Graham (now on copy ;-)
> > 
> > Ideally we'd make use of the existing community infrastructure as much as
> > possible to make this sustainable and secure. We are happy to modify our
> > existing tooling as necessary to do this. Update the logstash configuration, add
> > Nodepool resources, have grafana talk to elasticsearch, and so on.
> 
> I think the only key decision is if we can use the packet.net slaves as driven by the kata Jenkins master, or if we have to move the management of those into Zuul.
> For expediency and consistency with the rest of the Kata CI, obviously I lean heavily towards Jenkins.
> If we do have to go with Zuul, then I think we'll have to work out who has access to and how they can modify the Zuul job configs for Kata.
> 
> (adding Salvador to CC, as he is the Kata Jenkins owner mostly, and has also worked on the Zuul PoC for Kata before).
> 
>  Graham (hoping we can come to some agreement :-) )



From cboylan at sapwetik.org  Tue Nov 27 23:15:34 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Tue, 27 Nov 2018 15:15:34 -0800
Subject: [OpenStack-Infra] Adding index and views/dashboards for Kata to
	ELK stack
In-Reply-To: <01D2D3EEA433C0419A12152B3A36557E2051318D@IRSMSX101.ger.corp.intel.com>
References: <01D2D3EEA433C0419A12152B3A36557E204E9663@IRSMSX101.ger.corp.intel.com>
 <01D2D3EEA433C0419A12152B3A36557E204F18E7@IRSMSX101.ger.corp.intel.com>
 <1539879007.3697557.1546669152.55C51D64@webmail.messagingengine.com>
 <01D2D3EEA433C0419A12152B3A36557E204F3B6D@IRSMSX101.ger.corp.intel.com>
 <1540314157.1272773.1551970776.0C80340F@webmail.messagingengine.com>
 <01D2D3EEA433C0419A12152B3A36557E2051318D@IRSMSX101.ger.corp.intel.com>
Message-ID: <1543360534.3763086.1591115768.53DF7B8A@webmail.messagingengine.com>

On Tue, Nov 27, 2018, at 10:53 AM, Whaley, Graham wrote:
> (back to an old thread... this has rippled near the top of my pile again)
> 
> > -----Original Message-----
> > From: Clark Boylan [mailto:cboylan at sapwetik.org]
> > Sent: Tuesday, October 23, 2018 6:03 PM
> > To: Whaley, Graham <graham.whaley at intel.com>; openstack-
> > infra at lists.openstack.org; thierry at openstack.org
> > Cc: Ernst, Eric <eric.ernst at intel.com>; fungi at yuggoth.org
> > Subject: Re: Adding index and views/dashboards for Kata to ELK stack
> [snip]
> > > I don't think the Zuul Ansible role will be applicable - the metrics run
> > > on bare metal machines running Jenkins, and export their JSON results
> > > via a filebeat socket. My theory was we'd then add the socket input to
> > > the logstash server to receive from that filebeat - as in my gist at
> > >
> > https://gist.github.com/grahamwhaley/aa730e6bbd6a8ceab82129042b186467
> > 
> > I don't think we would want to expose write access to the unauthenticated
> > logstash and elasticsearch system to external systems. The thing that makes this
> > secure today is we (community infrastructure team) control the existing writers.
> > The existing writers are available for your use (see below) should you decide to
> > use them.
> 
> My theory was we'd secure the connection at least using the logstash/
> beat SSL connection, and only we/the infra group would have access to 
> the keys:
> https://www.elastic.co/guide/en/beats/filebeat/current/configuring-ssl-logstash.html
> 
> The machines themselves are only accessible by the CNCF CIL owners and 
> nominated Kata engineers with the keys.
> > 
> > >
> > > One crux here is that the metrics have to run on a machine with
> > > guaranteed performance (so not a shared/virtual cloud instance), and
> > > hence currently run under Jenkins and not on the OSF/Zuul CI infra.
> > 
> > Zuul (by way of Nodepool) can speak to arbitrary machines as long as they speak
> > an ansible connection protocol. In this case the default of ssh would probably
> > work when tied to nodepool's static instance driver. The community
> > infrastructure happens to only talk to cloud VMs today because that is what we
> > have been given access to, but should be able to talk to other resources if
> > people show up with them.
> 
> If we ignore the fact that all current Kata CI is running on Jenkins, 
> and we are not presently transitioning to Zuul afaik, then....
> Even if we did integrate the bare metal CNCF CIL packet.net machines vi 
> ansible/SSH/nodepool/Zuul, then afaict you'd still be running the same 
> CI tasks on the same machines and injecting the Elastic data through the 
> same SSL socket/tunnel into Elastic.

No, we would inject the data through the existing test node -> Zuul -> Logstash -> Elasticsearch path.

> I know you'd like to keep as much of the infra under your control, but 
> the only bit I think that would be different is the Jenkins Master. 
> Given the Jenkins job running the slave only executes master branch 
> merges, which have undergone peer review (which would be the same jobs 
> that Zuul would run), then I'm not sure there is any security difference 
> here in reality between having the Kata Jenkins master or Zuul drive the 
> slaves.

There is more to it than that. This service is part of the CI system we operate. The way you consume it is through the use of Zuul jobs. If you want to inject data into our Logstash/Elasticsearch system you do that by configuring your jobs in Zuul to do so. We are not in the business of operating one off solutions to problems. We support a large variety of users and projects and using generic flexible systems like this one is how we make that viable.

Additionally these systems are community managed so that we can work together to solve these problems in a way that gives the infra team appropriate administrative access while still allowing you and others to get specific work done. Rather than avoid this tooling can we please attempt to use it when it has preexisting solutions to problems like this? We will happily do our best to make re-consumption of existing systems a success, but building one off solutions to solve problems that are already solved does not scale.

> 
> > 
> > >
> > > Let me know you see any issues with that Jenkins/filebeat/socket/JSON flow.
> > >
> > > I need to deploy a new machine to process master branch merges to
> > > generate the data (currently we have a machine that is processing PRs at
> > > submission, not merge, which is not the data we want to track long
> > > term). I'll let you know when I have that up and running. If we wanted
> > > to move on this earlier, then I could inject data to a test index from
> > > my local test setup - all it would need I believe is the valid keys for
> > > the filebeat->logstash connection.
> 
> Oh, I've deployed a Jenkins slave and job to test out the first stage of 
> the flow btw:
> http://jenkins.katacontainers.io/job/kata-metrics-runtime-ubuntu-16-04-master/
> 
> > >
> > > > Clark
> > > Thanks!
> > >   Graham (now on copy ;-)
> > 
> > Ideally we'd make use of the existing community infrastructure as much as
> > possible to make this sustainable and secure. We are happy to modify our
> > existing tooling as necessary to do this. Update the logstash configuration, add
> > Nodepool resources, have grafana talk to elasticsearch, and so on.
> 
> I think the only key decision is if we can use the packet.net slaves as 
> driven by the kata Jenkins master, or if we have to move the management 
> of those into Zuul.
> For expediency and consistency with the rest of the Kata CI, obviously I 
> lean heavily towards Jenkins.
> If we do have to go with Zuul, then I think we'll have to work out who 
> has access to and how they can modify the Zuul job configs for Kata.

I wasn't directly involved with the decision making at the time but back at the beginning of the year my understanding was that Jenkins was chosen over Zuul for expediency. This wasn't a bad choice as the Github support in Zuul was still quite new (though having more users would likely have pushed it along more quickly). It probably would be worthwhile to decide separately if Jenkins is the permanent solution to the Kata CI tooling problem, or if we should continue to push for Zuul. If we want to push for Zuul then I think we need to stop choosing Jenkins as a default and start implementing new stuff in Zuul then move the existing CI as Kata is able.

As for who has Zuul access, the Infra team has administrative access to the service. Zuul configuration for the existing Kata jobs is done through a repo managed by the infra team, but anyone can push and propose changes to this repo. The reason for this is Zuul wants to gate its config updates to prevent new configs from being merged without being tested. Bypassing this testing does allow you to break your Zuul configuration. Currently we aren't gating Kata with Zuul so the configs live in the Infra repo. If we started gating Kata changes with Zuul we could move the configs into Kata repos and Kata could self manage them.

Looking ahead Zuul is multitenant aware, and we could deploy a Kata tenant. This would give Kata a bit more freedom to configure its Zuul pipeline behavior as desired, though gating is still strongly recommended as that will prevent broken configs from merging.

> 
> (adding Salvador to CC, as he is the Kata Jenkins owner mostly, and has 
> also worked on the Zuul PoC for Kata before).
> 
>  Graham (hoping we can come to some agreement :-) )