From tdecacqu at redhat.com  Tue Jan  2 01:56:23 2018
From: tdecacqu at redhat.com (Tristan Cacqueray)
Date: Tue, 02 Jan 2018 01:56:23 +0000
Subject: [OpenStack-Infra] [zuul] third-party CI for zuul-jobs
In-Reply-To: <87wp2agpok.fsf@meyer.lemoncheese.net>
References: <1511409160.e8irdc89pj.tristanC@fedora>
 <CADr68WaoM=NKk=FvAWsfgyqx9V0+YWTDZSWE53=4tXnY9-+vtw@mail.gmail.com>
 <87wp2agpok.fsf@meyer.lemoncheese.net>
Message-ID: <1514857765.xck7n2teo1.tristanC@fedora>

On November 28, 2017 7:37 pm, James E. Blair wrote:
> Jens Harbott <j.harbott at x-ion.de> writes:
> 
>> 2017-11-23 5:28 GMT+00:00 Tristan Cacqueray <tdecacqu at redhat.com>:
>> ...
>>> TL;DR; Is it alright if we re-enable this CI and report those tests on
>>>       zuul-jobs patchsets?
>>
>> I like the general idea, but please wait for more feedback until doing so.
> 
> I am in favor of the idea in general, thanks!
> 
>> Also, IMHO it would be better if you could change the "recheck-sf"
>> trigger to something that does not also rerun upstream checks. What
>> seems to work well for other projects is "run ci-name", where ci-name
>> is the name of the Gerrit account.
> 
> Actually, I'd prefer that we do the opposite.  I'd like the recheck
> command for both to just be "recheck".  There's no harm in both systems
> re-running tests for a change in this case, and it keeps things simpler
> for developers.  The requirements in
> https://docs.openstack.org/infra/system-config/third_party.html#requirements
> state that all systems should honor "recheck".  I'd like to go beyond
> that in zuul-jobs and say that third-party ci systems on that repo
> should *only* honor "recheck".
> 
> In the meeting today we agreed that we should start by reporting without
> voting, gain some confidence, then enable +1/-1 voting.
> 

Now that zuul-jobs correctly run on CentOS I enabled the patchset-created
and recheck comment event filters.

Thanks,
-Tristan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180102/26a383d9/attachment.sig>

From corvus at inaugust.com  Sat Jan  6 18:03:15 2018
From: corvus at inaugust.com (James E. Blair)
Date: Sat, 06 Jan 2018 10:03:15 -0800
Subject: [OpenStack-Infra] Hostnames
Message-ID: <878tdaeufw.fsf@meyer.lemoncheese.net>

Hi,

It seems that every time we boot a new server, it either randomly has a
hostname of foo, or foo.openstack.org.  And maybe that changes between
the first boot and second.

The result of this is that our services which require that they know
their hostname (which is a lot, especially the complicated ones) end up
randomly working or not.  We waste time repeating the same diagnosis and
manual fix each time.

What is the cause of this, and how do we fix this correctly?

-Jim


From cboylan at sapwetik.org  Sat Jan  6 18:21:12 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Sat, 06 Jan 2018 10:21:12 -0800
Subject: [OpenStack-Infra] Hostnames
In-Reply-To: <878tdaeufw.fsf@meyer.lemoncheese.net>
References: <878tdaeufw.fsf@meyer.lemoncheese.net>
Message-ID: <1515262872.3522059.1226417768.539404D1@webmail.messagingengine.com>

On Sat, Jan 6, 2018, at 10:03 AM, James E. Blair wrote:
> Hi,
> 
> It seems that every time we boot a new server, it either randomly has a
> hostname of foo, or foo.openstack.org.  And maybe that changes between
> the first boot and second.
> 
> The result of this is that our services which require that they know
> their hostname (which is a lot, especially the complicated ones) end up
> randomly working or not.  We waste time repeating the same diagnosis and
> manual fix each time.
> 
> What is the cause of this, and how do we fix this correctly?

It seems to be an intentional behavior [0] of part of the launch node build process [1]. We could remove the split entirely there and in the hosts and mailnametemplate to use fqdns as hostname to fix it.

[0] https://git.openstack.org/cgit/openstack-infra/system-config/tree/playbooks/roles/set_hostname/tasks/main.yml#n12
[1] https://git.openstack.org/cgit/openstack-infra/system-config/tree/launch/launch-node.py#n209

Clark


From pabelanger at redhat.com  Sat Jan  6 19:16:35 2018
From: pabelanger at redhat.com (Paul Belanger)
Date: Sat, 6 Jan 2018 14:16:35 -0500
Subject: [OpenStack-Infra] Hostnames
In-Reply-To: <1515262872.3522059.1226417768.539404D1@webmail.messagingengine.com>
References: <878tdaeufw.fsf@meyer.lemoncheese.net>
 <1515262872.3522059.1226417768.539404D1@webmail.messagingengine.com>
Message-ID: <20180106191635.GA704@localhost.localdomain>

On Sat, Jan 06, 2018 at 10:21:12AM -0800, Clark Boylan wrote:
> On Sat, Jan 6, 2018, at 10:03 AM, James E. Blair wrote:
> > Hi,
> > 
> > It seems that every time we boot a new server, it either randomly has a
> > hostname of foo, or foo.openstack.org.  And maybe that changes between
> > the first boot and second.
> > 
> > The result of this is that our services which require that they know
> > their hostname (which is a lot, especially the complicated ones) end up
> > randomly working or not.  We waste time repeating the same diagnosis and
> > manual fix each time.
> > 
> > What is the cause of this, and how do we fix this correctly?
> 
> It seems to be an intentional behavior [0] of part of the launch node build process [1]. We could remove the split entirely there and in the hosts and mailnametemplate to use fqdns as hostname to fix it.
> 
> [0] https://git.openstack.org/cgit/openstack-infra/system-config/tree/playbooks/roles/set_hostname/tasks/main.yml#n12
> [1] https://git.openstack.org/cgit/openstack-infra/system-config/tree/launch/launch-node.py#n209
> 
> Clark
> 
We also talked about removing cloud-init, which has been known to modify our
hostnames on reboot.  When I last looked (few months ago) that was the reason
for renames, unsure this time.

I know we also taked about building out own DIBs for control plane servers,
which would move us to glean by default. In the past we discussed using nodepool
to build the images, but didn't want to add passwords for rax into nodepool.o.o.
That would mean a 2nd instance of nodepool, do people think that would work? Or
maybe some sort of periodic job and store credentials in zuul secrets?

PB


From dms at redhat.com  Sun Jan  7 22:30:04 2018
From: dms at redhat.com (David Moreau Simard)
Date: Sun, 7 Jan 2018 17:30:04 -0500
Subject: [OpenStack-Infra] Hostnames
In-Reply-To: <878tdaeufw.fsf@meyer.lemoncheese.net>
References: <878tdaeufw.fsf@meyer.lemoncheese.net>
Message-ID: <CAH7C+PqV3ebPnS7HbnkWoSNrPVuvEn1B2Z4yY9YFr5A=B9+cDg@mail.gmail.com>

When I compared ze10 with ze09 today, I noticed that ze09's "hostname"
command returned "ze09" while ze10 had "ze10.openstack.org".

However, both nodes had the full fqdn when doing "hostname -f".

I didn't dig deeper since we're the weekend and all that but there might be
a clue in my experience above.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

On Jan 6, 2018 1:04 PM, "James E. Blair" <corvus at inaugust.com> wrote:

> Hi,
>
> It seems that every time we boot a new server, it either randomly has a
> hostname of foo, or foo.openstack.org.  And maybe that changes between
> the first boot and second.
>
> The result of this is that our services which require that they know
> their hostname (which is a lot, especially the complicated ones) end up
> randomly working or not.  We waste time repeating the same diagnosis and
> manual fix each time.
>
> What is the cause of this, and how do we fix this correctly?
>
> -Jim
>
> _______________________________________________
> 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/20180107/e9898436/attachment.html>

From cboylan at sapwetik.org  Mon Jan  8 16:05:44 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Mon, 08 Jan 2018 08:05:44 -0800
Subject: [OpenStack-Infra] Hostnames
In-Reply-To: <CAH7C+PqV3ebPnS7HbnkWoSNrPVuvEn1B2Z4yY9YFr5A=B9+cDg@mail.gmail.com>
References: <878tdaeufw.fsf@meyer.lemoncheese.net>
 <CAH7C+PqV3ebPnS7HbnkWoSNrPVuvEn1B2Z4yY9YFr5A=B9+cDg@mail.gmail.com>
Message-ID: <1515427544.2329691.1228077552.26FF608D@webmail.messagingengine.com>

On Sun, Jan 7, 2018, at 2:30 PM, David Moreau Simard wrote:
> When I compared ze10 with ze09 today, I noticed that ze09's "hostname"
> command returned "ze09" while ze10 had "ze10.openstack.org".
> 
> However, both nodes had the full fqdn when doing "hostname -f".
> 
> I didn't dig deeper since we're the weekend and all that but there might be
> a clue in my experience above.

I think the reason for this is that ze09 was rebuilt so the launch node scripts modified it setting hostname to only ze09 and not ze09.openstack.org. ze10 on the other hand was simply rebooted so its old hostname, ze10.openstack.org, stuck.

Clark


From fungi at yuggoth.org  Mon Jan  8 18:13:29 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 8 Jan 2018 18:13:29 +0000
Subject: [OpenStack-Infra] Hostnames
In-Reply-To: <20180106191635.GA704@localhost.localdomain>
References: <878tdaeufw.fsf@meyer.lemoncheese.net>
 <1515262872.3522059.1226417768.539404D1@webmail.messagingengine.com>
 <20180106191635.GA704@localhost.localdomain>
Message-ID: <20180108181328.zeuyaxj3nue6ibem@yuggoth.org>

On 2018-01-06 14:16:35 -0500 (-0500), Paul Belanger wrote:
[...]
> I know we also taked about building out own DIBs for control plane
> servers, which would move us to glean by default. In the past we
> discussed using nodepool to build the images, but didn't want to
> add passwords for rax into nodepool.o.o. That would mean a 2nd
> instance of nodepool, do people think that would work? Or maybe
> some sort of periodic job and store credentials in zuul secrets?

In the past we've considered the fact that none of our automation
has access to our control plane provider account credentials to be a
feature. There is a bit of additional risk, for example with giving
Zuul jobs access to those, where a failure in security design for
job secret handling could allow a malicious party to take control of
Zuul itself (and far more for that matter).
-- 
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/20180108/a15c18ef/attachment-0001.sig>

From corvus at inaugust.com  Mon Jan  8 23:46:34 2018
From: corvus at inaugust.com (James E. Blair)
Date: Mon, 08 Jan 2018 15:46:34 -0800
Subject: [OpenStack-Infra] Zuul mailing lists
Message-ID: <87zi5nc3s5.fsf@meyer.lemoncheese.net>

Hi,

We recently completed the work needed to host mailing lists for projects
at their own domains.  With our expanded focus in Zuul v3 on users
beyond those related to the OpenStack project, now seems like a good
time to create dedicated Zuul mailing lists.

I'd like to create the following two lists to start:

zuul-announce at lists.zuul-ci.org  --  A list for release announcements
and to disseminate information about job definition changes (including
information about the shared zuul-jobs repos).

zuul-discuss at lists.zuul-ci.org  --  A list for general discussion about
using Zuul and development work.

Note in particular that, at the moment, I'm not proposing a dev/user
mailing list split.  Much of our dev work directly impacts users and
needs broad discussion.  Likewise, we're better developers when we dive
into real user problems.  So to the extent possible, I'd like to avoid
creating a split where one isn't necessary.

Of course, if that doesn't work out, or if circumstances change, we can
add new lists as necessary.  It seems like the most conservative
approach is to create only one discussion list and add more if needed.

It's also worth noting that some of us wear multiple hats related to
OpenStack and Zuul.  It will still be reasonable for folks to have
Zuul-related discussions on this list, or openstack-dev, when they
relate entirely to OpenStack's use of Zuul.  We might discuss adding new
executors on openstack-infra, and we might promulgate a new role for
working with devstack logs on openstack-dev.  Neither of those
discussions need to happen on the new lists.  However, like any project
used heavily by another, people involved in OpenStack with a significant
interest in Zuul should subscribe to the new lists, so they can interact
with the rest of the Zuul community.

How does that sound?

Thanks,

Jim


From cboylan at sapwetik.org  Tue Jan  9 00:53:30 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Mon, 08 Jan 2018 16:53:30 -0800
Subject: [OpenStack-Infra] Zuul mailing lists
In-Reply-To: <87zi5nc3s5.fsf@meyer.lemoncheese.net>
References: <87zi5nc3s5.fsf@meyer.lemoncheese.net>
Message-ID: <1515459210.2464326.1228683048.6AFC8EE8@webmail.messagingengine.com>



On Mon, Jan 8, 2018, at 3:46 PM, James E. Blair wrote:
> Hi,
> 
> We recently completed the work needed to host mailing lists for projects
> at their own domains.  With our expanded focus in Zuul v3 on users
> beyond those related to the OpenStack project, now seems like a good
> time to create dedicated Zuul mailing lists.
> 
> I'd like to create the following two lists to start:
> 
> zuul-announce at lists.zuul-ci.org  --  A list for release announcements
> and to disseminate information about job definition changes (including
> information about the shared zuul-jobs repos).
> 
> zuul-discuss at lists.zuul-ci.org  --  A list for general discussion about
> using Zuul and development work.
> 
> Note in particular that, at the moment, I'm not proposing a dev/user
> mailing list split.  Much of our dev work directly impacts users and
> needs broad discussion.  Likewise, we're better developers when we dive
> into real user problems.  So to the extent possible, I'd like to avoid
> creating a split where one isn't necessary.

+1. I think one of the things OpenStack has struggled with is we've set up separate lines of communication for devs, users, and ops so it is easier to miss conversations that should involve these various groups. And even when we accommodate that it ends up as a mess of cross posts.

> 
> Of course, if that doesn't work out, or if circumstances change, we can
> add new lists as necessary.  It seems like the most conservative
> approach is to create only one discussion list and add more if needed.
> 
> It's also worth noting that some of us wear multiple hats related to
> OpenStack and Zuul.  It will still be reasonable for folks to have
> Zuul-related discussions on this list, or openstack-dev, when they
> relate entirely to OpenStack's use of Zuul.  We might discuss adding new
> executors on openstack-infra, and we might promulgate a new role for
> working with devstack logs on openstack-dev.  Neither of those
> discussions need to happen on the new lists.  However, like any project
> used heavily by another, people involved in OpenStack with a significant
> interest in Zuul should subscribe to the new lists, so they can interact
> with the rest of the Zuul community.
> 
> How does that sound?

Sounds good to me.

Clark


From cboylan at sapwetik.org  Tue Jan  9 01:15:21 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Mon, 08 Jan 2018 17:15:21 -0800
Subject: [OpenStack-Infra] [Storyboard] Nominating Kendall Nelson as
	Storyboard Core
Message-ID: <1515460521.2467799.1228687840.0BCB11A0@webmail.messagingengine.com>

Hello Storyboarders,

Kendall has been walking projects through the storyboard migration process so is quite familiar with the tool as a user. Additionally it has been observed that Kendall has been doing reviews on storyboard changes and that these are helpful. Kendall has also been shepherding changes through CI (rechecking when necessary and otherwise staying on top of changes' status).

In an effort to further encourage helping out storyboard I propose we add Kendall to the storyboard core group.

Let me know what you think and thank you to Kendall for all the help so far.

Clark


From corvus at inaugust.com  Tue Jan  9 01:42:58 2018
From: corvus at inaugust.com (James E. Blair)
Date: Mon, 08 Jan 2018 17:42:58 -0800
Subject: [OpenStack-Infra] Hostnames
In-Reply-To: <1515427544.2329691.1228077552.26FF608D@webmail.messagingengine.com>
 (Clark Boylan's message of "Mon, 08 Jan 2018 08:05:44 -0800")
References: <878tdaeufw.fsf@meyer.lemoncheese.net>
 <CAH7C+PqV3ebPnS7HbnkWoSNrPVuvEn1B2Z4yY9YFr5A=B9+cDg@mail.gmail.com>
 <1515427544.2329691.1228077552.26FF608D@webmail.messagingengine.com>
Message-ID: <87bmi3bye5.fsf@meyer.lemoncheese.net>

Clark Boylan <cboylan at sapwetik.org> writes:

> On Sun, Jan 7, 2018, at 2:30 PM, David Moreau Simard wrote:
>> When I compared ze10 with ze09 today, I noticed that ze09's "hostname"
>> command returned "ze09" while ze10 had "ze10.openstack.org".
>> 
>> However, both nodes had the full fqdn when doing "hostname -f".
>> 
>> I didn't dig deeper since we're the weekend and all that but there might be
>> a clue in my experience above.
>
> I think the reason for this is that ze09 was rebuilt so the launch
> node scripts modified it setting hostname to only ze09 and not
> ze09.openstack.org. ze10 on the other hand was simply rebooted so its
> old hostname, ze10.openstack.org, stuck.

Distilling this conversation and that in IRC today:

The current software should produce consistent results:
  hostname -> ze09
  hostname --fqdn -> ze09.openstack.org

This is what we want on all machines.

Machines launched before October 2017 were subject to a race with
cloud-init which has since been corrected.  Those may have the FQDN for
the hostname.  That explains the discrepancy observed.

The next time we stop all of Zuul, should we rename all the hosts and
then update the grafana dashboards?

-Jim


From joshua.hesketh at gmail.com  Tue Jan  9 01:55:33 2018
From: joshua.hesketh at gmail.com (Joshua Hesketh)
Date: Tue, 9 Jan 2018 12:55:33 +1100
Subject: [OpenStack-Infra] Zuul mailing lists
In-Reply-To: <87zi5nc3s5.fsf@meyer.lemoncheese.net>
References: <87zi5nc3s5.fsf@meyer.lemoncheese.net>
Message-ID: <CA+DTi5zz91jYWJdMpvCf=87_KYDh_AMYEhB=kcGvp7A7Xrh4kA@mail.gmail.com>

On Tue, Jan 9, 2018 at 10:46 AM, James E. Blair <corvus at inaugust.com> wrote:

> Hi,
>
> We recently completed the work needed to host mailing lists for projects
> at their own domains.  With our expanded focus in Zuul v3 on users
> beyond those related to the OpenStack project, now seems like a good
> time to create dedicated Zuul mailing lists.
>
> I'd like to create the following two lists to start:
>
> zuul-announce at lists.zuul-ci.org  --  A list for release announcements
> and to disseminate information about job definition changes (including
> information about the shared zuul-jobs repos).
>
> zuul-discuss at lists.zuul-ci.org  --  A list for general discussion about
> using Zuul and development work.
>
> Note in particular that, at the moment, I'm not proposing a dev/user
> mailing list split.  Much of our dev work directly impacts users and
> needs broad discussion.  Likewise, we're better developers when we dive
> into real user problems.  So to the extent possible, I'd like to avoid
> creating a split where one isn't necessary.
>
> Of course, if that doesn't work out, or if circumstances change, we can
> add new lists as necessary.  It seems like the most conservative
> approach is to create only one discussion list and add more if needed.
>
> It's also worth noting that some of us wear multiple hats related to
> OpenStack and Zuul.  It will still be reasonable for folks to have
> Zuul-related discussions on this list, or openstack-dev, when they
> relate entirely to OpenStack's use of Zuul.  We might discuss adding new
> executors on openstack-infra, and we might promulgate a new role for
> working with devstack logs on openstack-dev.  Neither of those
> discussions need to happen on the new lists.  However, like any project
> used heavily by another, people involved in OpenStack with a significant
> interest in Zuul should subscribe to the new lists, so they can interact
> with the rest of the Zuul community.
>
> How does that sound?
>

Sounds good :-)


>
> Thanks,
>
> Jim
>
> _______________________________________________
> 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/20180109/192b8373/attachment.html>

From fungi at yuggoth.org  Tue Jan  9 13:47:16 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 9 Jan 2018 13:47:16 +0000
Subject: [OpenStack-Infra] Zuul mailing lists
In-Reply-To: <1515459210.2464326.1228683048.6AFC8EE8@webmail.messagingengine.com>
References: <87zi5nc3s5.fsf@meyer.lemoncheese.net>
 <1515459210.2464326.1228683048.6AFC8EE8@webmail.messagingengine.com>
Message-ID: <20180109134716.tmizbftugim3uew5@yuggoth.org>

On 2018-01-08 16:53:30 -0800 (-0800), Clark Boylan wrote:
> On Mon, Jan 8, 2018, at 3:46 PM, James E. Blair wrote:
[...]
> > I'd like to create the following two lists to start:
> > 
> > zuul-announce at lists.zuul-ci.org  --  A list for release
> > announcements and to disseminate information about job
> > definition changes (including information about the shared
> > zuul-jobs repos).
> > 
> > zuul-discuss at lists.zuul-ci.org  --  A list for general
> > discussion about using Zuul and development work.
> > 
> > Note in particular that, at the moment, I'm not proposing a
> > dev/user mailing list split.  Much of our dev work directly
> > impacts users and needs broad discussion.  Likewise, we're
> > better developers when we dive into real user problems.  So to
> > the extent possible, I'd like to avoid creating a split where
> > one isn't necessary.
> 
> +1. I think one of the things OpenStack has struggled with is
> we've set up separate lines of communication for devs, users, and
> ops so it is easier to miss conversations that should involve
> these various groups. And even when we accommodate that it ends up
> as a mess of cross posts.
[...]

I'd go further and credit it with much of the unnecessary perceived
division between developers and operators in the OpenStack
community. The proposal sounds great.
-- 
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/20180109/6c71f43e/attachment.sig>

From jimmy at tipit.net  Tue Jan  9 13:53:02 2018
From: jimmy at tipit.net (Jimmy Mcarthur)
Date: Tue, 09 Jan 2018 07:53:02 -0600
Subject: [OpenStack-Infra] Zuul mailing lists
In-Reply-To: <20180109134716.tmizbftugim3uew5@yuggoth.org>
References: <87zi5nc3s5.fsf@meyer.lemoncheese.net>
 <1515459210.2464326.1228683048.6AFC8EE8@webmail.messagingengine.com>
 <20180109134716.tmizbftugim3uew5@yuggoth.org>
Message-ID: <5A54C93E.70704@tipit.net>



Jeremy Stanley wrote:
> I'd go further and credit it with much of the unnecessary perceived
> division between developers and operators in the OpenStack
> community. The proposal sounds great.
> -- Jeremy Stanley
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180109/f778d70b/attachment-0001.html>

From fungi at yuggoth.org  Tue Jan  9 13:51:09 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 9 Jan 2018 13:51:09 +0000
Subject: [OpenStack-Infra] [Storyboard] Nominating Kendall Nelson as
 Storyboard Core
In-Reply-To: <1515460521.2467799.1228687840.0BCB11A0@webmail.messagingengine.com>
References: <1515460521.2467799.1228687840.0BCB11A0@webmail.messagingengine.com>
Message-ID: <20180109135109.7u7rkugkr2z6lxdg@yuggoth.org>

On 2018-01-08 17:15:21 -0800 (-0800), Clark Boylan wrote:
> Kendall has been walking projects through the storyboard migration
> process so is quite familiar with the tool as a user. Additionally
> it has been observed that Kendall has been doing reviews on
> storyboard changes and that these are helpful. Kendall has also
> been shepherding changes through CI (rechecking when necessary and
> otherwise staying on top of changes' status).
> 
> In an effort to further encourage helping out storyboard I propose
> we add Kendall to the storyboard core group.
> 
> Let me know what you think and thank you to Kendall for all the
> help so far.

Growing the storyboard-core group sounds marvellous, and I'm glad to
see it attracting more contributors. Thanks Kendall, and a huge
thanks to the rest of the SB team for all the progress they've made
with such a small group!
-- 
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/20180109/4aaee401/attachment.sig>

From gema.gomez-solano at linaro.org  Wed Jan 10 09:41:57 2018
From: gema.gomez-solano at linaro.org (Gema Gomez)
Date: Wed, 10 Jan 2018 09:41:57 +0000
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
Message-ID: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>

Hi all,

Linaro would like to add a new cloud to infra so that we can run tests
on ARM64 going forward. This discussion has been ongoing for the good
part of a year, apologies that it took us so long to get to a point
where we feel comfortable going ahead in terms of stability of
infrastructure and functionality.

My team has been taking care of making OpenStack as multiarch as
possible and making the experience of using an ARM64 cloud as close to
using a traditional amd64 one as possible. We have the Linaro Developer
Cloud program, which consists of a set of clouds that run on ARM64
hardware donated by the Linaro Enterprise Group members[1] and dedicated
to enablement/testing of upstream projects. Until recently our clouds
were run by an engineering team and were used to do enablement of
different projects and bug fixes of OpenStack, now we have a dedicated
admin and we are ready to take it a step forward. The clouds are
currently running OpenStack Newton but we are going to be moving to
Queens as soon as the release is out. Kolla has volunteered to be the
first project for this experiment, they have been pushing us to start
doing CI on our images so they also feel more comfortable accepting our
changes. We will welcome any other project that wants to be part of this
experiment, but we'll focus our engineering efforts initially on
enabling Kolla CI.

After some preliminary discussion with fungi and inc0, we are going to
start small and grow from there. The initial plan is to add 2 projects:

1. Control-plane project that will host a nodepool builder with 8 vCPUs,
8 GB RAM, 1TB storage on a Cinder volume for the image building scratch
space. A cache server with similar specs + 200GB on a cinder volume for
AFS and Apache proxy caches. They will have a routable IP address.

2. Jobs project, we'll have capacity for 6 test instances initially and
after initial assessment grow it as required (8 vCPUs/8 GB RAM, 80GB
storage, 1 routable IP each).

Is there anything else we are missing for the initial trial? Any
questions/concerns before we start? I will try to have presence on the
infra weekly calls/IRC channel or have someone from my team on them
going forward.

In practical terms, once we've created the resources, is there a guide
to getting the infra bits in place for it? Who to give the credentials
to/etc?

Thanks!
Gema

[1] https://www.linaro.org/groups/leg/
-- 
Gema Gomez-Solano
Tech Lead, SDI
Linaro Ltd
IRC: gema@#linaro on irc.freenode.net


From adam.coldrick at codethink.co.uk  Wed Jan 10 10:40:15 2018
From: adam.coldrick at codethink.co.uk (Adam Coldrick)
Date: Wed, 10 Jan 2018 10:40:15 +0000
Subject: [OpenStack-Infra] [Storyboard] Nominating Kendall Nelson as
 Storyboard Core
In-Reply-To: <1515460521.2467799.1228687840.0BCB11A0@webmail.messagingengine.com>
References: <1515460521.2467799.1228687840.0BCB11A0@webmail.messagingengine.com>
Message-ID: <1515580815.5039.1.camel@codethink.co.uk>

On Mon, 2018-01-08 at 17:15 -0800, Clark Boylan wrote:
> Kendall has been walking projects through the storyboard migration
> process so is quite familiar with the tool as a user. Additionally it
> has been observed that Kendall has been doing reviews on storyboard
> changes and that these are helpful. Kendall has also been shepherding
> changes through CI (rechecking when necessary and otherwise staying
> on top of changes' status).
> 
> In an effort to further encourage helping out storyboard I propose we
> add Kendall to the storyboard core group.
> 
> Let me know what you think and thank you to Kendall for all the help
> so far.

I think this is a great idea, Kendall will be a good addition to the
team. Also, +1 to the thanks for all her work so far!

Adam


From ianyrchoi at gmail.com  Wed Jan 10 16:08:44 2018
From: ianyrchoi at gmail.com (Ian Y. Choi)
Date: Thu, 11 Jan 2018 01:08:44 +0900
Subject: [OpenStack-Infra] Asking for comments on translate-dev.o.o auth
	table mismatch
In-Reply-To: <CAAZU4v0+JfW4cGPGyC7MTG2TgRcMNJuS6uonyLFZ_+RjtJcreA@mail.gmail.com>
References: <a5b15b07-01c0-4f3a-fef3-73cc0d6ec893@gmail.com>
 <CAAZU4v0+JfW4cGPGyC7MTG2TgRcMNJuS6uonyLFZ_+RjtJcreA@mail.gmail.com>
Message-ID: <efa278c3-181a-48fc-a97e-28374673b078@gmail.com>

Hello,

I would like to update this (sorry for my late sharing on this mailing 
list and infra team):

- Jimmy commented on the Etherpad on Dec 13.

According to his comment, it would be nice if Zanata manages openid full 
url by separating
into domain part (e.g., "openstackid.org") and rest part (e.g., "/..."). 
@Patrick, would it be possible to support in Zanata
as a new feature?

By the way, I18n team decided to have another approach: freshing 
database used in translate-dev.openstack.org,
which would address current openstackid issues and I18n PTL proposed 
https://review.openstack.org/#/c/531736/ .
It would be so nice if the patch gets more attention from system-config 
cores.


With many thanks,

/Ian

Patrick Huang wrote on 12/6/2017 11:03 AM:
> I've put my comments in the etherpad.
>
> On Wed, Dec 6, 2017 at 11:19 AM, Ian Y. Choi <ianyrchoi at gmail.com 
> <mailto:ianyrchoi at gmail.com>> wrote:
>
>     Hello,
>
>     Since Zanata upgrade to 4.3.1 on translate-dev.openstack.org
>     <http://translate-dev.openstack.org> is going well [1],
>     I think it is a good time to discuss translate-dev.o.o
>     authentication problems.
>
>     I wrote a brief current problem on authentication issues in
>     translate-dev.o.o and my suggestion on proposed solution
>     :
>     https://etherpad.openstack.org/p/translate-dev-openstackid-issues
>     <https://etherpad.openstack.org/p/translate-dev-openstackid-issues> .
>
>     Clark looked at this proposal and said that it looked good previously.
>     It would be so nice if infra team, openstackid developers, I18n
>     PTL, and Zanata development team
>     would be in same pages.
>
>     In my opinion we can discuss more on for example:
>     - openstackid developers: How the sync between openstackid-dev and
>     openstackid databases is accomplished
>       (regarding password mismatch)
>     - Sharing Zanata auth table structure from Zanata development team
>     would be nice.
>
>
>     With many thanks,
>
>     /Ian
>
>     [1] https://storyboard.openstack.org/#!/story/2001362
>     <https://storyboard.openstack.org/#%21/story/2001362>
>
>
>
>
> -- 
> Patrick Huang
> Senior Software Engineer
> Engineering - Internationalisation
> Red Hat, Asia-Pacific Pty Ltd
> Level 1, 193 North Quay
> Brisbane 4000
> Office: +61 7 3514 8278
> Fax: +61 7 3514 8199
> IRC: pahuang
> github: github.com/huangp <http://github.com/huangp>
> Website: www.redhat.com <http://www.redhat.com>




From inc007 at gmail.com  Wed Jan 10 17:06:43 2018
From: inc007 at gmail.com (=?UTF-8?B?TWljaGHFgiBKYXN0cnrEmWJza2k=?=)
Date: Wed, 10 Jan 2018 09:06:43 -0800
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
Message-ID: <CALc0zUA9J7mwvB0jZkWi0umdGC=Uufq-hdMxJWdbJtFZ_DoKJg@mail.gmail.com>

Thanks Gema!

So it's my understanding (which is limited at best) that zuul
currently doesn't support something like "this job has to run on
nodepool X", which would be necessary. We might need to add some sort
of metadata for nodepools and be able to specify in zuul job that
"this job has to land on node with metadata X", like architecture:
arm64.

On 10 January 2018 at 01:41, Gema Gomez <gema.gomez-solano at linaro.org> wrote:
> Hi all,
>
> Linaro would like to add a new cloud to infra so that we can run tests
> on ARM64 going forward. This discussion has been ongoing for the good
> part of a year, apologies that it took us so long to get to a point
> where we feel comfortable going ahead in terms of stability of
> infrastructure and functionality.
>
> My team has been taking care of making OpenStack as multiarch as
> possible and making the experience of using an ARM64 cloud as close to
> using a traditional amd64 one as possible. We have the Linaro Developer
> Cloud program, which consists of a set of clouds that run on ARM64
> hardware donated by the Linaro Enterprise Group members[1] and dedicated
> to enablement/testing of upstream projects. Until recently our clouds
> were run by an engineering team and were used to do enablement of
> different projects and bug fixes of OpenStack, now we have a dedicated
> admin and we are ready to take it a step forward. The clouds are
> currently running OpenStack Newton but we are going to be moving to
> Queens as soon as the release is out. Kolla has volunteered to be the
> first project for this experiment, they have been pushing us to start
> doing CI on our images so they also feel more comfortable accepting our
> changes. We will welcome any other project that wants to be part of this
> experiment, but we'll focus our engineering efforts initially on
> enabling Kolla CI.
>
> After some preliminary discussion with fungi and inc0, we are going to
> start small and grow from there. The initial plan is to add 2 projects:
>
> 1. Control-plane project that will host a nodepool builder with 8 vCPUs,
> 8 GB RAM, 1TB storage on a Cinder volume for the image building scratch
> space. A cache server with similar specs + 200GB on a cinder volume for
> AFS and Apache proxy caches. They will have a routable IP address.
>
> 2. Jobs project, we'll have capacity for 6 test instances initially and
> after initial assessment grow it as required (8 vCPUs/8 GB RAM, 80GB
> storage, 1 routable IP each).
>
> Is there anything else we are missing for the initial trial? Any
> questions/concerns before we start? I will try to have presence on the
> infra weekly calls/IRC channel or have someone from my team on them
> going forward.
>
> In practical terms, once we've created the resources, is there a guide
> to getting the infra bits in place for it? Who to give the credentials
> to/etc?
>
> Thanks!
> Gema
>
> [1] https://www.linaro.org/groups/leg/
> --
> Gema Gomez-Solano
> Tech Lead, SDI
> Linaro Ltd
> IRC: gema@#linaro on irc.freenode.net
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


From fungi at yuggoth.org  Wed Jan 10 17:28:17 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 10 Jan 2018 17:28:17 +0000
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <CALc0zUA9J7mwvB0jZkWi0umdGC=Uufq-hdMxJWdbJtFZ_DoKJg@mail.gmail.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <CALc0zUA9J7mwvB0jZkWi0umdGC=Uufq-hdMxJWdbJtFZ_DoKJg@mail.gmail.com>
Message-ID: <20180110172817.pw63p56imkleaofv@yuggoth.org>

On 2018-01-10 09:06:43 -0800 (-0800), Michał Jastrzębski wrote:
> So it's my understanding (which is limited at best) that zuul
> currently doesn't support something like "this job has to run on
> nodepool X", which would be necessary. We might need to add some sort
> of metadata for nodepools and be able to specify in zuul job that
> "this job has to land on node with metadata X", like architecture:
> arm64.

This shouldn't be an issue since our node types are tightly coupled
to the images they boot, and the arm64 architecture images will I'm
sure get distinct names (as an offshoot of this though, we may end
up extending the names of our current amd64 images to embed
processor architecture names for consistency, but this is one of the
many points we'll need to debate).
-- 
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/20180110/bb8982dc/attachment.sig>

From marcin.juszkiewicz at linaro.org  Wed Jan 10 18:34:07 2018
From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz)
Date: Wed, 10 Jan 2018 19:34:07 +0100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <20180110172817.pw63p56imkleaofv@yuggoth.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <CALc0zUA9J7mwvB0jZkWi0umdGC=Uufq-hdMxJWdbJtFZ_DoKJg@mail.gmail.com>
 <20180110172817.pw63p56imkleaofv@yuggoth.org>
Message-ID: <423ae93e-040b-f616-5258-140a9397d280@linaro.org>

W dniu 10.01.2018 o 18:28, Jeremy Stanley pisze:
> On 2018-01-10 09:06:43 -0800 (-0800), Michał Jastrzębski wrote:
>> So it's my understanding (which is limited at best) that zuul
>> currently doesn't support something like "this job has to run on
>> nodepool X", which would be necessary. We might need to add some sort
>> of metadata for nodepools and be able to specify in zuul job that
>> "this job has to land on node with metadata X", like architecture:
>> arm64.

> This shouldn't be an issue since our node types are tightly coupled
> to the images they boot, and the arm64 architecture images will I'm
> sure get distinct names (as an offshoot of this though, we may end
> up extending the names of our current amd64 images to embed
> processor architecture names for consistency, but this is one of the
> many points we'll need to debate).

Docker images can be multiarch so same names are used on different
architectures.


From fungi at yuggoth.org  Wed Jan 10 18:48:54 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 10 Jan 2018 18:48:54 +0000
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <423ae93e-040b-f616-5258-140a9397d280@linaro.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <CALc0zUA9J7mwvB0jZkWi0umdGC=Uufq-hdMxJWdbJtFZ_DoKJg@mail.gmail.com>
 <20180110172817.pw63p56imkleaofv@yuggoth.org>
 <423ae93e-040b-f616-5258-140a9397d280@linaro.org>
Message-ID: <20180110184854.6hhwnc4ynchuzvej@yuggoth.org>

On 2018-01-10 19:34:07 +0100 (+0100), Marcin Juszkiewicz wrote:
> W dniu 10.01.2018 o 18:28, Jeremy Stanley pisze:
> > On 2018-01-10 09:06:43 -0800 (-0800), Michał Jastrzębski wrote:
> >> So it's my understanding (which is limited at best) that zuul
> >> currently doesn't support something like "this job has to run on
> >> nodepool X", which would be necessary. We might need to add some sort
> >> of metadata for nodepools and be able to specify in zuul job that
> >> "this job has to land on node with metadata X", like architecture:
> >> arm64.
> 
> > This shouldn't be an issue since our node types are tightly coupled
> > to the images they boot, and the arm64 architecture images will I'm
> > sure get distinct names (as an offshoot of this though, we may end
> > up extending the names of our current amd64 images to embed
> > processor architecture names for consistency, but this is one of the
> > many points we'll need to debate).
> 
> Docker images can be multiarch so same names are used on different
> architectures.

Right, these are virtual machine images and not Docker images, but
regardless we _could_ do something similar. This would however
require some reworking of Nodepool and Zuul to become processor
architecture aware so that it could be tracked independently of node
type and image build.
-- 
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/20180110/eb88bab7/attachment.sig>

From jimmy at openstack.org  Wed Jan 10 22:16:49 2018
From: jimmy at openstack.org (Jimmy McArthur)
Date: Wed, 10 Jan 2018 16:16:49 -0600
Subject: [OpenStack-Infra] Asking for comments on translate-dev.o.o auth
	table mismatch
In-Reply-To: <CAA6Xr1SVWkkhsWbdQ=mJXTrDf1=P+7E+9KbMOHWahp5xc-R8+g@mail.gmail.com>
References: <a5b15b07-01c0-4f3a-fef3-73cc0d6ec893@gmail.com>
 <CAAZU4v0+JfW4cGPGyC7MTG2TgRcMNJuS6uonyLFZ_+RjtJcreA@mail.gmail.com>
 <efa278c3-181a-48fc-a97e-28374673b078@gmail.com>
 <CAA6Xr1SVWkkhsWbdQ=mJXTrDf1=P+7E+9KbMOHWahp5xc-R8+g@mail.gmail.com>
Message-ID: <9E59F39C-5320-4FFC-B472-8820C49AE73E@openstack.org>

Technically those affected users could just update their password on both the OpenStackID production and dev sites. Then the problem would be solved. I can’t imagine we are talking about that many people that have changed their passwords?

Thanks,
Jimmy McArthur <jimmy at openstack.org>
512.965.4846


On Jan 10, 2018, at 3:48 PM, Alex Eng <aeng at redhat.com> wrote:

>> According to his comment, it would be nice if Zanata manages openid full url by separating
>> into domain part (e.g., "openstackid.org") and rest part (e.g., "/..."). @Patrick, would it be possible to support in Zanata
>> as a new feature?
>  
> As much as I would like to solve issue asap, I don't think this is the right solution. 
> It is best to handle the URL changes through a script or the jboss-cli.
> 
>> On Thu, Jan 11, 2018 at 2:08 AM, Ian Y. Choi <ianyrchoi at gmail.com> wrote:
>> Hello,
>> 
>> I would like to update this (sorry for my late sharing on this mailing list and infra team):
>> 
>> - Jimmy commented on the Etherpad on Dec 13.
>> 
>> According to his comment, it would be nice if Zanata manages openid full url by separating
>> into domain part (e.g., "openstackid.org") and rest part (e.g., "/..."). @Patrick, would it be possible to support in Zanata
>> as a new feature?
>> 
>> By the way, I18n team decided to have another approach: freshing database used in translate-dev.openstack.org,
>> which would address current openstackid issues and I18n PTL proposed https://review.openstack.org/#/c/531736/ .
>> It would be so nice if the patch gets more attention from system-config cores.
>> 
>> 
>> With many thanks,
>> 
>> /Ian
>> 
>> Patrick Huang wrote on 12/6/2017 11:03 AM:
>>> I've put my comments in the etherpad.
>>> 
>>> On Wed, Dec 6, 2017 at 11:19 AM, Ian Y. Choi <ianyrchoi at gmail.com <mailto:ianyrchoi at gmail.com>> wrote:
>>> 
>>>     Hello,
>>> 
>>>     Since Zanata upgrade to 4.3.1 on translate-dev.openstack.org
>>>     <http://translate-dev.openstack.org> is going well [1],
>>>     I think it is a good time to discuss translate-dev.o.o
>>>     authentication problems.
>>> 
>>>     I wrote a brief current problem on authentication issues in
>>>     translate-dev.o.o and my suggestion on proposed solution
>>>     :
>>>     https://etherpad.openstack.org/p/translate-dev-openstackid-issues
>>>     <https://etherpad.openstack.org/p/translate-dev-openstackid-issues> .
>>> 
>>>     Clark looked at this proposal and said that it looked good previously.
>>>     It would be so nice if infra team, openstackid developers, I18n
>>>     PTL, and Zanata development team
>>>     would be in same pages.
>>> 
>>>     In my opinion we can discuss more on for example:
>>>     - openstackid developers: How the sync between openstackid-dev and
>>>     openstackid databases is accomplished
>>>       (regarding password mismatch)
>>>     - Sharing Zanata auth table structure from Zanata development team
>>>     would be nice.
>>> 
>>> 
>>>     With many thanks,
>>> 
>>>     /Ian
>>> 
>>>     [1] https://storyboard.openstack.org/#!/story/2001362
>>>     <https://storyboard.openstack.org/#%21/story/2001362>
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Patrick Huang
>>> Senior Software Engineer
>>> Engineering - Internationalisation
>>> Red Hat, Asia-Pacific Pty Ltd
>>> Level 1, 193 North Quay
>>> Brisbane 4000
>>> Office: +61 7 3514 8278
>>> Fax: +61 7 3514 8199
>>> IRC: pahuang
>>> github: github.com/huangp <http://github.com/huangp>
>>> Website: www.redhat.com <http://www.redhat.com>
>> 
>> 
> 
> 
> 
> -- 
> ALEX ENG
> ASSOCIATE MANAGER
> GLOBALIZATION TOOLING, CUSTOMER PLATFORM
> Red Hat Inc
> 193 North Quay, Brisbane City QLD 4000
> alex.eng at redhat.com    M: 0423353457     IM: aeng
> 
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180110/46459a0e/attachment.html>

From iwienand at redhat.com  Thu Jan 11 04:53:30 2018
From: iwienand at redhat.com (Ian Wienand)
Date: Thu, 11 Jan 2018 15:53:30 +1100
Subject: [OpenStack-Infra] ze04 & #532575
Message-ID: <ab1a5bdc-5096-242a-4b24-a12bdfbc9540@redhat.com>

Hi,

To avoid you having to pull apart the logs starting ~ [1], we
determined that ze04.o.o was externally rebooted at 01:00UTC (there is
a rather weird support ticket which you can look at, which is assigned
to a rackspace employee but in our queue, saying the host became
unresponsive).

Unfortunately that left a bunch of jobs orphaned and necessitated a
restart of zuul.

However, recent changes to not run the executor as root [2] were thus
partially rolled out on ze04 as it came up after reboot.  As a
consequence when the host came back up the executor was running as
root with an invalid finger server.

The executor on ze04 has been stopped, and the host placed in the
emergency file to avoid it coming back.  There are now some in-flight
patches to complete this transition, which will need to be staged a
bit more manually.

The other executors have been left as is, based on the KISS theory
they shouldn't restart and pick up the code until this has been dealt
with.

Thanks,

-i


[1] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-11.log.html#t2018-01-11T01:09:20
[2] https://review.openstack.org/#/c/532575/


From shrewsbury.dave at gmail.com  Thu Jan 11 12:58:11 2018
From: shrewsbury.dave at gmail.com (David Shrewsbury)
Date: Thu, 11 Jan 2018 07:58:11 -0500
Subject: [OpenStack-Infra] ze04 & #532575
In-Reply-To: <ab1a5bdc-5096-242a-4b24-a12bdfbc9540@redhat.com>
References: <ab1a5bdc-5096-242a-4b24-a12bdfbc9540@redhat.com>
Message-ID: <CAB91eg7MSVaGkuzvzE2RaVhe=L3w-Oak03FtrGBwqTVSDWcERA@mail.gmail.com>

This is probably mostly my fault since I did not WIP or -2 my change in
532575 to keep it
from getting merged without some infra coordination.

Because of that change, it is also required that we change the user
zuul-executor starts
as from root to zuul [1], and that we also open up the new default finger
port on the
executors [2]. Once those are in place, we should be ok to restart the
executors.

As for ze04, since that one restarted as the 'root' user, and never dropped
privileges
to the 'zuul' user due to 532575, I'm not sure what state it is going to be
in after applying
[1] and [2]. Would it create files/directories as root that would now be
inaccessible if it
were to restart with the zuul user? Think logs, work dirs, etc...


-Dave


[1] https://review.openstack.org/532594
[2] https://review.openstack.org/532709


On Wed, Jan 10, 2018 at 11:53 PM, Ian Wienand <iwienand at redhat.com> wrote:

> Hi,
>
> To avoid you having to pull apart the logs starting ~ [1], we
> determined that ze04.o.o was externally rebooted at 01:00UTC (there is
> a rather weird support ticket which you can look at, which is assigned
> to a rackspace employee but in our queue, saying the host became
> unresponsive).
>
> Unfortunately that left a bunch of jobs orphaned and necessitated a
> restart of zuul.
>
> However, recent changes to not run the executor as root [2] were thus
> partially rolled out on ze04 as it came up after reboot.  As a
> consequence when the host came back up the executor was running as
> root with an invalid finger server.
>
> The executor on ze04 has been stopped, and the host placed in the
> emergency file to avoid it coming back.  There are now some in-flight
> patches to complete this transition, which will need to be staged a
> bit more manually.
>
> The other executors have been left as is, based on the KISS theory
> they shouldn't restart and pick up the code until this has been dealt
> with.
>
> Thanks,
>
> -i
>
>
> [1] http://eavesdrop.openstack.org/irclogs/%23openstack-
> infra/%23openstack-infra.2018-01-11.log.html#t2018-01-11T01:09:20
> [2] https://review.openstack.org/#/c/532575/
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra




-- 
David Shrewsbury (Shrews)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180111/a47fb978/attachment-0001.html>

From pabelanger at redhat.com  Thu Jan 11 16:05:20 2018
From: pabelanger at redhat.com (Paul Belanger)
Date: Thu, 11 Jan 2018 11:05:20 -0500
Subject: [OpenStack-Infra] ze04 & #532575
In-Reply-To: <CAB91eg7MSVaGkuzvzE2RaVhe=L3w-Oak03FtrGBwqTVSDWcERA@mail.gmail.com>
References: <ab1a5bdc-5096-242a-4b24-a12bdfbc9540@redhat.com>
 <CAB91eg7MSVaGkuzvzE2RaVhe=L3w-Oak03FtrGBwqTVSDWcERA@mail.gmail.com>
Message-ID: <20180111160520.GA18166@localhost.localdomain>

On Thu, Jan 11, 2018 at 07:58:11AM -0500, David Shrewsbury wrote:
> This is probably mostly my fault since I did not WIP or -2 my change in
> 532575 to keep it
> from getting merged without some infra coordination.
> 
> Because of that change, it is also required that we change the user
> zuul-executor starts
> as from root to zuul [1], and that we also open up the new default finger
> port on the
> executors [2]. Once those are in place, we should be ok to restart the
> executors.
> 
> As for ze04, since that one restarted as the 'root' user, and never dropped
> privileges
> to the 'zuul' user due to 532575, I'm not sure what state it is going to be
> in after applying
> [1] and [2]. Would it create files/directories as root that would now be
> inaccessible if it
> were to restart with the zuul user? Think logs, work dirs, etc...
> 
For permissions, we should likely confirm that puppet-zuul will properly setup
zuul:zuul on the required folders. Then next puppet run we'd be protected.
> 
> -Dave
> 
> 
> [1] https://review.openstack.org/532594
> [2] https://review.openstack.org/532709
> 
> 
> On Wed, Jan 10, 2018 at 11:53 PM, Ian Wienand <iwienand at redhat.com> wrote:
> 
> > Hi,
> >
> > To avoid you having to pull apart the logs starting ~ [1], we
> > determined that ze04.o.o was externally rebooted at 01:00UTC (there is
> > a rather weird support ticket which you can look at, which is assigned
> > to a rackspace employee but in our queue, saying the host became
> > unresponsive).
> >
> > Unfortunately that left a bunch of jobs orphaned and necessitated a
> > restart of zuul.
> >
> > However, recent changes to not run the executor as root [2] were thus
> > partially rolled out on ze04 as it came up after reboot.  As a
> > consequence when the host came back up the executor was running as
> > root with an invalid finger server.
> >
> > The executor on ze04 has been stopped, and the host placed in the
> > emergency file to avoid it coming back.  There are now some in-flight
> > patches to complete this transition, which will need to be staged a
> > bit more manually.
> >
> > The other executors have been left as is, based on the KISS theory
> > they shouldn't restart and pick up the code until this has been dealt
> > with.
> >
> > Thanks,
> >
> > -i
> >
> >
> > [1] http://eavesdrop.openstack.org/irclogs/%23openstack-
> > infra/%23openstack-infra.2018-01-11.log.html#t2018-01-11T01:09:20
> > [2] https://review.openstack.org/#/c/532575/
> >
> > _______________________________________________
> > OpenStack-Infra mailing list
> > OpenStack-Infra at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 
> 
> 
> 
> -- 
> David Shrewsbury (Shrews)

> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



From cboylan at sapwetik.org  Thu Jan 11 23:28:27 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Thu, 11 Jan 2018 15:28:27 -0800
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
Message-ID: <1515713307.1621085.1232530640.1104FEFD@webmail.messagingengine.com>

On Wed, Jan 10, 2018, at 1:41 AM, Gema Gomez wrote:
> Hi all,
> 
> Linaro would like to add a new cloud to infra so that we can run tests
> on ARM64 going forward. This discussion has been ongoing for the good
> part of a year, apologies that it took us so long to get to a point
> where we feel comfortable going ahead in terms of stability of
> infrastructure and functionality.
> 
> My team has been taking care of making OpenStack as multiarch as
> possible and making the experience of using an ARM64 cloud as close to
> using a traditional amd64 one as possible. We have the Linaro Developer
> Cloud program, which consists of a set of clouds that run on ARM64
> hardware donated by the Linaro Enterprise Group members[1] and dedicated
> to enablement/testing of upstream projects. Until recently our clouds
> were run by an engineering team and were used to do enablement of
> different projects and bug fixes of OpenStack, now we have a dedicated
> admin and we are ready to take it a step forward. The clouds are
> currently running OpenStack Newton but we are going to be moving to
> Queens as soon as the release is out. Kolla has volunteered to be the
> first project for this experiment, they have been pushing us to start
> doing CI on our images so they also feel more comfortable accepting our
> changes. We will welcome any other project that wants to be part of this
> experiment, but we'll focus our engineering efforts initially on
> enabling Kolla CI.
> 
> After some preliminary discussion with fungi and inc0, we are going to
> start small and grow from there. The initial plan is to add 2 projects:
> 
> 1. Control-plane project that will host a nodepool builder with 8 vCPUs,
> 8 GB RAM, 1TB storage on a Cinder volume for the image building scratch
> space. A cache server with similar specs + 200GB on a cinder volume for
> AFS and Apache proxy caches. They will have a routable IP address.
> 
> 2. Jobs project, we'll have capacity for 6 test instances initially and
> after initial assessment grow it as required (8 vCPUs/8 GB RAM, 80GB
> storage, 1 routable IP each).
> 
> Is there anything else we are missing for the initial trial? Any
> questions/concerns before we start? I will try to have presence on the
> infra weekly calls/IRC channel or have someone from my team on them
> going forward.

This plan looks good to me. The one question I had on IRC (and putting it here for historical reasons) is whether or not Andrew FileSystem (AFS) will build and run on arm64. OpenAFS is not in the linux kernel tree so this may not work. The good news is mtreinish reports that after a quick test on some of his hardware AFS was working.

> 
> In practical terms, once we've created the resources, is there a guide
> to getting the infra bits in place for it? Who to give the credentials
> to/etc?

New clouds happen infrequently enough and require a reasonable amount of communication to get going so I don't think we have written down a guide beyond what we have on the donating resources page [2].

Typically what happens is we'll have an infra root act as the contact point to set things up, you'll provide them with credentials via email (or whatever communication system is most convenient) then they will immediately change the password(s). It is also helpful if we can get a contact individual for the cloud side and we'll record that in our passwords file so that any one of our infra roots knows who to talk to should the need arise.

Once the initial credential exchange happens the next step is for that infra root to double check quotas and get the mirror host up and running as well as image builder (and images) built. Once that is done you should be ready to push changes to projects that add jobs using the new nodepool labels (something like ubuntu-xenial-arm64).
> 
> Thanks!
> Gema

Thank you! this is exciting.

> 
> [1] https://www.linaro.org/groups/leg/
[2] https://docs.openstack.org/infra/system-config/contribute-cloud.html

Clark


From iwienand at redhat.com  Fri Jan 12 00:09:10 2018
From: iwienand at redhat.com (Ian Wienand)
Date: Fri, 12 Jan 2018 11:09:10 +1100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
Message-ID: <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>

On 01/10/2018 08:41 PM, Gema Gomez wrote:
> 1. Control-plane project that will host a nodepool builder with 8 vCPUs,
> 8 GB RAM, 1TB storage on a Cinder volume for the image building scratch
> space.
Does this mean you're planning on using diskimage-builder to produce
the images to run tests on?  I've seen occasional ARM things come by,
but of course diskimage-builder doesn't have CI for it (yet :) so it's
status is probably "unknown".

-i


From cboylan at sapwetik.org  Fri Jan 12 00:30:21 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Thu, 11 Jan 2018 16:30:21 -0800
Subject: [OpenStack-Infra] Old infra specs
Message-ID: <1515717021.1634844.1232582320.6F915C25@webmail.messagingengine.com>

Hello,

Recently Fungi removed old Jenkins' votes in Gerrit which had the effect of bubbling up older infra-specs to the top of the review list. This prompted me to start looking through the list. So far I have abandoned one spec, https://review.openstack.org/#/c/163637/, as the Zuul v3 spec and implementation made it redundant.

There are three other specs that I think we may be able to abandon for various reasons but they aren't as clear cut so want your feedback.

1. Tracking priority efforts with yaml, https://review.openstack.org/#/c/219372/. I'd like to abandon this one as we are attempting to use storyboard boards for this type of work tracking. We aren't using a board yet for our priority efforts but I think we could easily add a lane to https://storyboard.openstack.org/#!/board/54 to track that work.

2. Any bugtracker support in reviewstats, https://review.openstack.org/#/c/172886/. Russellb wrote reviewstats and doesn't seem to think this is necessary. Basically its easy enough to modify reviewstats to grok bug trackers other than launchpad. We also seem to have far less emphasis on stats tracking via this tool now so super low priority?

3. Infra hosted survey tool, https://review.openstack.org/#/c/349831/. We seem to be far less survey crazy recently compared to when this spec was proposed. Granted that may be due to lack of infra hosted survey tooling. Do we think this is still a service we want to run? and if so would the community get benefit from it?

Let me know what you think. Also, this list isn't comprehensive, I expect there will be more of these emails as I dig into the specs proposals more.

Thank you,
Clark


From fungi at yuggoth.org  Fri Jan 12 00:31:13 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 12 Jan 2018 00:31:13 +0000
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
Message-ID: <20180112003112.v34rfkvnhhi45kb5@yuggoth.org>

On 2018-01-12 11:09:10 +1100 (+1100), Ian Wienand wrote:
[...]
> I've seen occasional ARM things come by, but of course
> diskimage-builder doesn't have CI for it (yet :) so it's status is
> probably "unknown".

A problem which will solve itself! ;)
-- 
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/20180112/3d7b9dbd/attachment.sig>

From marcin.juszkiewicz at linaro.org  Fri Jan 12 10:17:33 2018
From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz)
Date: Fri, 12 Jan 2018 11:17:33 +0100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
Message-ID: <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>

Wu dniu 12.01.2018 o 01:09, Ian Wienand pisze:
> On 01/10/2018 08:41 PM, Gema Gomez wrote:
>> 1. Control-plane project that will host a nodepool builder with 8 vCPUs,
>> 8 GB RAM, 1TB storage on a Cinder volume for the image building scratch
>> space.
> Does this mean you're planning on using diskimage-builder to produce
> the images to run tests on?  I've seen occasional ARM things come by,
> but of course diskimage-builder doesn't have CI for it (yet :) so it's
> status is probably "unknown".

I had a quick look at diskimage-builder tool.

It looks to me that you always build MBR based image with one partition.
This will have to be changed as AArch64 is UEFI based platform (both
baremetal and VM) so disk needs to use GPT for partitioning and EFI
System Partition needs to be present (with grub-efi binary on it).

I am aware that you like to build disk images on your own but have you
considered using virt-install with generated preseed/kickstart files? It
would move several arch related things (like bootloader) to be handled
by distribution rules instead of handling them again in code.


Sent a patch to make it choose proper grub package on aarch64.


From pabelanger at redhat.com  Fri Jan 12 14:49:39 2018
From: pabelanger at redhat.com (Paul Belanger)
Date: Fri, 12 Jan 2018 09:49:39 -0500
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
Message-ID: <20180112144939.GA11821@localhost.localdomain>

On Fri, Jan 12, 2018 at 11:17:33AM +0100, Marcin Juszkiewicz wrote:
> Wu dniu 12.01.2018 o 01:09, Ian Wienand pisze:
> > On 01/10/2018 08:41 PM, Gema Gomez wrote:
> >> 1. Control-plane project that will host a nodepool builder with 8 vCPUs,
> >> 8 GB RAM, 1TB storage on a Cinder volume for the image building scratch
> >> space.
> > Does this mean you're planning on using diskimage-builder to produce
> > the images to run tests on?  I've seen occasional ARM things come by,
> > but of course diskimage-builder doesn't have CI for it (yet :) so it's
> > status is probably "unknown".
> 
> I had a quick look at diskimage-builder tool.
> 
> It looks to me that you always build MBR based image with one partition.
> This will have to be changed as AArch64 is UEFI based platform (both
> baremetal and VM) so disk needs to use GPT for partitioning and EFI
> System Partition needs to be present (with grub-efi binary on it).
> 
This is often the case when bringing new images online, that some changes to DIB
will be required to support them. I suspect somebody with access to AArch64
hardware will first need to run build-image.sh[1] and paste the build.log. That
will build an image locally for you using our DIB elements.

[1] http://git.openstack.org/cgit/openstack-infra/project-config/tree/tools/build-image.sh
> I am aware that you like to build disk images on your own but have you
> considered using virt-install with generated preseed/kickstart files? It
> would move several arch related things (like bootloader) to be handled
> by distribution rules instead of handling them again in code.
> 
I don't believe we want to look at using a new tool to build all our images,
switching to virt-install would be a large change. There are reasons why we
build images from scratch and don't believe switching to virt-install help
with that.
> 
> Sent a patch to make it choose proper grub package on aarch64.
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


From fungi at yuggoth.org  Fri Jan 12 14:59:12 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 12 Jan 2018 14:59:12 +0000
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
Message-ID: <20180112145912.rrmujb4h56oxqzvv@yuggoth.org>

On 2018-01-12 11:17:33 +0100 (+0100), Marcin Juszkiewicz wrote:
[...]
> I am aware that you like to build disk images on your own but have
> you considered using virt-install with generated preseed/kickstart
> files? It would move several arch related things (like bootloader)
> to be handled by distribution rules instead of handling them again
> in code.
[...]

We pre-generate and upload images via Glance because it allows us to
upload the same image to all providers (modulo processor
architecture in this case obviously). Once we have more than one
arm64 deployment to integrate, being able to know that we're
uploading identical images to all of them will be useful from a
consistency standpoint. Honestly, getting EFI bits into DIB is
probably no harder than writing a new nodepool builder backend to do
remote virt-install, and would be of use to a lot more people when
implemented.

If you look in
http://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/elements/bootloader/finalise.d/50-bootloader
there's support for setting up ppc64 PReP boot partitions... I don't
expect getting correct EFI partition creation integrated would be
much tougher? That said, it's something the DIB maintainers will
want to weigh in on obviously.
-- 
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/20180112/ebe3ff64/attachment.sig>

From marcin.juszkiewicz at linaro.org  Fri Jan 12 15:06:03 2018
From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz)
Date: Fri, 12 Jan 2018 16:06:03 +0100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <20180112144939.GA11821@localhost.localdomain>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
Message-ID: <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>

W dniu 12.01.2018 o 15:49, Paul Belanger pisze:
> On Fri, Jan 12, 2018 at 11:17:33AM +0100, Marcin Juszkiewicz wrote:
>> Wu dniu 12.01.2018 o 01:09, Ian Wienand pisze:
>>> On 01/10/2018 08:41 PM, Gema Gomez wrote:
>>>> 1. Control-plane project that will host a nodepool builder with 8 vCPUs,
>>>> 8 GB RAM, 1TB storage on a Cinder volume for the image building scratch
>>>> space.
>>> Does this mean you're planning on using diskimage-builder to produce
>>> the images to run tests on?  I've seen occasional ARM things come by,
>>> but of course diskimage-builder doesn't have CI for it (yet :) so it's
>>> status is probably "unknown".
>>
>> I had a quick look at diskimage-builder tool.
>>
>> It looks to me that you always build MBR based image with one partition.
>> This will have to be changed as AArch64 is UEFI based platform (both
>> baremetal and VM) so disk needs to use GPT for partitioning and EFI
>> System Partition needs to be present (with grub-efi binary on it).
>>
> This is often the case when bringing new images online, that some changes to DIB
> will be required to support them. I suspect somebody with access to AArch64
> hardware will first need to run build-image.sh[1] and paste the build.log. That
> will build an image locally for you using our DIB elements.

Or someone will try to target q35/uefi emulation instead of i440fx one
on x86 alone. I am tired of yet another disk image building projects.
All think they are special, all have same assumptions. btdt.

If I disable installing grub I can build useless one partition disk
image on arm64. Nothing will boot it.


From gema.gomez-solano at linaro.org  Fri Jan 12 15:19:47 2018
From: gema.gomez-solano at linaro.org (Gema Gomez)
Date: Fri, 12 Jan 2018 16:19:47 +0100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <20180112144939.GA11821@localhost.localdomain>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
Message-ID: <431fdf19-5681-daed-07a5-1eaa06edecec@linaro.org>



On 12/01/18 15:49, Paul Belanger wrote:
> On Fri, Jan 12, 2018 at 11:17:33AM +0100, Marcin Juszkiewicz wrote:
>> Wu dniu 12.01.2018 o 01:09, Ian Wienand pisze:
>>> On 01/10/2018 08:41 PM, Gema Gomez wrote:
>>>> 1. Control-plane project that will host a nodepool builder with 8 vCPUs,
>>>> 8 GB RAM, 1TB storage on a Cinder volume for the image building scratch
>>>> space.
>>> Does this mean you're planning on using diskimage-builder to produce
>>> the images to run tests on?  I've seen occasional ARM things come by,
>>> but of course diskimage-builder doesn't have CI for it (yet :) so it's
>>> status is probably "unknown".
>>
>> I had a quick look at diskimage-builder tool.
>>
>> It looks to me that you always build MBR based image with one partition.
>> This will have to be changed as AArch64 is UEFI based platform (both
>> baremetal and VM) so disk needs to use GPT for partitioning and EFI
>> System Partition needs to be present (with grub-efi binary on it).
>>
> This is often the case when bringing new images online, that some changes to DIB
> will be required to support them. I suspect somebody with access to AArch64
> hardware will first need to run build-image.sh[1] and paste the build.log. That
> will build an image locally for you using our DIB elements.
> 
> [1] http://git.openstack.org/cgit/openstack-infra/project-config/tree/tools/build-image.sh

Yep, that won't be an issue. Will do that on Monday.

>> I am aware that you like to build disk images on your own but have you
>> considered using virt-install with generated preseed/kickstart files? It
>> would move several arch related things (like bootloader) to be handled
>> by distribution rules instead of handling them again in code.
>>
> I don't believe we want to look at using a new tool to build all our images,
> switching to virt-install would be a large change. There are reasons why we
> build images from scratch and don't believe switching to virt-install help
> with that
>>
>> Sent a patch to make it choose proper grub package on aarch64.
>>
>> _______________________________________________
>> OpenStack-Infra mailing list
>> OpenStack-Infra at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 

-- 
Gema Gomez-Solano
Tech Lead, SDI
Linaro Ltd
IRC: gema@#linaro on irc.freenode.net


From gema.gomez-solano at linaro.org  Fri Jan 12 15:28:25 2018
From: gema.gomez-solano at linaro.org (Gema Gomez)
Date: Fri, 12 Jan 2018 16:28:25 +0100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <1515713307.1621085.1232530640.1104FEFD@webmail.messagingengine.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <1515713307.1621085.1232530640.1104FEFD@webmail.messagingengine.com>
Message-ID: <06dec89f-c498-eb41-1272-2b6f1ba24c1c@linaro.org>



On 12/01/18 00:28, Clark Boylan wrote:
> On Wed, Jan 10, 2018, at 1:41 AM, Gema Gomez wrote:
>> Hi all,
>>
>> Linaro would like to add a new cloud to infra so that we can run tests
>> on ARM64 going forward. This discussion has been ongoing for the good
>> part of a year, apologies that it took us so long to get to a point
>> where we feel comfortable going ahead in terms of stability of
>> infrastructure and functionality.
>>
>> My team has been taking care of making OpenStack as multiarch as
>> possible and making the experience of using an ARM64 cloud as close to
>> using a traditional amd64 one as possible. We have the Linaro Developer
>> Cloud program, which consists of a set of clouds that run on ARM64
>> hardware donated by the Linaro Enterprise Group members[1] and dedicated
>> to enablement/testing of upstream projects. Until recently our clouds
>> were run by an engineering team and were used to do enablement of
>> different projects and bug fixes of OpenStack, now we have a dedicated
>> admin and we are ready to take it a step forward. The clouds are
>> currently running OpenStack Newton but we are going to be moving to
>> Queens as soon as the release is out. Kolla has volunteered to be the
>> first project for this experiment, they have been pushing us to start
>> doing CI on our images so they also feel more comfortable accepting our
>> changes. We will welcome any other project that wants to be part of this
>> experiment, but we'll focus our engineering efforts initially on
>> enabling Kolla CI.
>>
>> After some preliminary discussion with fungi and inc0, we are going to
>> start small and grow from there. The initial plan is to add 2 projects:
>>
>> 1. Control-plane project that will host a nodepool builder with 8 vCPUs,
>> 8 GB RAM, 1TB storage on a Cinder volume for the image building scratch
>> space. A cache server with similar specs + 200GB on a cinder volume for
>> AFS and Apache proxy caches. They will have a routable IP address.
>>
>> 2. Jobs project, we'll have capacity for 6 test instances initially and
>> after initial assessment grow it as required (8 vCPUs/8 GB RAM, 80GB
>> storage, 1 routable IP each).
>>
>> Is there anything else we are missing for the initial trial? Any
>> questions/concerns before we start? I will try to have presence on the
>> infra weekly calls/IRC channel or have someone from my team on them
>> going forward.
> 
> This plan looks good to me. The one question I had on IRC (and putting it here for historical reasons) is whether or not Andrew FileSystem (AFS) will build and run on arm64. OpenAFS is not in the linux kernel tree so this may not work. The good news is mtreinish reports that after a quick test on some of his hardware AFS was working.
> 
>>
>> In practical terms, once we've created the resources, is there a guide
>> to getting the infra bits in place for it? Who to give the credentials
>> to/etc?
> 
> New clouds happen infrequently enough and require a reasonable amount of communication to get going so I don't think we have written down a guide beyond what we have on the donating resources page [2].
> 
> Typically what happens is we'll have an infra root act as the contact point to set things up, you'll provide them with credentials via email (or whatever communication system is most convenient) then they will immediately change the password(s). It is also helpful if we can get a contact individual for the cloud side and we'll record that in our passwords file so that any one of our infra roots knows who to talk to should the need arise.
> 
> Once the initial credential exchange happens the next step is for that infra root to double check quotas and get the mirror host up and running as well as image builder (and images) built. Once that is done you should be ready to push changes to projects that add jobs using the new nodepool labels (something like ubuntu-xenial-arm64).

Sounds good. Quick update, we are working on applying a patch
(https://review.openstack.org/#/c/489951/) to our Newton deployment so
that uploaded images do not require any extra parameters. Once that is
done we can give infra credentials. Who will be our infra counterpart
for that?

We are also happy to add engineers to work on any fixes required to make
the infra tools work as seamlessly as possible with ARM64.

Cheers!
Gema

>>
>> Thanks!
>> Gema
> 
> Thank you! this is exciting.
> 
>>
>> [1] https://www.linaro.org/groups/leg/
> [2] https://docs.openstack.org/infra/system-config/contribute-cloud.html
> 
> Clark
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 

-- 
Gema Gomez-Solano
Tech Lead, SDI
Linaro Ltd
IRC: gema@#linaro on irc.freenode.net


From fungi at yuggoth.org  Fri Jan 12 15:54:20 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 12 Jan 2018 15:54:20 +0000
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
Message-ID: <20180112155419.ead6msjlbbobup5o@yuggoth.org>

On 2018-01-12 16:06:03 +0100 (+0100), Marcin Juszkiewicz wrote:
> Or someone will try to target q35/uefi emulation instead of i440fx
> one on x86 alone.

I'm curious why we'd need emulation there... the expectation is that
DIB is running on a native 64-bit ARM system (under a hypervisor,
but still not cross-architecture). The reason we'll be deploying a
Nodepool builder server in the environment is so that we don't need
to worry about cross-building an arm64 rootfs and boot partition.

> I am tired of yet another disk image building projects.
> All think they are special, all have same assumptions. btdt.

While I can't disagree with regard to the proliferation of disk
image builders, this one has existed since July of 2012 and sees
extensive use throughout OpenStack. At the time it came into being,
there weren't a lot of good options for cross-distro orchestration
of image builds (e.g., one tool which could build Debian images on
CentOS and CentOS images on Debian).

> If I disable installing grub I can build useless one partition disk
> image on arm64. Nothing will boot it.

See my other reply on this thread with a link to the bootloader
element. It seems like it's got support implemented for
multi-partition images needed by 64-bit PowerPC systems, so not
terribly dissimilar.
-- 
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/20180112/341eba6f/attachment.sig>

From marcin.juszkiewicz at linaro.org  Fri Jan 12 16:54:20 2018
From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz)
Date: Fri, 12 Jan 2018 17:54:20 +0100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <20180112155419.ead6msjlbbobup5o@yuggoth.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
Message-ID: <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>

W dniu 12.01.2018 o 16:54, Jeremy Stanley pisze:
> On 2018-01-12 16:06:03 +0100 (+0100), Marcin Juszkiewicz wrote:
>> Or someone will try to target q35/uefi emulation instead of i440fx 
>> one on x86 alone.
> 
> I'm curious why we'd need emulation there...

Developers around x86 virtualisation live in world where VM is like PC
from 90s (i440fx qemu model). You boot BIOS which reads bootloader from
1st sector of your storage, you have 32 PCI slots with hotplug etc. All
you need is VM + disk image with one partition using MBR partitioning.

If you want to have something which reminds Arm64 (but still is x86)
then you switch to Q35 qemu model and enable UEFI as bootloader. And all
your existing (and working with previous model) disk images with one
partition are useless. Your hotplug options are limited to amount of
pcie root ports defined in VM (usually 2-3). All your disk images need
to be converted to GPT partitioning, you need to have ESP (EFI System
Partition) partition with EFI bootloader stored there.

But (nearly) no one in x86 world goes for q35 model. Mostly because it
requires more work to be done and because users will ask why they can
not add 6th storage and 11th network card. And in arm64 world we do not
have such luck.

That's why I mentioned q35.

>> If I disable installing grub I can build useless one partition
>> disk image on arm64. Nothing will boot it.
> 
> See my other reply on this thread with a link to the bootloader 
> element. It seems like it's got support implemented for 
> multi-partition images needed by 64-bit PowerPC systems, so not 
> terribly dissimilar.

Firmware used by 64-bit Power system accepts MBR partitioned storage.

UEFI expects GPT and DIB is completely not prepared for it. I made
block-layout-arm64.yaml file and got it used just to see "sorry, mbr
expected" message. You have whole Python class to create MBR bit by bit
when few calls to 'sfdisk/gdisk' shell commands do the same.



From fungi at yuggoth.org  Fri Jan 12 18:01:35 2018
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 12 Jan 2018 18:01:35 +0000
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
 <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
Message-ID: <20180112180134.zdtkmqffvuddb4n4@yuggoth.org>

On 2018-01-12 17:54:20 +0100 (+0100), Marcin Juszkiewicz wrote:
[...]
> UEFI expects GPT and DIB is completely not prepared for it. I made
> block-layout-arm64.yaml file and got it used just to see "sorry,
> mbr expected" message.

I concur. It looks like the DIB team would welcome work toward GPT
support based on the label entry at
https://docs.openstack.org/diskimage-builder/latest/user_guide/building_an_image.html#module-partitioning
and I find https://bugzilla.redhat.com/show_bug.cgi?id=1488557
suggesting there's probably also interest within Red Hat for it as
well.

> You have whole Python class to create MBR bit by bit when few
> calls to 'sfdisk/gdisk' shell commands do the same.

Well, the comments at
http://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/block_device/level1/mbr.py?id=5d5fa06#n28
make some attempt at explaining why it doesn't just do that instead
(at least as of ~7 months ago?). Per the subsequent discussion in
#openstack-dib I don't know whether there is also work underway to
solve the identified deficiencies in sfdisk and gparted but those
more directly involved in DIB development may have answers when
they're around (which they may not be at this point in the weekend).
-- 
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/20180112/fd788a19/attachment.sig>

From cboylan at sapwetik.org  Fri Jan 12 22:42:43 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Fri, 12 Jan 2018 14:42:43 -0800
Subject: [OpenStack-Infra] Merging feature/zuulv3 into master in Zuul and
	Nodepool repos
Message-ID: <1515796963.2999351.1233704024.0A7E95F1@webmail.messagingengine.com>

Hello,

I think we are very close to being ready to merge the zuulv3 feature branch into master in both the Zuul and Nodepool repos. In particular we merged https://review.openstack.org/#/c/523951/ which should prevent breakages for anyone using that deployment method (single_node_ci) for an all in one CI suite.

One thing I've noticed is that we don't have this same handling in the lower level individual service manifests. For us I don't think that is a major issue, we'll just pin our builders to the nodepool 0.5.0 tag, do the merge, then update our configs and switch back to master. But do we have any idea if it is common for third part CI's to bypass single_node_ci and construct their own like we do?

As for the actual merging itself a quick test locally using `git merge -s recursive -X theirs feature/zuulv3` on the master branch of nodepool appears to work. I have to delete the files that the feature branch deleted by hand but otherwise the merge is automated. The resulting tree does also pass `tox -e pep8` and `tox -epy36` testing.

We will probably want a soft freeze of both Zuul and Nodepool then do our best to get both merged together so that we don't have to remember which project has merged and which hasn't. Once that is done we will need to repropose any open changes on the feature branch to the master branch, abandon the changes on the feature branch then delete the feature branch. Might be a good idea to merge as many feature branch changes as possible before hand?

Am I missing anything?

Thank you,
Clark


From dradez at redhat.com  Fri Jan 12 23:27:50 2018
From: dradez at redhat.com (Dan Radez)
Date: Fri, 12 Jan 2018 18:27:50 -0500
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <20180112145912.rrmujb4h56oxqzvv@yuggoth.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112145912.rrmujb4h56oxqzvv@yuggoth.org>
Message-ID: <db99df2c-eb57-0a61-f22d-9170d36143d5@redhat.com>

fwiw
We've been building arm images for tripleo and posting them.
https://images.rdoproject.org/aarch64/pike/delorean/current-tripleo-rdo/


This uses delorean and overcloud build:

    DIB_YUM_REPO_CONF+="/etc/yum.repos.d/delorean-deps-${OSVER}.repo
/etc/yum.repos.d/delorean-${OSVER}.repo /etc/yum.repos.d/ceph.repo
/etc/yum.repos.d/epel.repo /etc/yum.repos.d/radez.fedorapeople.repo" \
    openstack --debug overcloud image build \
        --config-file overcloud-aarch64.yaml \
        --config-file
/usr/share/openstack-tripleo-common/image-yaml/overcloud-images.yaml \
        --config-file
/usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos7.yaml
    # --config-file overcloud-images.yaml --config-file
overcloud-images-centos7.yaml --config-file aarch64-gumpf.yaml --image-name
    #openstack --debug overcloud image build --type overcloud-full
--node-arch aarch64

It's not quite an orthodox RDO build, There are still a few things in
place that work around arm related packaging discrepancies or x86
related configs. But we get good builds from it.

I don't know the details of what overcloud build does to the dib builds,
Though I don't believe these are whole disk images. I think the
overcloud and undercloud are root partition images and the kernel an
initrd are composed into the disk for the overcloud by OOO and we direct
boot them to launch a undercloud VM.

Happy to share details if anyone wants more.

Radez



On 01/12/2018 09:59 AM, Jeremy Stanley wrote:
> On 2018-01-12 11:17:33 +0100 (+0100), Marcin Juszkiewicz wrote:
> [...]
>> I am aware that you like to build disk images on your own but have
>> you considered using virt-install with generated preseed/kickstart
>> files? It would move several arch related things (like bootloader)
>> to be handled by distribution rules instead of handling them again
>> in code.
> [...]
>
> We pre-generate and upload images via Glance because it allows us to
> upload the same image to all providers (modulo processor
> architecture in this case obviously). Once we have more than one
> arm64 deployment to integrate, being able to know that we're
> uploading identical images to all of them will be useful from a
> consistency standpoint. Honestly, getting EFI bits into DIB is
> probably no harder than writing a new nodepool builder backend to do
> remote virt-install, and would be of use to a lot more people when
> implemented.
>
> If you look in
> http://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/elements/bootloader/finalise.d/50-bootloader
> there's support for setting up ppc64 PReP boot partitions... I don't
> expect getting correct EFI partition creation integrated would be
> much tougher? That said, it's something the DIB maintainers will
> want to weigh in on obviously.
>
>
> _______________________________________________
> 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/20180112/45e24658/attachment.html>

From cboylan at sapwetik.org  Sat Jan 13 00:21:21 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Fri, 12 Jan 2018 16:21:21 -0800
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <db99df2c-eb57-0a61-f22d-9170d36143d5@redhat.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112145912.rrmujb4h56oxqzvv@yuggoth.org>
 <db99df2c-eb57-0a61-f22d-9170d36143d5@redhat.com>
Message-ID: <1515802881.3021942.1233775744.1AC77074@webmail.messagingengine.com>

On Fri, Jan 12, 2018, at 3:27 PM, Dan Radez wrote:
> fwiw
> We've been building arm images for tripleo and posting them.
> https://images.rdoproject.org/aarch64/pike/delorean/current-tripleo-rdo/
> 
> 
> This uses delorean and overcloud build:
> 
>     DIB_YUM_REPO_CONF+="/etc/yum.repos.d/delorean-deps-${OSVER}.repo
> /etc/yum.repos.d/delorean-${OSVER}.repo /etc/yum.repos.d/ceph.repo
> /etc/yum.repos.d/epel.repo /etc/yum.repos.d/radez.fedorapeople.repo" \
>     openstack --debug overcloud image build \
>         --config-file overcloud-aarch64.yaml \
>         --config-file
> /usr/share/openstack-tripleo-common/image-yaml/overcloud-images.yaml \
>         --config-file
> /usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos7.yaml
>     # --config-file overcloud-images.yaml --config-file
> overcloud-images-centos7.yaml --config-file aarch64-gumpf.yaml --image-name
>     #openstack --debug overcloud image build --type overcloud-full
> --node-arch aarch64
> 
> It's not quite an orthodox RDO build, There are still a few things in
> place that work around arm related packaging discrepancies or x86
> related configs. But we get good builds from it.
> 
> I don't know the details of what overcloud build does to the dib builds,
> Though I don't believe these are whole disk images. I think the
> overcloud and undercloud are root partition images and the kernel an
> initrd are composed into the disk for the overcloud by OOO and we direct
> boot them to launch a undercloud VM.
> 
> Happy to share details if anyone wants more.
> 
> Radez

Looking into this a big more `openstack overcloud image build` takes in the yaml config files you list and converts that into a forked diskimage-builder process to build an image. The centos7 dib element in particular seems to have aarch64 support via building on top of the upstream centos7 aarch64 image. We do use the centos-minimal element for our images though as it allows us to do things like install glean. Chances are we still need need to sort out UEFI and GPT for general dib use.

Just to be sure there isn't any other magic going on can you provide the contents of the overcloud-aarch64.yaml or point to where it can be found? It doesn't appear to be in tripleo-common with the other configs.

It is good to know that this is working in some cases though.

Clark


From iwienand at redhat.com  Sat Jan 13 02:26:59 2018
From: iwienand at redhat.com (Ian Wienand)
Date: Sat, 13 Jan 2018 13:26:59 +1100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <20180112180134.zdtkmqffvuddb4n4@yuggoth.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
 <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
 <20180112180134.zdtkmqffvuddb4n4@yuggoth.org>
Message-ID: <34e8f12e-82bd-5a30-650b-630503f4365a@redhat.com>

On 01/13/2018 05:01 AM, Jeremy Stanley wrote:
> On 2018-01-12 17:54:20 +0100 (+0100), Marcin Juszkiewicz wrote:
> [...]
>> UEFI expects GPT and DIB is completely not prepared for it. I made
>> block-layout-arm64.yaml file and got it used just to see "sorry,
>> mbr expected" message.
> 
> I concur. It looks like the DIB team would welcome work toward GPT
> support based on the label entry at
> https://docs.openstack.org/diskimage-builder/latest/user_guide/building_an_image.html#module-partitioning
> and I find https://bugzilla.redhat.com/show_bug.cgi?id=1488557
> suggesting there's probably also interest within Red Hat for it as
> well.

Yes, it would be welcome.  So far it's been a bit of a "nice to have"
which has kept it low priority, but a concrete user could help our
focus here.

>> You have whole Python class to create MBR bit by bit when few
>> calls to 'sfdisk/gdisk' shell commands do the same.
> 
> Well, the comments at
> http://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/block_device/level1/mbr.py?id=5d5fa06#n28
> make some attempt at explaining why it doesn't just do that instead
> (at least as of ~7 months ago?).

I agree with the broad argument of this sentiment; that writing a
binary-level GPT implementation is out of scope for dib (and the
existing MBR one is, with hindsight, something I would have pushed
back on more).

dib-block-device being in python is a double edged sword -- on the one
hand it's harder to drop in a few lines like in shell, but on the
other hand it has proper data structures, unit testing, logging and
config-reading abilities -- things that all are rather ugly, or get
lost with shell.  The code is not perfect, but doing more things like
[1,2] to enhance and better use libraries will help everyone (and
notice that's making it easier to translate directly to parted, no
coincidence :)

The GPL linkage issue, as described in the code, prevents us doing the
obvious thing and calling directly via python.  But I believe will we
be OK just making system() calls to parted to configure GPT;
especially given the clearly modular nature of it all.

In terms of implementation, since you've already looked, I think
essentially diskimage_builder/block_device/level1.py create() will
need some moderate re-factoring to call a gpt implementation in
response to a gpt label, which could translate self.partitions into a
format for calling parted via our existing exec_sudo.

This is highly amenable to a test-driven development scenario as we
have some pretty good existing unit tests for various parts of the
partitioning to template from (for example, tests/test_lvm.py).  So
bringing up a sample config and test, then working backwards from what
calls we expect to see is probably a great way to start.  Even if you
just want to provide some (pseudo)shell examples based on your
experience and any thoughts on the yaml config files it would be
helpful.

--

I try to run the meetings described in [3] if there is anything on the
agenda.  The cadence is probably not appropriate for this, we can do
much better via mail here, or #openstack-dib in IRC.  I hope we can
collaborate in a positive way; as I mentioned I think as a first step
we'd be best working backwards from what we expect to see in terms of
configuration, partition layout and parted calls.

Thanks,

-i

[1] https://review.openstack.org/#/c/503574/
[2] https://review.openstack.org/#/c/503572/
[3] https://wiki.openstack.org/wiki/Meetings/diskimage-builder


From iwienand at redhat.com  Mon Jan 15 08:03:22 2018
From: iwienand at redhat.com (Ian Wienand)
Date: Mon, 15 Jan 2018 19:03:22 +1100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <34e8f12e-82bd-5a30-650b-630503f4365a@redhat.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
 <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
 <20180112180134.zdtkmqffvuddb4n4@yuggoth.org>
 <34e8f12e-82bd-5a30-650b-630503f4365a@redhat.com>
Message-ID: <785fb91c-268b-66f8-2149-a542e57f8228@redhat.com>

On 01/13/2018 01:26 PM, Ian Wienand wrote:
> In terms of implementation, since you've already looked, I think
> essentially diskimage_builder/block_device/level1.py create() will
> need some moderate re-factoring to call a gpt implementation in
> response to a gpt label, which could translate self.partitions into a
> format for calling parted via our existing exec_sudo.

> bringing up a sample config and test, then working backwards from what
> calls we expect to see

I've started down this path with

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

... still very wip

-i


From dradez at redhat.com  Mon Jan 15 15:52:22 2018
From: dradez at redhat.com (Dan Radez)
Date: Mon, 15 Jan 2018 10:52:22 -0500
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <1515802881.3021942.1233775744.1AC77074@webmail.messagingengine.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112145912.rrmujb4h56oxqzvv@yuggoth.org>
 <db99df2c-eb57-0a61-f22d-9170d36143d5@redhat.com>
 <1515802881.3021942.1233775744.1AC77074@webmail.messagingengine.com>
Message-ID: <5cf67d6c-675a-7d75-433e-3d0cfc96f33b@redhat.com>



On 01/12/2018 07:21 PM, Clark Boylan wrote:
> On Fri, Jan 12, 2018, at 3:27 PM, Dan Radez wrote:
>> fwiw
>> We've been building arm images for tripleo and posting them.
>> https://images.rdoproject.org/aarch64/pike/delorean/current-tripleo-rdo/
>>
>>
>> This uses delorean and overcloud build:
>>
>>     DIB_YUM_REPO_CONF+="/etc/yum.repos.d/delorean-deps-${OSVER}.repo
>> /etc/yum.repos.d/delorean-${OSVER}.repo /etc/yum.repos.d/ceph.repo
>> /etc/yum.repos.d/epel.repo /etc/yum.repos.d/radez.fedorapeople.repo" \
>>     openstack --debug overcloud image build \
>>         --config-file overcloud-aarch64.yaml \
>>         --config-file
>> /usr/share/openstack-tripleo-common/image-yaml/overcloud-images.yaml \
>>         --config-file
>> /usr/share/openstack-tripleo-common/image-yaml/overcloud-images-centos7.yaml
>>     # --config-file overcloud-images.yaml --config-file
>> overcloud-images-centos7.yaml --config-file aarch64-gumpf.yaml --image-name
>>     #openstack --debug overcloud image build --type overcloud-full
>> --node-arch aarch64
>>
>> It's not quite an orthodox RDO build, There are still a few things in
>> place that work around arm related packaging discrepancies or x86
>> related configs. But we get good builds from it.
>>
>> I don't know the details of what overcloud build does to the dib builds,
>> Though I don't believe these are whole disk images. I think the
>> overcloud and undercloud are root partition images and the kernel an
>> initrd are composed into the disk for the overcloud by OOO and we direct
>> boot them to launch a undercloud VM.
>>
>> Happy to share details if anyone wants more.
>>
>> Radez
> Looking into this a big more `openstack overcloud image build` takes in the yaml config files you list and converts that into a forked diskimage-builder process to build an image. The centos7 dib element in particular seems to have aarch64 support via building on top of the upstream centos7 aarch64 image. We do use the centos-minimal element for our images though as it allows us to do things like install glean. Chances are we still need need to sort out UEFI and GPT for general dib use.
>
> Just to be sure there isn't any other magic going on can you provide the contents of the overcloud-aarch64.yaml or point to where it can be found? It doesn't appear to be in tripleo-common with the other configs.
>
> It is good to know that this is working in some cases though.
>
> Clark
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
The centos support that's there is because I added it. :)
Here's the overcloud-aarch64 file, Its purpose is just to switch the
arch for the two images built.
I think the packages reference was because there was a missing dep that
has since been resolved.

[stack at localhost ~]$ cat overcloud-aarch64.yaml
  disk_images:
  -
    imagename: overcloud-full
    arch: arm64
    packages:
      - os-collect-config
  -
    imagename: ironic-python-agent
    arch: arm64



From iwienand at redhat.com  Mon Jan 15 22:51:25 2018
From: iwienand at redhat.com (Ian Wienand)
Date: Tue, 16 Jan 2018 09:51:25 +1100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <BAB33867-D148-49C4-8883-277E0436F867@redhat.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
 <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
 <20180112180134.zdtkmqffvuddb4n4@yuggoth.org>
 <34e8f12e-82bd-5a30-650b-630503f4365a@redhat.com>
 <785fb91c-268b-66f8-2149-a542e57f8228@redhat.com>
 <BAB33867-D148-49C4-8883-277E0436F867@redhat.com>
Message-ID: <79037f7e-973b-66d4-105d-a94da79a9f60@redhat.com>

On 01/16/2018 12:11 AM, Frank Jansen wrote:
> do you have any insight into the availability of a physical
> environment for the ARM64 cloud?

> I’m curious, as there may be a need for downstream testing, which I
> would assume will want to make use of our existing OSP CI framework.

Sorry, not 100% sure what you mean here?  I think the theory is that
this would be an ARM64 based cloud attached to OpenStack infra and
thus run any jobs infra could ...

-i



From corvus at inaugust.com  Mon Jan 15 23:34:19 2018
From: corvus at inaugust.com (James E. Blair)
Date: Mon, 15 Jan 2018 15:34:19 -0800
Subject: [OpenStack-Infra] Merging feature/zuulv3 into master in Zuul
	and Nodepool repos
In-Reply-To: <1515796963.2999351.1233704024.0A7E95F1@webmail.messagingengine.com>
 (Clark Boylan's message of "Fri, 12 Jan 2018 14:42:43 -0800")
References: <1515796963.2999351.1233704024.0A7E95F1@webmail.messagingengine.com>
Message-ID: <871siqae84.fsf@meyer.lemoncheese.net>

Clark Boylan <cboylan at sapwetik.org> writes:

> Hello,
>
> I think we are very close to being ready to merge the zuulv3 feature
> branch into master in both the Zuul and Nodepool repos. In particular
> we merged https://review.openstack.org/#/c/523951/ which should
> prevent breakages for anyone using that deployment method
> (single_node_ci) for an all in one CI suite.
>
> One thing I've noticed is that we don't have this same handling in the
> lower level individual service manifests. For us I don't think that is
> a major issue, we'll just pin our builders to the nodepool 0.5.0 tag,
> do the merge, then update our configs and switch back to master. But
> do we have any idea if it is common for third part CI's to bypass
> single_node_ci and construct their own like we do?
>
> As for the actual merging itself a quick test locally using `git merge
> -s recursive -X theirs feature/zuulv3` on the master branch of
> nodepool appears to work. I have to delete the files that the feature
> branch deleted by hand but otherwise the merge is automated. The
> resulting tree does also pass `tox -e pep8` and `tox -epy36` testing.
>
> We will probably want a soft freeze of both Zuul and Nodepool then do
> our best to get both merged together so that we don't have to remember
> which project has merged and which hasn't. Once that is done we will
> need to repropose any open changes on the feature branch to the master
> branch, abandon the changes on the feature branch then delete the
> feature branch. Might be a good idea to merge as many feature branch
> changes as possible before hand?
>
> Am I missing anything?
>
> Thank you,
> Clark

Thanks for looking into that!

I don't think we're in a great position to merge a lot of the
outstanding changes on the feature branch -- many of them are post 3.0
things and I don't want to distract us from stabilizing and finalizing
the release.  We may just want to plan on porting a bunch over.

Let's plan on performing the merge this Thursday, Jan 18th.

-Jim


From gema.gomez-solano at linaro.org  Tue Jan 16 08:17:36 2018
From: gema.gomez-solano at linaro.org (Gema Gomez)
Date: Tue, 16 Jan 2018 08:17:36 +0000
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <79037f7e-973b-66d4-105d-a94da79a9f60@redhat.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
 <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
 <20180112180134.zdtkmqffvuddb4n4@yuggoth.org>
 <34e8f12e-82bd-5a30-650b-630503f4365a@redhat.com>
 <785fb91c-268b-66f8-2149-a542e57f8228@redhat.com>
 <BAB33867-D148-49C4-8883-277E0436F867@redhat.com>
 <79037f7e-973b-66d4-105d-a94da79a9f60@redhat.com>
Message-ID: <ad6cd2e6-bee6-0921-1953-94300d599d3a@linaro.org>

On 15/01/18 22:51, Ian Wienand wrote:
> On 01/16/2018 12:11 AM, Frank Jansen wrote:
>> do you have any insight into the availability of a physical
>> environment for the ARM64 cloud?
> 
>> I’m curious, as there may be a need for downstream testing, which I
>> would assume will want to make use of our existing OSP CI framework.
> 
> Sorry, not 100% sure what you mean here?  I think the theory is that
> this would be an ARM64 based cloud attached to OpenStack infra and
> thus run any jobs infra could ...

+1, this is the idea indeed.

Gema
> 
> -i
> 
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



From Tobias.Henkel at bmw.de  Tue Jan 16 11:31:13 2018
From: Tobias.Henkel at bmw.de (Tobias.Henkel at bmw.de)
Date: Tue, 16 Jan 2018 11:31:13 +0000
Subject: [OpenStack-Infra] RFC: Zuul executor congestion control
Message-ID: <703C4047-5118-4034-A1F0-B6C8C68F8BBF@bmw.de>

Hi zuulers,

the zuul-executor resource governor topic seems to be a recurring now and we might want take the step and make it a bit smarter.

I think the current approach of a set of on/off governors based on the current conditions may not be sufficient. I thought about that and like to have feedback about what you think about that.

TLDR; I propose having a congestion control algorithm managing a congestion window utilizing a slow start with a generic sensor interface and weighted job costs.


Algorithm
--------------

The algorithm I propose would manage a congestion window of an abstract metric measured in points. This is intended to leverage some (simple) weighting of jobs as multi node jobs e.g. probably take more resources than single node jobs.

The algorithm consists of two threads. One managing the congestion window, one accepting the jobs.

Congestion window management:

  1.  Start with a window of size START_WINDOW_SIZE points
  2.  Get current used percentage of window
  3.  Ask sensors for green/red
  4.  If all green AND window-usage > INCREASE_WINDOW_THRESHOLD
     *   Increase window
  5.  If one red
     *   Decrease window below current usage
  6.  Loop back to step 2

Job accepting:

  1.  Get current used window-percentage
  2.  If window-usage < window-size
     *   Register function if necessary
     *   Accept job
     *   summarize window-usage (the job will update asynchronously when finished)
  3.  Else
     *   Deregister function if necessary
  4.  Loop back to step 1

The magic numbers used are subject for further discussion and algorithm tweaking.


Weighting of jobs
------------------------
Now different jobs take different amounts of resources so we would need some simple estimation about that. This could be tuned in the future. For the start I’d propose something simple like this:

Cost_job = 5 + 5 * size of inventory

In the future this could be improved to estimate the costs based on historical data of the individual jobs.


Sensors
----------

Further different ways of deployment will have different needs about the sensors. E.g. the load and ram sensors which utilize load1 and memfree won’t work in a kubernetes based deployments as they assume the executor is located exclusively on a VM. In order to mitigate I’d like to have some generic sensor interface where we also could put a cgroups sensor into which checks resource usage according to the cgroup limit (which is what we need for a kubernetes hosted zuul). We also could put a filesystem sensor in which monitors if there is enough local storage. For hooking this into the algorithm I think we could start with a single function

def isStatusOk() -> bool


Exposing the data
-------------------------

The window-usage and window-size values could also be exported to statsd. This could enable autoscaling of the number of executors in deployments supporting that.


What are your thoughts about that?

Kind regards
Tobi


--
BMW Car IT GmbH
Tobias Henkel
Spezialist Entwicklung
Moosacher Straße 86
80809 München

Tel.:  ­+49 89 189311-48
Fax:  +49 89 189311-20
Mail: tobias.henkel at bmw.de<mailto:tobias.henkel at bmw.de>
Web: http://www.bmw-carit.de<http://www.bmw-carit.de/>
-----------------------------------------------------------------------------
BMW Car IT GmbH
Geschäftsführer: Kai-Uwe Balszuweit
und Christian Salzmann
Sitz und Registergericht: München HRB 134810
-----------------------------------------------------------------------------


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

From corvus at inaugust.com  Tue Jan 16 15:20:19 2018
From: corvus at inaugust.com (James E. Blair)
Date: Tue, 16 Jan 2018 07:20:19 -0800
Subject: [OpenStack-Infra] New Zuul mailing lists
Message-ID: <8737357rv0.fsf@meyer.lemoncheese.net>

Hi,

We've created two new mailing lists for Zuul.  If you run an instance of
Zuul, or are a user of Zuul, you should subscribe.  The new lists are:

zuul-announce at lists.zuul-ci.org
-------------------------------

http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-announce

This will be a low-traffic, announce-only list where we post important
information about Zuul releases, or changes to the zuul-jobs repository.
If you operate or package Zuul, you should definitely subscribe to this.
If you spend a lot of time working with jobs defined in the zuul-jobs
repo, or jobs which inherit from that, it would also be a good idea to
subscribe to this list.

zuul-discuss at lists.zuul-ci.org
------------------------------

http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss

This is where all discussion about Zuul will take place.  Operaters,
users, and developers of Zuul should all participate in this list.  If
someone has a question about how to accomplish something with Zuul, we
will answer it here.  If we need to discuss making a change to the job
syntax, this is also the place.  We're all involved in using and
developing Zuul together.

Treat this as an "upstream" for Zuul, meaning that if a discussion topic
pertains entirely to OpenStack's use of Zuul -- for instance, whether we
should make a certain change to openstack-tox-py35, or if we should add
more executors -- please use the openstack-dev or openstack-infra lists
as appropriate.

Please go ahead and subscribe now, and we will start using the new lists
soon.

Thanks,

Jim


From corvus at inaugust.com  Tue Jan 16 16:47:59 2018
From: corvus at inaugust.com (James E. Blair)
Date: Tue, 16 Jan 2018 08:47:59 -0800
Subject: [OpenStack-Infra] RFC: Zuul executor congestion control
In-Reply-To: <703C4047-5118-4034-A1F0-B6C8C68F8BBF@bmw.de> (Tobias Henkel's
 message of "Tue, 16 Jan 2018 11:31:13 +0000")
References: <703C4047-5118-4034-A1F0-B6C8C68F8BBF@bmw.de>
Message-ID: <87o9lt698g.fsf@meyer.lemoncheese.net>

<Tobias.Henkel at bmw.de> writes:

> Hi zuulers,
>
> the zuul-executor resource governor topic seems to be a recurring now
> and we might want take the step and make it a bit smarter.

To be honest, it keeps coming up because we haven't gotten around to
finishing the work already in progress on this.  We're not done with the
current approach yet, so let's not declare it a failure until we've
tried it and learned what we can.

> I think the current approach of a set of on/off governors based on the
> current conditions may not be sufficient. I thought about that and
> like to have feedback about what you think about that.
>
> TLDR; I propose having a congestion control algorithm managing a
> congestion window utilizing a slow start with a generic sensor
> interface and weighted job costs.
>
> Algorithm
> --------------
>
> The algorithm I propose would manage a congestion window of an
> abstract metric measured in points. This is intended to leverage some
> (simple) weighting of jobs as multi node jobs e.g. probably take more
> resources than single node jobs.
>
> The algorithm consists of two threads. One managing the congestion
> window, one accepting the jobs.
>
> Congestion window management:
>
>   1.  Start with a window of size START_WINDOW_SIZE points
>   2.  Get current used percentage of window
>   3.  Ask sensors for green/red
>   4.  If all green AND window-usage > INCREASE_WINDOW_THRESHOLD
>      *   Increase window
>   5.  If one red
>      *   Decrease window below current usage
>   6.  Loop back to step 2
>
> Job accepting:
>
>   1.  Get current used window-percentage
>   2.  If window-usage < window-size
>      *   Register function if necessary
>      *   Accept job
>      *   summarize window-usage (the job will update asynchronously when finished)
>   3.  Else
>      *   Deregister function if necessary
>   4.  Loop back to step 1
>
> The magic numbers used are subject for further discussion and
> algorithm tweaking.
>
>
> Weighting of jobs
> ------------------------
> Now different jobs take different amounts of resources so we would need some simple estimation about that. This could be tuned in the future. For the start I’d propose something simple like this:
>
> Cost_job = 5 + 5 * size of inventory
>
> In the future this could be improved to estimate the costs based on historical data of the individual jobs.

This is the part I'm most concerned about.  The current approach
involves some magic numbers, but they are only there to help approximate
what an appropriate load (or soon memory) for a host might be, and would
be straightforward for an operator to tune if necessary.

Approximating what resources a job uses is a much more difficult matter.
We could have a job which uses 0 nodes and runs for 30 seconds, or a job
that uses 10 nodes and runs for 6 hours collecting a lot of output.  We
could be running both of those at the same time.  Tuning that magic
number would not be straightforward for anyone, and may be impossible.

Automatically collecting that data would improve the accuracy, but would
also be very difficult.  Collecting the cpu usuage, memory consumption,
disk usage, etc, over time and using it to predict impact on the system
is a very sophisticated task, and I'm afraid we'll spend a lot of time
on it.

> Sensors
> ----------
>
> Further different ways of deployment will have different needs about
> the sensors. E.g. the load and ram sensors which utilize load1 and
> memfree won’t work in a kubernetes based deployments as they assume
> the executor is located exclusively on a VM. In order to mitigate I’d
> like to have some generic sensor interface where we also could put a
> cgroups sensor into which checks resource usage according to the
> cgroup limit (which is what we need for a kubernetes hosted zuul). We
> also could put a filesystem sensor in which monitors if there is
> enough local storage. For hooking this into the algorithm I think we
> could start with a single function
>
> def isStatusOk() -> bool

This is a good idea, and I see no reason why we shouldn't go ahead and
work toward an interface like this even with the current system.  That
will make it more flexible, and if we decide to implement a more
sophisticated system like the one described here in the future, it will
be easy to incorporate this.

> Exposing the data
> -------------------------
>
> The window-usage and window-size values could also be exported to
> statsd. This could enable autoscaling of the number of executors in
> deployments supporting that.

I agree that whatever we do, we should expose the data to statsd.

> What are your thoughts about that?

Let me lay out my goals for this:

The governor doesn't need to be perfect -- it only needs to keep the
system from becoming so overloaded that jobs which are running don't
fail due to being out of resources, or cause the kernel to kill the
process.  Ideally an operator should be able to look at a graph and see
that a significant number of executors have gone into self-protection
and stopped accepting jobs, and know that they should add more (or
kubernetes should add more).

I don't want operators to have to tune the system at all.  I'm hoping we
can make this automatically work in most cases (though operators should
be able to override settings if we git the heuristic wrong).  If it
turns out that operators do need to tune something, we should just drop
all of this and expose a 'max jobs' setting -- that would be the easiest
to tune.

Now, aside from not incorporating anything related to RAM into the
current system, the other major deficiency we're dealing with is the
fact that the load average and ram usage are trailing indicators -- it
takes several minutes at least for an increase in usage to be reflected.
Currently, our executors will, even when fully loaded, only wait a few
seconds between accepting jobs.  So we need to slow down the acceptance
rate to allow the indicators to catch up.  Our current plan is to simply
increase the delay between job acceptance proportionate to the number of
jobs we're running.  The slow start and window scaling could help with
that, however, I think we need to focus on that a bit more -- how do we
avoid increasing the window size too quickly, but still allow it to
increase?  That's really a fundamental problem shared by both
approaches.

I'm starting to view the algorithm you describe here as a formalization
of what we're trying to achieve with the current approach.  I think it
can be a good way of thinking about it.

I wonder if we can simplify things a bit by dealing with averages.
Declare that the window is the number of jobs we run at once, then
increase the window if we are at the max and our sensors are all green
for a certain amount of time (minutes?), and as soon as one goes red,
decrease the window.  This way we don't have to estimate the cost of
each job, we just observe the behavior of the system in aggregate.

While we continue to discuss the window approach, I'd also like to
continue to implement the RAM governor, and then also increase the
acceptance delay as load scales.  I think this work will be useful to
build on in the future regardless, and we can hopefully address some
immediate problems and learn more about the behavior.

-Jim


From corvus at inaugust.com  Tue Jan 16 23:39:21 2018
From: corvus at inaugust.com (James E. Blair)
Date: Tue, 16 Jan 2018 15:39:21 -0800
Subject: [OpenStack-Infra] Merging feature/zuulv3 into master
Message-ID: <87po69tlue.fsf@meyer.lemoncheese.net>

Hi,

On Thursday, January 18, 2018, we will merge the feature/zuulv3 branches
of both Zuul and Nodepool into master.

If you continuously deploy Zuul or Nodepool from master, you should make
sure you are prepared for this.

The current version of the single_node_ci pattern in puppet-openstackci
should, by default, install the latest released versions of Zuul and
Nodepool.  However, if you are running Zuul continuously deployed from a
version of puppet-openstackci which is not continuously deployed, or
using some other method, you may find that your system has automatically
been upgraded if you have not taken action before the branch is merged.

Regardless of how you deploy Zuul, if you find that your system has been
upgraded, simply re-install the most current releases of Zuul and
Nodepool, either from PyPI or from a git tag.  They are:

Nodepool: 0.5.0
Zuul: 2.6.0

Note that the final version of Zuul v3 has not been released yet.  We
hope to do so soon, but until we do, our recommendation is to continue
using the current releases.

Finally, if you find this message relevant, please subscribe to the new
zuul-announce at lists.zuul-ci.org mailing list:

http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-announce

Thanks,

Jim


From daragh.bailey at gmail.com  Thu Jan 18 17:12:03 2018
From: daragh.bailey at gmail.com (Darragh Bailey)
Date: Thu, 18 Jan 2018 17:12:03 +0000
Subject: [OpenStack-Infra] Merging feature/zuulv3 into master in Zuul
 and Nodepool repos
In-Reply-To: <1515796963.2999351.1233704024.0A7E95F1@webmail.messagingengine.com>
References: <1515796963.2999351.1233704024.0A7E95F1@webmail.messagingengine.com>
Message-ID: <CACR765_-VGN24LfB+BB=fQotAA-_JmvJ6-ffBM9yjPGE2=KD9Q@mail.gmail.com>

Hi Clark,


You might find the following series of commands help automate this a little
more.

git merge -s ours --no-commit feature/zuulv3
git read-tree -u --reset feature/zuulv3
git commit -m "replace mainline with feature/zuulv3"

Basically it replaces the current branch contents with everything that came
from feature/zuulv3, so no risk that changes get merged at all, whatever
was on the master branch is ignored.

Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool" - unknown

On 12 Jan 2018 22:43, "Clark Boylan" <cboylan at sapwetik.org> wrote:

> Hello,
>
> I think we are very close to being ready to merge the zuulv3 feature
> branch into master in both the Zuul and Nodepool repos. In particular we
> merged https://review.openstack.org/#/c/523951/ which should prevent
> breakages for anyone using that deployment method (single_node_ci) for an
> all in one CI suite.
>
> One thing I've noticed is that we don't have this same handling in the
> lower level individual service manifests. For us I don't think that is a
> major issue, we'll just pin our builders to the nodepool 0.5.0 tag, do the
> merge, then update our configs and switch back to master. But do we have
> any idea if it is common for third part CI's to bypass single_node_ci and
> construct their own like we do?
>
> As for the actual merging itself a quick test locally using `git merge -s
> recursive -X theirs feature/zuulv3` on the master branch of nodepool
> appears to work. I have to delete the files that the feature branch deleted
> by hand but otherwise the merge is automated. The resulting tree does also
> pass `tox -e pep8` and `tox -epy36` testing.
>
> We will probably want a soft freeze of both Zuul and Nodepool then do our
> best to get both merged together so that we don't have to remember which
> project has merged and which hasn't. Once that is done we will need to
> repropose any open changes on the feature branch to the master branch,
> abandon the changes on the feature branch then delete the feature branch.
> Might be a good idea to merge as many feature branch changes as possible
> before hand?
>
> Am I missing anything?
>
> 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/20180118/d5f69dd7/attachment.html>

From cboylan at sapwetik.org  Thu Jan 18 19:48:36 2018
From: cboylan at sapwetik.org (Clark Boylan)
Date: Thu, 18 Jan 2018 11:48:36 -0800
Subject: [OpenStack-Infra] Dublin PTG Brainstorming
Message-ID: <1516304916.2041266.1240185160.3C54CD61@webmail.messagingengine.com>

Hello everyone,

Dublin PTG planning is happening now. Looks like we'll get a shared room with QA, Release, and Requirements Monday and Tuesday acting as a Help Room then have a room for Infra specific things Wednesday to Friday. This is basically what we had in Denver and I think it worked well enough.

I've started an etherpad, https://etherpad.openstack.org/p/infra-rocky-ptg, and stuck it on the appropriate wiki location for brainstorming topics.

One of the things I've written there is ideas on how we might make the help room days more effective. I think with the zuul v3 deployment that we recently did this will be an important couple days for us. I'm open to other ideas that people have for making that more effective so feel free to throw them on the etherpad too.

For the Infra specific days I think writing down topics with an owner worked well in the past, so I think we can start with that this time around as well. I look forward to seeing what you all put down as things we should work on.

Thank you,
Clark


From iwienand at redhat.com  Fri Jan 19 05:08:46 2018
From: iwienand at redhat.com (Ian Wienand)
Date: Fri, 19 Jan 2018 16:08:46 +1100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
 <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
Message-ID: <60565afd-3603-da48-1974-a5d9632e47c2@redhat.com>

On 01/13/2018 03:54 AM, Marcin Juszkiewicz wrote:
> UEFI expects GPT and DIB is completely not prepared for it.

I feel like we've made good progress on this part, with sufficient
GPT support in [1] to get started on the EFI part

... which is obviously where the magic is here.  This is my first
rodeo building something that boots on aarch64, but not yours I've
noticed :)

I've started writing some notes at [2] and anyone is welcome to edit,
expand, add notes on testing etc etc.  I've been reading through the
cirros implementation and have more of a handle on it; I'm guessing
we'll need to do something similar in taking distro grub packages and
put them in place manually.  Any notes on testing very welcome :)

Cheers,

-i

[1] https://review.openstack.org/#/c/533490/
[2] https://etherpad.openstack.org/p/dib-efi


From xinliang.liu at linaro.org  Fri Jan 19 09:36:37 2018
From: xinliang.liu at linaro.org (Xinliang Liu)
Date: Fri, 19 Jan 2018 17:36:37 +0800
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <60565afd-3603-da48-1974-a5d9632e47c2@redhat.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
 <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
 <60565afd-3603-da48-1974-a5d9632e47c2@redhat.com>
Message-ID: <CAGd==044rSi_ZvMfKaMK-j1SnHVadJue0rbCp7YetoFh9gj9wQ@mail.gmail.com>

Hi Lan,

On 19 January 2018 at 13:08, Ian Wienand <iwienand at redhat.com> wrote:
> On 01/13/2018 03:54 AM, Marcin Juszkiewicz wrote:
>>
>> UEFI expects GPT and DIB is completely not prepared for it.
>
>
> I feel like we've made good progress on this part, with sufficient
> GPT support in [1] to get started on the EFI part

Thanks for the patch, great work.
Only one question is that: why just merge gpt into 'vm' rather than
create an new 'block-device-gpt' element?
We then just need to add some partition configuration file into 'vm'
element, like the one you add in test case:
https://review.openstack.org/#/c/533490/10/diskimage_builder/block_device/tests/config/gpt_efi.yaml

>
> ... which is obviously where the magic is here.  This is my first
> rodeo building something that boots on aarch64, but not yours I've
> noticed :)
>
> I've started writing some notes at [2] and anyone is welcome to edit,
> expand, add notes on testing etc etc.  I've been reading through the
> cirros implementation and have more of a handle on it; I'm guessing
> we'll need to do something similar in taking distro grub packages and
> put them in place manually.  Any notes on testing very welcome :)

I think qemu image just need to install grub into /EFI/BOOT/. We can
make it by adding '--removable' option when installing the grub.
See comment here: https://review.openstack.org/#/c/533126/1

Thanks,
Xinliang


>
> Cheers,
>
> -i
>
> [1] https://review.openstack.org/#/c/533490/
> [2] https://etherpad.openstack.org/p/dib-efi
>
>
> _______________________________________________
> 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  Sun Jan 21 16:28:25 2018
From: aj at suse.com (Andreas Jaeger)
Date: Sun, 21 Jan 2018 17:28:25 +0100
Subject: [OpenStack-Infra] Is our testing of nodepool ok?
Message-ID: <33006242-b983-77ca-ac99-d46b7f3b541a@suse.com>


With the merge of Zuulv3 branch of nodepool, we need to rethink our
testing of nodepool.

We currently run on openstack-infra/glean and
openstack/diskimage-builder these jobs:

        - legacy-dsvm-nodepool-redhat-src
        - legacy-dsvm-nodepool-ubuntu-src
        - legacy-dsvm-nodepool-opensuse-src
	- legacy-dsvm-nodepool-debian-src (experimental)

The jobs check out nodepool and shade as well. Those are python 2 jobs
but isn't nodepool python 3 now? Also, nodepool has devstack file, is that

I just pushed https://review.openstack.org/#/c/536135/ to see whether
the jobs still work - only opensuse succeeded, rest failed but didn't
dig into those.

So, my question: Do we test the right thing with these jobs now that
nodepool v3 branch is merged or are changes needed for the setup? And
could somebody check why those two fail?

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 dmsimard at redhat.com  Mon Jan 22 22:12:55 2018
From: dmsimard at redhat.com (David Moreau Simard)
Date: Mon, 22 Jan 2018 17:12:55 -0500
Subject: [OpenStack-Infra] Talks for the Vancouver CFP ?
Message-ID: <CAH7C+Pr8imtJ-N1wdpKKjx8+HQK3e8Oga-ZLv9qVGgPxf0jHDA@mail.gmail.com>

Hi,

Did we want to brainstorm around topics and talks suggestions from an
openstack-infra perspective for Vancouver [1] ?

The deadline is February 8th and the tracks are the following:
- CI / CD
- Container Infrastructure
- Edge Computing
- HPC / GPU / AI
- Open Source Community
- Private & Hybrid Cloud
- Public Cloud
- Telecom & NFV

CI/CD has Zuul and Nodepool written all over it, of course.
FWIW I'm already planning on submitting a talk that covers how a
commit in an upstream project ends up being released by RDO which
includes the upstream Zuul and RDO's instance of Zuul (amongst other
things).

I started an etherpad [2], we can brainstorm there ?

[1]: https://www.openstack.org/summit/vancouver-2018/call-for-presentations/
[2]: https://etherpad.openstack.org/p/infra-vancouver-cfp

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


From marcin.juszkiewicz at linaro.org  Mon Jan 22 22:24:35 2018
From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz)
Date: Mon, 22 Jan 2018 23:24:35 +0100
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <60565afd-3603-da48-1974-a5d9632e47c2@redhat.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
 <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
 <60565afd-3603-da48-1974-a5d9632e47c2@redhat.com>
Message-ID: <511dfe5c-9253-712e-3ef8-5a64d00175a7@linaro.org>

W dniu 19.01.2018 o 06:08, Ian Wienand pisze:
> On 01/13/2018 03:54 AM, Marcin Juszkiewicz wrote:
>> UEFI expects GPT and DIB is completely not prepared for it.
> 
> I feel like we've made good progress on this part, with sufficient
> GPT support in [1] to get started on the EFI part
> 
> ... which is obviously where the magic is here.  This is my first
> rodeo building something that boots on aarch64, but not yours I've
> noticed :)
> 
> I've started writing some notes at [2] and anyone is welcome to edit,
> expand, add notes on testing etc etc.  I've been reading through the
> cirros implementation and have more of a handle on it; I'm guessing
> we'll need to do something similar in taking distro grub packages and
> put them in place manually.  Any notes on testing very welcome :)

> [2] https://etherpad.openstack.org/p/dib-efi

We are now at 5 patch series. Resulting image boots in x86-64 VM using UEFI.

More information at etherpad [2].


From mrhillsman at gmail.com  Tue Jan 23 03:43:03 2018
From: mrhillsman at gmail.com (Melvin Hillsman)
Date: Mon, 22 Jan 2018 21:43:03 -0600
Subject: [OpenStack-Infra] Talks for the Vancouver CFP ?
In-Reply-To: <CAH7C+Pr8imtJ-N1wdpKKjx8+HQK3e8Oga-ZLv9qVGgPxf0jHDA@mail.gmail.com>
References: <CAH7C+Pr8imtJ-N1wdpKKjx8+HQK3e8Oga-ZLv9qVGgPxf0jHDA@mail.gmail.com>
Message-ID: <CAMVtB2G0Z2_Fke0H7MOCBG4XqU30zWohFeWQ1YcyZEjv7PhokA@mail.gmail.com>

I would be willing to do something with a more seasoned Zuul'r (core or ptl
even) around work we are doing in OpenLab; gophercloud + terraform
integration we have already done, work we are doing to add k8s

On Mon, Jan 22, 2018 at 4:12 PM, David Moreau Simard <dmsimard at redhat.com>
wrote:

> Hi,
>
> Did we want to brainstorm around topics and talks suggestions from an
> openstack-infra perspective for Vancouver [1] ?
>
> The deadline is February 8th and the tracks are the following:
> - CI / CD
> - Container Infrastructure
> - Edge Computing
> - HPC / GPU / AI
> - Open Source Community
> - Private & Hybrid Cloud
> - Public Cloud
> - Telecom & NFV
>
> CI/CD has Zuul and Nodepool written all over it, of course.
> FWIW I'm already planning on submitting a talk that covers how a
> commit in an upstream project ends up being released by RDO which
> includes the upstream Zuul and RDO's instance of Zuul (amongst other
> things).
>
> I started an etherpad [2], we can brainstorm there ?
>
> [1]: https://www.openstack.org/summit/vancouver-2018/call-
> for-presentations/
> [2]: https://etherpad.openstack.org/p/infra-vancouver-cfp
>
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
>
> dmsimard = [irc, github, twitter]
>
> _______________________________________________
> 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/20180122/5318e7f7/attachment.html>

From dmsimard at redhat.com  Tue Jan 23 14:58:55 2018
From: dmsimard at redhat.com (David Moreau Simard)
Date: Tue, 23 Jan 2018 09:58:55 -0500
Subject: [OpenStack-Infra] Talks for the Vancouver CFP ?
In-Reply-To: <CAMVtB2G0Z2_Fke0H7MOCBG4XqU30zWohFeWQ1YcyZEjv7PhokA@mail.gmail.com>
References: <CAH7C+Pr8imtJ-N1wdpKKjx8+HQK3e8Oga-ZLv9qVGgPxf0jHDA@mail.gmail.com>
 <CAMVtB2G0Z2_Fke0H7MOCBG4XqU30zWohFeWQ1YcyZEjv7PhokA@mail.gmail.com>
Message-ID: <CAH7C+Po5baq0AK_NYWgGdLf3CqNCrsuG+FeS6zyzeA-FogUZ2A@mail.gmail.com>

On Mon, Jan 22, 2018 at 10:43 PM, Melvin Hillsman <mrhillsman at gmail.com> wrote:
> I would be willing to do something with a more seasoned Zuul'r (core or ptl
> even) around work we are doing in OpenLab; gophercloud + terraform
> integration we have already done, work we are doing to add k8s

I think it would be a great idea to highlight the usage and use cases
of Zuul outside of OpenStack instance itself!
I'd attend a talk like that.

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]


From pabelanger at redhat.com  Tue Jan 23 15:27:20 2018
From: pabelanger at redhat.com (Paul Belanger)
Date: Tue, 23 Jan 2018 10:27:20 -0500
Subject: [OpenStack-Infra] Talks for the Vancouver CFP ?
In-Reply-To: <CAH7C+Pr8imtJ-N1wdpKKjx8+HQK3e8Oga-ZLv9qVGgPxf0jHDA@mail.gmail.com>
References: <CAH7C+Pr8imtJ-N1wdpKKjx8+HQK3e8Oga-ZLv9qVGgPxf0jHDA@mail.gmail.com>
Message-ID: <20180123152720.GB331@localhost.localdomain>

On Mon, Jan 22, 2018 at 05:12:55PM -0500, David Moreau Simard wrote:
> Hi,
> 
> Did we want to brainstorm around topics and talks suggestions from an
> openstack-infra perspective for Vancouver [1] ?
> 
> The deadline is February 8th and the tracks are the following:
> - CI / CD
> - Container Infrastructure
> - Edge Computing
> - HPC / GPU / AI
> - Open Source Community
> - Private & Hybrid Cloud
> - Public Cloud
> - Telecom & NFV
> 
> CI/CD has Zuul and Nodepool written all over it, of course.
> FWIW I'm already planning on submitting a talk that covers how a
> commit in an upstream project ends up being released by RDO which
> includes the upstream Zuul and RDO's instance of Zuul (amongst other
> things).
> 
> I started an etherpad [2], we can brainstorm there ?
> 
> [1]: https://www.openstack.org/summit/vancouver-2018/call-for-presentations/
> [2]: https://etherpad.openstack.org/p/infra-vancouver-cfp
> 
I'd like to see if we can do the zuulv3 workshop again, I think it went well in
Sydney and being the 2nd time around know of some changes that could be made.
Was likely going to propose that.

Another one, we've done in the past, is to give an overview of what
openstack-infra is. Maybe this time around we can discuss the evolution of
becoming a hosting platform with projects like kata and zuul-ci.org.

-Paul


From corvus at inaugust.com  Wed Jan 24 16:33:58 2018
From: corvus at inaugust.com (James E. Blair)
Date: Wed, 24 Jan 2018 08:33:58 -0800
Subject: [OpenStack-Infra] [infra][all] New Zuul Depends-On syntax
Message-ID: <87efmfz05l.fsf@meyer.lemoncheese.net>

Hi,

We recently introduced a new URL-based syntax for Depends-On: footers
in commit messages:

  Depends-On: https://review.openstack.org/535851

The old syntax will continue to work for a while, but please begin using
the new syntax on new changes.

Why are we changing this?  Zuul has grown the ability to interact with
multiple backend systems (Gerrit, GitHub, and plain Git so far), and we
have extended the cross-repo-dependency feature to support multiple
systems.  But Gerrit is the only one that uses the change-id syntax.
URLs, on the other hand, are universal.

That means you can write, as in https://review.openstack.org/535541, a
commit message such as:

  Depends-On: https://github.com/ikalnytskyi/sphinxcontrib-openapi/pull/17

Or in a Github pull request like
https://github.com/ansible/ansible/pull/20974, you can write:

  Depends-On: https://review.openstack.org/536159

But we're getting a bit ahead of ourselves here -- we're just getting
started with Gerrit <-> GitHub dependencies and we haven't worked
everything out yet.  While you can Depends-On any GitHub URL, you can't
add any project to required-projects yet, and we need to establish a
process to actually report on GitHub projects.  But cool things are
coming.

We will continue to support the Gerrit-specific syntax for a while,
probably for several months at least, so you don't need to update the
commit messages of changes that have accumulated precious +2s.  But do
please start using the new syntax now, so that we can age the old syntax
out.

There are a few differences in using the new syntax:

* Rather than copying the change-id from a commit message, you'll need
  to get the URL from Gerrit.  That means the dependent change already
  needs to be uploaded.  In some complex situations, this may mean that
  you need to amend an existing commit message to add in the URL later.

  If you're uploading both changes, Gerrit will output the URL when you
  run git-review, and you can copy it from there.  If you are looking at
  an existing change in Gerrit, you can copy the URL from the permalink
  at the top left of the page.  Where it says "Change 535855 - Needs
  ..." the change number itself is the permalink of the change.

* The new syntax points to a specific change on a specific branch.  This
  means if you depend on a change to multiple branches, or changes to
  multiple projects, you need to list each URL.  The old syntax looks
  for all changes with that ID, and depends on all of them.  This may
  mean some changes need multiple Depends-On footers, however, it also
  means that we can express dependencies is a more fine-grained manner.

Please start using the new syntax, and let us know in #openstack-infra
if you have any problems.  As new features related to GitHub support
become available, we'll announce them here.

Thanks,

Jim


From shrewsbury.dave at gmail.com  Wed Jan 24 20:25:09 2018
From: shrewsbury.dave at gmail.com (David Shrewsbury)
Date: Wed, 24 Jan 2018 15:25:09 -0500
Subject: [OpenStack-Infra] [openstack-dev] [infra][all] New Zuul
	Depends-On syntax
In-Reply-To: <87efmfz05l.fsf@meyer.lemoncheese.net>
References: <87efmfz05l.fsf@meyer.lemoncheese.net>
Message-ID: <CAB91eg7Q0+ALsZc4zsZvCBPR2z8DynB9VF1ESm1NwSzY-58ecw@mail.gmail.com>

This is a (the?) killer feature.


On Wed, Jan 24, 2018 at 11:33 AM, James E. Blair <corvus at inaugust.com>
wrote:

> Hi,
>
> We recently introduced a new URL-based syntax for Depends-On: footers
> in commit messages:
>
>   Depends-On: https://review.openstack.org/535851
>
> The old syntax will continue to work for a while, but please begin using
> the new syntax on new changes.
>
> Why are we changing this?  Zuul has grown the ability to interact with
> multiple backend systems (Gerrit, GitHub, and plain Git so far), and we
> have extended the cross-repo-dependency feature to support multiple
> systems.  But Gerrit is the only one that uses the change-id syntax.
> URLs, on the other hand, are universal.
>
> That means you can write, as in https://review.openstack.org/535541, a
> commit message such as:
>
>   Depends-On: https://github.com/ikalnytskyi/sphinxcontrib-openapi/pull/17
>
> Or in a Github pull request like
> https://github.com/ansible/ansible/pull/20974, you can write:
>
>   Depends-On: https://review.openstack.org/536159
>
> But we're getting a bit ahead of ourselves here -- we're just getting
> started with Gerrit <-> GitHub dependencies and we haven't worked
> everything out yet.  While you can Depends-On any GitHub URL, you can't
> add any project to required-projects yet, and we need to establish a
> process to actually report on GitHub projects.  But cool things are
> coming.
>
> We will continue to support the Gerrit-specific syntax for a while,
> probably for several months at least, so you don't need to update the
> commit messages of changes that have accumulated precious +2s.  But do
> please start using the new syntax now, so that we can age the old syntax
> out.
>
> There are a few differences in using the new syntax:
>
> * Rather than copying the change-id from a commit message, you'll need
>   to get the URL from Gerrit.  That means the dependent change already
>   needs to be uploaded.  In some complex situations, this may mean that
>   you need to amend an existing commit message to add in the URL later.
>
>   If you're uploading both changes, Gerrit will output the URL when you
>   run git-review, and you can copy it from there.  If you are looking at
>   an existing change in Gerrit, you can copy the URL from the permalink
>   at the top left of the page.  Where it says "Change 535855 - Needs
>   ..." the change number itself is the permalink of the change.
>


Is the permalink the only valid format here for gerrit? Or does the fully
expanded link also work. E.g.,

   Depends-On: https://review.openstack.org/536540

versus

   Depends-On: https://review.openstack.org/#/c/536540/

[snip]


-Dave
-- 
David Shrewsbury (Shrews)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180124/0896a768/attachment.html>

From Remo at Italy1.com  Thu Jan 25 21:26:36 2018
From: Remo at Italy1.com (Remo Mattei)
Date: Thu, 25 Jan 2018 22:26:36 +0100
Subject: [OpenStack-Infra] Talks for the Vancouver CFP ?
In-Reply-To: <20180123152720.GB331@localhost.localdomain>
References: <CAH7C+Pr8imtJ-N1wdpKKjx8+HQK3e8Oga-ZLv9qVGgPxf0jHDA@mail.gmail.com>
 <20180123152720.GB331@localhost.localdomain>
Message-ID: <3EE2D0EE-7983-4AFA-99F7-DBE863331D85@Italy1.com>

Hello all to this topic I would like to see if anyone would want to know more how we are now going to be ready to use designate in a ha mode. We have it working with tripleo. 

Thanks. 

Inviato da iPhone

> Il giorno 23 gen 2018, alle ore 16:27, Paul Belanger <pabelanger at redhat.com> ha scritto:
> 
>> On Mon, Jan 22, 2018 at 05:12:55PM -0500, David Moreau Simard wrote:
>> Hi,
>> 
>> Did we want to brainstorm around topics and talks suggestions from an
>> openstack-infra perspective for Vancouver [1] ?
>> 
>> The deadline is February 8th and the tracks are the following:
>> - CI / CD
>> - Container Infrastructure
>> - Edge Computing
>> - HPC / GPU / AI
>> - Open Source Community
>> - Private & Hybrid Cloud
>> - Public Cloud
>> - Telecom & NFV
>> 
>> CI/CD has Zuul and Nodepool written all over it, of course.
>> FWIW I'm already planning on submitting a talk that covers how a
>> commit in an upstream project ends up being released by RDO which
>> includes the upstream Zuul and RDO's instance of Zuul (amongst other
>> things).
>> 
>> I started an etherpad [2], we can brainstorm there ?
>> 
>> [1]: https://www.openstack.org/summit/vancouver-2018/call-for-presentations/
>> [2]: https://etherpad.openstack.org/p/infra-vancouver-cfp
>> 
> I'd like to see if we can do the zuulv3 workshop again, I think it went well in
> Sydney and being the 2nd time around know of some changes that could be made.
> Was likely going to propose that.
> 
> Another one, we've done in the past, is to give an overview of what
> openstack-infra is. Maybe this time around we can discuss the evolution of
> becoming a hosting platform with projects like kata and zuul-ci.org.
> 
> -Paul
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



From gr at ham.ie  Mon Jan 29 16:08:07 2018
From: gr at ham.ie (Graham Hayes)
Date: Mon, 29 Jan 2018 16:08:07 +0000
Subject: [OpenStack-Infra] Talks for the Vancouver CFP ?
In-Reply-To: <3EE2D0EE-7983-4AFA-99F7-DBE863331D85@Italy1.com>
References: <CAH7C+Pr8imtJ-N1wdpKKjx8+HQK3e8Oga-ZLv9qVGgPxf0jHDA@mail.gmail.com>
 <20180123152720.GB331@localhost.localdomain>
 <3EE2D0EE-7983-4AFA-99F7-DBE863331D85@Italy1.com>
Message-ID: <38eeca42-5a68-275a-bcd0-f169607c23b3@ham.ie>

I would - a lot :)

If anyone needs content / ideas for that let me know!

- Graham

On 25/01/18 21:26, Remo Mattei wrote:
> Hello all to this topic I would like to see if anyone would want to know more how we are now going to be ready to use designate in a ha mode. We have it working with tripleo. 
> 
> Thanks. 
> 
> Inviato da iPhone
> 
>> Il giorno 23 gen 2018, alle ore 16:27, Paul Belanger <pabelanger at redhat.com> ha scritto:
>>
>>> On Mon, Jan 22, 2018 at 05:12:55PM -0500, David Moreau Simard wrote:
>>> Hi,
>>>
>>> Did we want to brainstorm around topics and talks suggestions from an
>>> openstack-infra perspective for Vancouver [1] ?
>>>
>>> The deadline is February 8th and the tracks are the following:
>>> - CI / CD
>>> - Container Infrastructure
>>> - Edge Computing
>>> - HPC / GPU / AI
>>> - Open Source Community
>>> - Private & Hybrid Cloud
>>> - Public Cloud
>>> - Telecom & NFV
>>>
>>> CI/CD has Zuul and Nodepool written all over it, of course.
>>> FWIW I'm already planning on submitting a talk that covers how a
>>> commit in an upstream project ends up being released by RDO which
>>> includes the upstream Zuul and RDO's instance of Zuul (amongst other
>>> things).
>>>
>>> I started an etherpad [2], we can brainstorm there ?
>>>
>>> [1]: https://www.openstack.org/summit/vancouver-2018/call-for-presentations/
>>> [2]: https://etherpad.openstack.org/p/infra-vancouver-cfp
>>>
>> I'd like to see if we can do the zuulv3 workshop again, I think it went well in
>> Sydney and being the 2nd time around know of some changes that could be made.
>> Was likely going to propose that.
>>
>> Another one, we've done in the past, is to give an overview of what
>> openstack-infra is. Maybe this time around we can discuss the evolution of
>> becoming a hosting platform with projects like kata and zuul-ci.org.
>>
>> -Paul
>>
>> _______________________________________________
>> OpenStack-Infra mailing list
>> OpenStack-Infra at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180129/59643f9b/attachment.sig>

From Unana.Okpoyo at dell.com  Tue Jan  9 15:00:04 2018
From: Unana.Okpoyo at dell.com (Okpoyo, Unana)
Date: Tue, 09 Jan 2018 15:00:04 -0000
Subject: [OpenStack-Infra] devstack-plugin-vmax-core
Message-ID: <3D7FD0810DD0E04EAB5786711833788B4EEE4B2B@MX202CL01.corp.emc.com>

Hi there,

I am trying to create a pike branch for the devstack-plugin-vmax plugin but am unable to create branches. Could I be given access to be able to do so?
Thanks

Kind Regards,

Unana Okpoyo
Software Senior Engineer
Dell EMC | VMAX_UNISPHERE
phone +353 21 494 6886<tel:353-21-494-6886>
Unana.Okpoyo at Dell.com<mailto:Unana.Okpoyo at Dell.com>

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

From aeng at redhat.com  Wed Jan 10 21:48:53 2018
From: aeng at redhat.com (Alex Eng)
Date: Wed, 10 Jan 2018 21:48:53 -0000
Subject: [OpenStack-Infra] Asking for comments on translate-dev.o.o auth
	table mismatch
In-Reply-To: <efa278c3-181a-48fc-a97e-28374673b078@gmail.com>
References: <a5b15b07-01c0-4f3a-fef3-73cc0d6ec893@gmail.com>
 <CAAZU4v0+JfW4cGPGyC7MTG2TgRcMNJuS6uonyLFZ_+RjtJcreA@mail.gmail.com>
 <efa278c3-181a-48fc-a97e-28374673b078@gmail.com>
Message-ID: <CAA6Xr1SVWkkhsWbdQ=mJXTrDf1=P+7E+9KbMOHWahp5xc-R8+g@mail.gmail.com>

>
> According to his comment, it would be nice if Zanata manages openid full
> url by separating
> into domain part (e.g., "openstackid.org") and rest part (e.g., "/...").
> @Patrick, would it be possible to support in Zanata
> as a new feature?


As much as I would like to solve issue asap, I don't think this is the
right solution.
It is best to handle the URL changes through a script or the jboss-cli.

On Thu, Jan 11, 2018 at 2:08 AM, Ian Y. Choi <ianyrchoi at gmail.com> wrote:

> Hello,
>
> I would like to update this (sorry for my late sharing on this mailing
> list and infra team):
>
> - Jimmy commented on the Etherpad on Dec 13.
>
> According to his comment, it would be nice if Zanata manages openid full
> url by separating
> into domain part (e.g., "openstackid.org") and rest part (e.g., "/...").
> @Patrick, would it be possible to support in Zanata
> as a new feature?
>
> By the way, I18n team decided to have another approach: freshing database
> used in translate-dev.openstack.org,
> which would address current openstackid issues and I18n PTL proposed
> https://review.openstack.org/#/c/531736/ .
> It would be so nice if the patch gets more attention from system-config
> cores.
>
>
> With many thanks,
>
> /Ian
>
> Patrick Huang wrote on 12/6/2017 11:03 AM:
>
>> I've put my comments in the etherpad.
>>
>> On Wed, Dec 6, 2017 at 11:19 AM, Ian Y. Choi <ianyrchoi at gmail.com
>> <mailto:ianyrchoi at gmail.com>> wrote:
>>
>>     Hello,
>>
>>     Since Zanata upgrade to 4.3.1 on translate-dev.openstack.org
>>     <http://translate-dev.openstack.org> is going well [1],
>>     I think it is a good time to discuss translate-dev.o.o
>>     authentication problems.
>>
>>     I wrote a brief current problem on authentication issues in
>>     translate-dev.o.o and my suggestion on proposed solution
>>     :
>>     https://etherpad.openstack.org/p/translate-dev-openstackid-issues
>>     <https://etherpad.openstack.org/p/translate-dev-openstackid-issues> .
>>
>>     Clark looked at this proposal and said that it looked good previously.
>>     It would be so nice if infra team, openstackid developers, I18n
>>     PTL, and Zanata development team
>>     would be in same pages.
>>
>>     In my opinion we can discuss more on for example:
>>     - openstackid developers: How the sync between openstackid-dev and
>>     openstackid databases is accomplished
>>       (regarding password mismatch)
>>     - Sharing Zanata auth table structure from Zanata development team
>>     would be nice.
>>
>>
>>     With many thanks,
>>
>>     /Ian
>>
>>     [1] https://storyboard.openstack.org/#!/story/2001362
>>     <https://storyboard.openstack.org/#%21/story/2001362>
>>
>>
>>
>>
>> --
>> Patrick Huang
>> Senior Software Engineer
>> Engineering - Internationalisation
>> Red Hat, Asia-Pacific Pty Ltd
>> Level 1, 193 North Quay
>> Brisbane 4000
>> Office: +61 7 3514 8278
>> Fax: +61 7 3514 8199
>> IRC: pahuang
>> github: github.com/huangp <http://github.com/huangp>
>> Website: www.redhat.com <http://www.redhat.com>
>>
>
>
>


-- 

ALEX ENG

ASSOCIATE MANAGER

globalization TOOLING, CUSTOMER PLATFORM

Red Hat Inc <https://www.redhat.com/>

193 North Quay, Brisbane City QLD 4000

alex.eng at redhat.com <aeng at redhat.com>    M: 0423353457     IM: aeng
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180110/60c57cd8/attachment.html>

From pahuang at redhat.com  Wed Jan 10 23:56:22 2018
From: pahuang at redhat.com (Patrick Huang)
Date: Wed, 10 Jan 2018 23:56:22 -0000
Subject: [OpenStack-Infra] Asking for comments on translate-dev.o.o auth
	table mismatch
In-Reply-To: <efa278c3-181a-48fc-a97e-28374673b078@gmail.com>
References: <a5b15b07-01c0-4f3a-fef3-73cc0d6ec893@gmail.com>
 <CAAZU4v0+JfW4cGPGyC7MTG2TgRcMNJuS6uonyLFZ_+RjtJcreA@mail.gmail.com>
 <efa278c3-181a-48fc-a97e-28374673b078@gmail.com>
Message-ID: <CAAZU4v27h5ypERcVtfiq5qBz2rPHopGvdzQy7iS+Mb+9+Ef=Mw@mail.gmail.com>

Hi Ian,

Not every openID provider returns the identifier URL in such pattern. In
fact it might not be URL at all (it just need to be unique to that
provider). So technically Zanata won't be able to support the feature you
proposed below.

I think fresh database will work well and easier to implement.

Regards,
Patrick

On Thu, Jan 11, 2018 at 2:08 AM, Ian Y. Choi <ianyrchoi at gmail.com> wrote:

> Hello,
>
> I would like to update this (sorry for my late sharing on this mailing
> list and infra team):
>
> - Jimmy commented on the Etherpad on Dec 13.
>
> According to his comment, it would be nice if Zanata manages openid full
> url by separating
> into domain part (e.g., "openstackid.org") and rest part (e.g., "/...").
> @Patrick, would it be possible to support in Zanata
> as a new feature?


> By the way, I18n team decided to have another approach: freshing database
> used in translate-dev.openstack.org,
> which would address current openstackid issues and I18n PTL proposed
> https://review.openstack.org/#/c/531736/ .
> It would be so nice if the patch gets more attention from system-config
> cores.
>
>
> With many thanks,
>
> /Ian
>
> Patrick Huang wrote on 12/6/2017 11:03 AM:
>
>> I've put my comments in the etherpad.
>>
>> On Wed, Dec 6, 2017 at 11:19 AM, Ian Y. Choi <ianyrchoi at gmail.com
>> <mailto:ianyrchoi at gmail.com>> wrote:
>>
>>     Hello,
>>
>>     Since Zanata upgrade to 4.3.1 on translate-dev.openstack.org
>>     <http://translate-dev.openstack.org> is going well [1],
>>     I think it is a good time to discuss translate-dev.o.o
>>     authentication problems.
>>
>>     I wrote a brief current problem on authentication issues in
>>     translate-dev.o.o and my suggestion on proposed solution
>>     :
>>     https://etherpad.openstack.org/p/translate-dev-openstackid-issues
>>     <https://etherpad.openstack.org/p/translate-dev-openstackid-issues> .
>>
>>     Clark looked at this proposal and said that it looked good previously.
>>     It would be so nice if infra team, openstackid developers, I18n
>>     PTL, and Zanata development team
>>     would be in same pages.
>>
>>     In my opinion we can discuss more on for example:
>>     - openstackid developers: How the sync between openstackid-dev and
>>     openstackid databases is accomplished
>>       (regarding password mismatch)
>>     - Sharing Zanata auth table structure from Zanata development team
>>     would be nice.
>>
>>
>>     With many thanks,
>>
>>     /Ian
>>
>>     [1] https://storyboard.openstack.org/#!/story/2001362
>>     <https://storyboard.openstack.org/#%21/story/2001362>
>>
>>
>
>


-- 
Patrick Huang
Senior Software Engineer
Engineering - Internationalisation
Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8278
Fax: +61 7 3514 8199
IRC: pahuang
github: github.com/huangp
Website: www.redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180110/06964837/attachment.html>

From fjansen at redhat.com  Mon Jan 15 13:11:26 2018
From: fjansen at redhat.com (Frank Jansen)
Date: Mon, 15 Jan 2018 13:11:26 -0000
Subject: [OpenStack-Infra] Adding ARM64 cloud to infra
In-Reply-To: <785fb91c-268b-66f8-2149-a542e57f8228@redhat.com>
References: <ada8008c-0e6a-bd2b-5e25-62900d29da2f@linaro.org>
 <d01a8851-b84c-6dff-ed85-631f4a84e4e4@redhat.com>
 <27918520-279d-08d6-bd4f-3753fa226a84@linaro.org>
 <20180112144939.GA11821@localhost.localdomain>
 <e62cd321-061f-54ac-6e3e-5014a928bd64@linaro.org>
 <20180112155419.ead6msjlbbobup5o@yuggoth.org>
 <bdb02619-b867-2075-1e42-5dc0fd90280e@linaro.org>
 <20180112180134.zdtkmqffvuddb4n4@yuggoth.org>
 <34e8f12e-82bd-5a30-650b-630503f4365a@redhat.com>
 <785fb91c-268b-66f8-2149-a542e57f8228@redhat.com>
Message-ID: <BAB33867-D148-49C4-8883-277E0436F867@redhat.com>

Hi Ian,

do you have any insight into the availability of a physical environment for the ARM64 cloud?

I’m curious, as there may be a need for downstream testing, which I would assume will want to make use of our existing OSP CI framework.

Thanks!

Frank
--------
Frank Jansen
Senior Manager | Quality Engineering
Red Hat, Inc.

> On Jan 15, 2018, at 8:03 AM, Ian Wienand <iwienand at redhat.com> wrote:
> 
> On 01/13/2018 01:26 PM, Ian Wienand wrote:
>> In terms of implementation, since you've already looked, I think
>> essentially diskimage_builder/block_device/level1.py create() will
>> need some moderate re-factoring to call a gpt implementation in
>> response to a gpt label, which could translate self.partitions into a
>> format for calling parted via our existing exec_sudo.
> 
>> bringing up a sample config and test, then working backwards from what
>> calls we expect to see
> 
> I've started down this path with
> 
> https://review.openstack.org/#/c/533490/
> 
> ... still very wip
> 
> -i
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra



From pahuang at redhat.com  Thu Jan 11 00:05:08 2018
From: pahuang at redhat.com (Patrick Huang)
Date: Thu, 11 Jan 2018 00:05:08 -0000
Subject: [OpenStack-Infra] Asking for comments on translate-dev.o.o auth
	table mismatch
In-Reply-To: <9E59F39C-5320-4FFC-B472-8820C49AE73E@openstack.org>
References: <a5b15b07-01c0-4f3a-fef3-73cc0d6ec893@gmail.com>
 <CAAZU4v0+JfW4cGPGyC7MTG2TgRcMNJuS6uonyLFZ_+RjtJcreA@mail.gmail.com>
 <efa278c3-181a-48fc-a97e-28374673b078@gmail.com>
 <CAA6Xr1SVWkkhsWbdQ=mJXTrDf1=P+7E+9KbMOHWahp5xc-R8+g@mail.gmail.com>
 <9E59F39C-5320-4FFC-B472-8820C49AE73E@openstack.org>
Message-ID: <CAAZU4v2xE=DFZdmw7qq1-u2GBNOW-_xaRKnx3ezVxxJsitVmRg@mail.gmail.com>

Not only the password mismatch. The problem is username (among other
things, e.g. the identifier url, name and email, are returned from
openstackId authentication and can be changed by user then saved to Zanata)
has to be unique in Zanata. Since the identifier values come from two
different providers (openstackid and openstackid dev), Zanata will consider
they are two different users. Therefore for the same person, he would have
two users in Zanata with different username. The idea here is to remove the
obsolete user already in the database. Now the new propose is to start with
a fresh database which I think it's much easier.

Regards,
Patrick

On Thu, Jan 11, 2018 at 8:16 AM, Jimmy McArthur <jimmy at openstack.org> wrote:

> Technically those affected users could just update their password on both
> the OpenStackID production and dev sites. Then the problem would be solved.
> I can’t imagine we are talking about that many people that have changed
> their passwords?
>
> Thanks,
> Jimmy McArthur <jimmy at openstack.org>
> 512.965.4846 <(512)%20965-4846>
>
>
> On Jan 10, 2018, at 3:48 PM, Alex Eng <aeng at redhat.com> wrote:
>
> According to his comment, it would be nice if Zanata manages openid full
>> url by separating
>> into domain part (e.g., "openstackid.org") and rest part (e.g., "/...").
>> @Patrick, would it be possible to support in Zanata
>> as a new feature?
>
>
> As much as I would like to solve issue asap, I don't think this is the
> right solution.
> It is best to handle the URL changes through a script or the jboss-cli.
>
> On Thu, Jan 11, 2018 at 2:08 AM, Ian Y. Choi <ianyrchoi at gmail.com> wrote:
>
>> Hello,
>>
>> I would like to update this (sorry for my late sharing on this mailing
>> list and infra team):
>>
>> - Jimmy commented on the Etherpad on Dec 13.
>>
>> According to his comment, it would be nice if Zanata manages openid full
>> url by separating
>> into domain part (e.g., "openstackid.org") and rest part (e.g., "/...").
>> @Patrick, would it be possible to support in Zanata
>> as a new feature?
>>
>> By the way, I18n team decided to have another approach: freshing database
>> used in translate-dev.openstack.org,
>> which would address current openstackid issues and I18n PTL proposed
>> https://review.openstack.org/#/c/531736/ .
>> It would be so nice if the patch gets more attention from system-config
>> cores.
>>
>>
>> With many thanks,
>>
>> /Ian
>>
>> Patrick Huang wrote on 12/6/2017 11:03 AM:
>>
>>> I've put my comments in the etherpad.
>>>
>>> On Wed, Dec 6, 2017 at 11:19 AM, Ian Y. Choi <ianyrchoi at gmail.com
>>> <mailto:ianyrchoi at gmail.com>> wrote:
>>>
>>>     Hello,
>>>
>>>     Since Zanata upgrade to 4.3.1 on translate-dev.openstack.org
>>>     <http://translate-dev.openstack.org> is going well [1],
>>>     I think it is a good time to discuss translate-dev.o.o
>>>     authentication problems.
>>>
>>>     I wrote a brief current problem on authentication issues in
>>>     translate-dev.o.o and my suggestion on proposed solution
>>>     :
>>>     https://etherpad.openstack.org/p/translate-dev-openstackid-issues
>>>     <https://etherpad.openstack.org/p/translate-dev-openstackid-issues>
>>> .
>>>
>>>     Clark looked at this proposal and said that it looked good
>>> previously.
>>>     It would be so nice if infra team, openstackid developers, I18n
>>>     PTL, and Zanata development team
>>>     would be in same pages.
>>>
>>>     In my opinion we can discuss more on for example:
>>>     - openstackid developers: How the sync between openstackid-dev and
>>>     openstackid databases is accomplished
>>>       (regarding password mismatch)
>>>     - Sharing Zanata auth table structure from Zanata development team
>>>     would be nice.
>>>
>>>
>>>     With many thanks,
>>>
>>>     /Ian
>>>
>>>     [1] https://storyboard.openstack.org/#!/story/2001362
>>>     <https://storyboard.openstack.org/#%21/story/2001362>
>>>
>>>
>>>
>>>
>>> --
>>> Patrick Huang
>>> Senior Software Engineer
>>> Engineering - Internationalisation
>>> Red Hat, Asia-Pacific Pty Ltd
>>> Level 1, 193 North Quay
>>> <https://maps.google.com/?q=193+North+Quay+%0D+Brisbane+4000+%0D+Office:+%2B61&entry=gmail&source=g>
>>> Brisbane 4000
>>> Office: +61 7 3514 8278
>>> Fax: +61 7 3514 8199
>>> IRC: pahuang
>>> github: github.com/huangp <http://github.com/huangp>
>>> Website: www.redhat.com <http://www.redhat.com>
>>>
>>
>>
>>
>
>
> --
>
> ALEX ENG
>
> ASSOCIATE MANAGER
>
> globalization TOOLING, CUSTOMER PLATFORM
>
> Red Hat Inc <https://www.redhat.com/>
>
> 193 North Quay, Brisbane City QLD 4000
> <https://maps.google.com/?q=193+North+Quay,+Brisbane+City+QLD+4000&entry=gmail&source=g>
>
> alex.eng at redhat.com <aeng at redhat.com>    M: 0423353457     IM: aeng
> <https://red.ht/sig>
>
>
>


-- 
Patrick Huang
Senior Software Engineer
Engineering - Internationalisation
Red Hat, Asia-Pacific Pty Ltd
Level 1, 193 North Quay
Brisbane 4000
Office: +61 7 3514 8278
Fax: +61 7 3514 8199
IRC: pahuang
github: github.com/huangp
Website: www.redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180111/df89fcee/attachment-0001.html>