Shuicheng, thank you.  I tend to agree with you that Option 2 is the way to go, but I have some questions that maybe you or someone else in the community can answer.

· Do we know how long it will take CentOS to produce the RPM on Train’s Keystone?

· Do we know if the Stein Keystone is compatible with Train?

· How did we handle this in the past?

· Why do we need CentOS to provide an RPM?  Can we make our own from upstream Train sources?

      brucej

From: Lin, Shuicheng
Sent: Monday, September 23, 2019 6:44 PM
To: starlingx-discuss@lists.starlingx.io; Jones, Bruce E <bruce.e.jones@intel.com>; Hu, Yong <yong.hu@intel.com>
Subject: About task "update keystone on the host from the SRPM" of Openstack Train

Hi all,

There is a task 36619 [0] “update keystone on the host from the SRPM” of story 2006544 “Integrate with OpenStack Train (master)”.

Due to Train is not released yet, and it will take sometime for CentOS to support Train and provide the SRPM.

We have two option as below. And I prefer Option 2, since host keystone is to serve flock service, not OpenStack service.

Please help provide your suggestion.

Thanks in advance.

Option 1:

To catch stx 3.0 release, we need switch SRPM to use upstream git directly.

Advantage:

Host keystone will align with containerized keystone.

Disadvantage:

A few keystone related packages need switch from SRPM to git repository.

Other rpms may need be upgraded also if they have dependency on keystone.

Option 2:

We defer the upgrade task to stx 4.0, wait until SRPM is available in CentOS mirror.

Advantage:

Follow current design, and related packages could be upgraded easily together.

Disadvantage:

Host keystone will differ from containerized keystone.

Not sure when CentOS will provide SRPM for Train.

[0]: https://storyboard.openstack.org/#!/story/2006544

Best Regards

Shuicheng