Questions related to ongoing architectural changes for extensibility

39 views
Skip to first unread message

Pablo Chacin

unread,
Jan 21, 2019, 1:58:51 PM1/21/19
to gardener
Greetings

My apologies for a long and dense message, I hope this is the best channel for asking the questions below. 

A PR was recently submitted [1]  introducing some of the changes for improving Gardener's extensability, as described in [2]

I have some questions related to these ongoing work:

1. What time frame do you envision this transition to happen, on which all the platform-specific components are externalized from the "core" gardener? 
This is important as there's some ongoing work for using SUSE Linux as a platform for shoot cluster nodes, and it would be interesting to integrate it into
the future architecture, but it will depend on the timeframe for this transition to occur. 

2. Related to the extensibility proposal in [2] I have some doubts about the proposed management of controller's life-cycle as I mentioned in  [3]
Which is the best way to move this discussion forward?  As a PR over the extensibility proposal? As a topic in the community meeting? 

3. In the last community meeting there was a presentation about out of tree machine-controllers  [4] How is it related to [1]? My initial impression is that

vasu 1124

unread,
Jan 24, 2019, 10:40:23 AM1/24/19
to gardener

Hi Pablo,

 

Let me try to be concise and short, even though your questions might elicit a long answer.

 

regarding #1: for our next community meeting I asked that we give an insight to where we are in the extensibility target. Optimistically, the implementation should be doable by Q2. But we invite hands-on feedback from partners who ideally can report from real experiences with the current implementation of Gardener [1]. I think the Kubernetes journey for out-of-tree cloud controllers also took longer. It is a difficult decision to make. On the one hand, you want to start with the new design, but it’s not there yet. On the other hand, you want to articulate and influence the new design, but for that you need at least an experimental in-tree implementation.

 

regarding #2: I think the best way is indeed an agenda item in the community meeting. Overall, I understood that you are addressing what we suggested under the “gardenlet” [2]. In essence, the central Gardener is using the seed clusters for “dumb” execution. By switching the operator into the seed, and with the cluster-api spec standardized, the central Gardener can instead just multiplex the cluster order to a system that fulfills the request. And the latter could be Gardener operator (or CaaSP).

 

regarding #3: machine-controller is indeed independent. It actually is the best showcase of the extensibility design we have in mind.

 

BR Vasu

 

[1] https://github.com/gardener/gardener/blob/master/docs/development/new-cloud-provider.md

[2] https://github.com/gardener/gardener/blob/master/docs/proposals/01-extensibility.md#gardenlet

Pablo Chacin

unread,
Jan 24, 2019, 1:24:15 PM1/24/19
to gardener
Hi Vasu

Thank you for your detailed answer and for promoting this point in the next community meeting.

Regarding the Gardenlet, I think it is an step towards the idea I suggested but if I understand it well, 
as happens  with the kubelet the gardenlet still has a strong master-slave relationship with the garden
cluster.

For example, shoots are created in the garden cluster, and also operators are registered in the garden
cluster. These actions are propagated to the seed cluster. This separation of control puzzles me because 
Seed looks  devoid of most logic and requires the Garden to accomplish its duties.  

Please correct me if I'm understanding incorrectly the architecture in [1]. For instance, the scope of the Seed API. 

I was suggesting an step towards a more independent relationship by putting the registry of operators 
as part of a seed api. Eventually, the shoot operations should also happen there. I would envision the
possibility of launching a Seed cluster and be able to manage shoot clusters in a very rudimentary way
just by using its API. 

The Garden could then be considered as a higher level of management in terms of sophistication. I understand
this is possibly a major departure from the original Gardener's paradigm, but I think is one that makes more appealing
the project for mid-sized deployments which is the target I'm particularly interested. 

I'm looking forward for continuing this conversation either by this mean of any other you consider more convenient.

Reply all
Reply to author
Forward
0 new messages