[Starlingx-discuss] ceph containerization patch review

Wed Feb 19 08:40:52 UTC 2020

Brent & Bob & Frank,

>From last night's meeting, we discussed lots of ceph containerization issues. We had some progress, but because of the time limitation, I believe we are not fully on the same page of some issues. To have a clear picture of the issues, I'd like to describe these in detail.

Basically there're 2 issues to be addressed,
   1. How to decouple sysinv from rook/ceph?
   2. How to design a storage migration strategy when a user currently running stx 3.0 wants to upgrade to 4.0.

1. How to decouple sysinv from rook/ceph?

In stx 3.0, sysinv is tightly coupled with ceph by communicating with python-cephclient. The original idea from Tingjie's BP[0] is to replace python-cephclient by python-rookclient, without changing the current logic of ceph configuration.

The decoupling of sysinv and rook/ceph was mentioned in containerize meeting[1] on Jan 14th and Martin(Haochuan) is not in that meeting. To let folks have a clear view, I have some questions about decoupling:

  a. When talking about decoupling, does it mean all the ceph configuration would only be set through overrides generated by sysinv helm plugin?
  b. Does sysinv storage command like host-stor-*/storage-tier-* deprecated along with its sysinv conductor code after rook enabled?
  c. Can a sysadmin operate rook without sysinv overrides? If so, how to guarantee the previous restrictions of storage policy/rules, like 3 monitors, like osds not locates on worker node.
  d. Back to sysinv overrides, what's the mechanism of generating runtime overrides to add an osd or a node or change crushmap rules to the ceph cluster? Through customer override?
  e. Is a command line tool other than cgcs-client needed for sysadmin(if sysinv conductor is not involved)? I believe the command line is more friendly than writing a yaml type override to update ceph cluster.
  f. What role starlingx plays in storage management? To perform easier integration of rook and let rook manages storage, or to be the manipulator of rook?

2. How to design a storage migration strategy when a user currently running stx 3.0 wants to upgrade to 4.0.

We do face this question about how to migration current ceph to rook. However we don't think it blocks the previous issue that the users install stx4.0 from scratch doesn't encounter migration issue. I prefer addressing these 2 issues independently.

I think the migration strategy is not an easy implementation because it's about the safety of customer's data. We'd like to follow a standard procedure from upstream to lower the risk of migration failure. Unfortunately, we haven't seen a best practice from rook community yet.

To continue this work, I would like to align with you about some points:
- All the services using ceph should be down during the migration.
- The daemons of ceph running on host will be removed after migration.
- What's the interface of migration? A tool or a script or instructions documented?
- The implementation of migration should not go along with rook-ceph application.

I described the 2 major issues in detail in current ceph containerization task for Martin's reference. Hopefully my questions could be addressed by WR folks to make our communication more effective and efficient.

Tingjie, please correct me if I have some misunderstandings since you are the first prim of ceph containerization who knows the full context well.

[0] https://opendev.org/starlingx/specs/src/branch/master/doc/source/specs/stx-3.0/approved/containerization-2005527-containerized-ceph-deployment-and-provision.rst
[1] http://lists.starlingx.io/pipermail/starlingx-discuss/2020-January/007485.html

Mingyuan

From: Chen, Haochuan Z <haochuan.z.chen at intel.com>
Sent: Wednesday, February 19, 2020 12:57
To: Miller, Frank <Frank.Miller at windriver.com>; 'starlingx-discuss at lists.starlingx.io' <starlingx-discuss at lists.starlingx.io>; Rowsell, Brent <Brent.Rowsell at windriver.com>; Greg.Waines at windriver.com
Cc: Chen, Tingjie <tingjie.chen at intel.com>; Sun, Austin <austin.sun at intel.com>; Qi, Mingyuan <mingyuan.qi at intel.com>; Church, Robert <Robert.Church at windriver.com>
Subject: RE: ceph containerization patch review

After helm install, you can assign label to nodes,  "ceph-mon-placement=enabled", "ceph-mgr-placement=enabled"
Then pod with ceph-mon and ceph-mgr will deploy on the label assigned node.

Martin, Chen
IOTG, Software Engineer
021-61164330

From: Chen, Haochuan Z
Sent: Wednesday, February 19, 2020 12:53 PM
To: 'Miller, Frank' <Frank.Miller at windriver.com<mailto:Frank.Miller at windriver.com>>; 'starlingx-discuss at lists.starlingx.io' <starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>>; Rowsell, Brent <Brent.Rowsell at windriver.com<mailto:Brent.Rowsell at windriver.com>>; 'Greg.Waines at windriver.com' <Greg.Waines at windriver.com<mailto:Greg.Waines at windriver.com>>
Cc: Chen, Tingjie <tingjie.chen at intel.com<mailto:tingjie.chen at intel.com>>; Sun, Austin <austin.sun at intel.com<mailto:austin.sun at intel.com>>; Qi, Mingyuan <mingyuan.qi at intel.com<mailto:mingyuan.qi at intel.com>>; Church, Robert <Robert.Church at windriver.com<mailto:Robert.Church at windriver.com>>
Subject: RE: ceph containerization patch review

Hi folks

Answer the question, with only k8s, how to deploy rook.

$ helm-upload stx-platform rook-ceph-0.1.0.tga
$ helm install stx-platform/rook-ceph -n rook-ceph-cluster -n kube-system -f value.yaml

BR!

Martin, Chen
IOTG, Software Engineer
021-61164330

From: Miller, Frank <Frank.Miller at windriver.com<mailto:Frank.Miller at windriver.com>>
Sent: Tuesday, February 18, 2020 10:06 PM
To: Chen, Haochuan Z <haochuan.z.chen at intel.com<mailto:haochuan.z.chen at intel.com>>; 'starlingx-discuss at lists.starlingx.io' <starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>>; Rowsell, Brent <Brent.Rowsell at windriver.com<mailto:Brent.Rowsell at windriver.com>>
Cc: Chen, Tingjie <tingjie.chen at intel.com<mailto:tingjie.chen at intel.com>>; Sun, Austin <austin.sun at intel.com<mailto:austin.sun at intel.com>>; Qi, Mingyuan <mingyuan.qi at intel.com<mailto:mingyuan.qi at intel.com>>; Church, Robert <Robert.Church at windriver.com<mailto:Robert.Church at windriver.com>>
Subject: RE: ceph containerization patch review

+Bob who is the containers TL

From: Chen, Haochuan Z [mailto:haochuan.z.chen at intel.com]
Sent: Monday, February 17, 2020 8:46 AM
To: Miller, Frank <Frank.Miller at windriver.com<mailto:Frank.Miller at windriver.com>>; 'starlingx-discuss at lists.starlingx.io' <starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>>; Rowsell, Brent <Brent.Rowsell at windriver.com<mailto:Brent.Rowsell at windriver.com>>
Cc: Chen, Tingjie <tingjie.chen at intel.com<mailto:tingjie.chen at intel.com>>; Sun, Austin <austin.sun at intel.com<mailto:austin.sun at intel.com>>; Qi, Mingyuan <mingyuan.qi at intel.com<mailto:mingyuan.qi at intel.com>>
Subject: RE: ceph containerization patch review

Hi Frank & Brent

For rook manage configuration, after introduce rook-ceph, current ceph cluster deployed by puppet will keep or be removed?
If removed, containerized ceph cluster deployed by rook-ceph will take the role of provisioner for stx-openstack.
If keeps, helm chart rbd-provisioner in platform-integ-app also keeps and takes the role of provisioner for stx-openstack. Containerized ceph cluster deployed by rook-ceph only serve as csi provider for k8s.

BR!

Martin, Chen
IOTG, Software Engineer
021-61164330

From: Chen, Haochuan Z
Sent: Monday, February 10, 2020 11:47 PM
To: Miller, Frank <Frank.Miller at windriver.com<mailto:Frank.Miller at windriver.com>>; 'starlingx-discuss at lists.starlingx.io' <starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>>
Cc: Chen, Tingjie <tingjie.chen at intel.com<mailto:tingjie.chen at intel.com>>; Sun, Austin <austin.sun at intel.com<mailto:austin.sun at intel.com>>; Qi, Mingyuan <mingyuan.qi at intel.com<mailto:mingyuan.qi at intel.com>>
Subject: RE: ceph containerization patch review

Hi Frank:

As synced with Tingjie, this is my understanding for Rook manage the configuration instead of sysinv.

1, Remove ceph config and status query from sysinv
2, create another tool, like rook-client to launch and provision ceph cluster
3, one helm plugin like rbd-provision, which depends on newly created tool

BR!

Martin, Chen
IOTG, Software Engineer
021-61164330

From: Miller, Frank <Frank.Miller at windriver.com<mailto:Frank.Miller at windriver.com>>
Sent: Saturday, February 8, 2020 4:16 AM
To: Chen, Haochuan Z <haochuan.z.chen at intel.com<mailto:haochuan.z.chen at intel.com>>; 'starlingx-discuss at lists.starlingx.io' <starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>>
Subject: RE: ceph containerization patch review

Martin:

Thanks for posting your reviews and the update on the current status for this feature.

I was unable to attend the containerization meeting this week so wasn't able to have Tingjie or you give an update on the open actions for the feature.  From the Jan 14 minutes [1] one of the actions is to determine "how can you have Rook do all the configuration and not have sysinv involved"

For now I suggest you add an additional item to your Tasks to do list to identify a design that does not require sysinv for the configuration and instead has Rook manage the configuration.  I would like to ask that we discuss further at the next containerization meeting and if possible review a proposal from yourself and Austin for this item.

Frank
[1] https://etherpad.openstack.org/p/stx-containerization

From: Chen, Haochuan Z [mailto:haochuan.z.chen at intel.com]
Sent: Thursday, February 06, 2020 11:02 PM
To: 'starlingx-discuss at lists.starlingx.io' <starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>>
Subject: [Starlingx-discuss] ceph containerization patch review

Hi folks

I enabled containerized ceph cluster with simplex. You can begin to review my patch. I propose to build an image and deploy a simplex system with these patch to check.

https://review.opendev.org/#/c/681457/<https://review.opendev.org/>
https://review.opendev.org/#/c/687340/<https://review.opendev.org/>
https://review.opendev.org/#/c/706256/<https://review.opendev.org/>
https://review.opendev.org/#/c/699557/<https://review.opendev.org/>
https://review.opendev.org/#/c/699556/<https://review.opendev.org/>

And I know there is other story, like remove ceph as default backend storage, maybe some conflict, we can discuss together.

Tash Done:
1, disable native ceph cluster in ceph.pp
2, disable ceph daemon monitoring in service manager
3, add rook-ceph helm chart to launch ceph cluster
4, add override in stx-config to generate override with starlingx system config
5, sysinv add label in provision stage, to make containerized ceph mon and ceph mgr on designed host
6, add rook-ceph-provisioner helm chart to generate storage class, secret, config and pool for stx-application
7, enabled stx-openstack with containerized ceph
8, update ceph wrapper in stx-config to set or get containerized ceph cluster

All these tasks done is enabled with simplex only.

Task to do:
1,  enable add osd runtime, after system provisioned
2, fix know issue, if system reboot, ceph cluster launch fail
3, enable bluestore and filestore, currently there is only bluestore
4, enable multi-node and duplex
5, enable swift with containerized ceph
6, enable fm alarm for containerized ceph
7, check backup and restore for containerized ceph
8, check system upgrade or how to transit from native ceph cluster to containerized ceph cluster
9, code cleanup
10, update unit test in stx-config

BR!

Martin, Chen
IOTG, Software Engineer
021-61164330

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20200219/bfb47cc2/attachment-0001.html>