Hi Bruce,

Please check my inline comments.

Best Regards

Shuicheng

From: Jones, Bruce E <bruce.e.jones@intel.com>
Sent: Wednesday, September 25, 2019 4:07 AM
To: Lin, Shuicheng <shuicheng.lin@intel.com>; starlingx-discuss@lists.starlingx.io; Hu, Yong <yong.hu@intel.com>
Subject: RE: About task "update keystone on the host from the SRPM" of Openstack Train

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?

[shuicheng] Per history of Stein and Rocky, it is about 1 month after OpenStack’s release date.

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

[shuicheng] I assume Host keystone (Stein) should have no communication with OpenStack(Train). Please correct me if it is wrong.

• How did we handle this in the past?

[shuicheng] Based on git history, we always use SRPM/RPM from CentOS for keystone.

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

[shuicheng] We could do it. Option 1 is to use upstream keystone code directly.

                      The risk is other dependent packages may need be upgraded together.

                                    For Option 2, CentOS help handle the dependency.

      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