ishankhare07
commented
2 years ago These above changes require slight modification in the vcluster-sdk core codebase itself. These would roughly be:
-
This will tap into the correct indices and register them - plugin.go
for _, s := range m.syncers { // Experimental!! // check if syncer.MapperConfig syncerReverseMapper, ok := s.(syncer.ReverseMapper) if ok { reverseMapperConfig := syncerReverseMapper.GetReverseMapper() reverseMapperConfig.ExtraIndices(m.context) } // ------------------------ end of experimental ------------------------ // indexRegisterer, ok := s.(syncer.IndicesRegisterer) if ok { err := indexRegisterer.RegisterIndices(m.context) if err != nil { return errors.Wrapf(err, "register indices for %s syncer", s.Name()) } } } - This will tap and register the required
watchers- syncer.gomapperConfig, ok := r.syncer.(ReverseMapper) if ok { for _, watcher := range mapperConfig.GetWatchers() { controller, err = watcher(ctx, controller) if err != nil { return err } } } - An additional
Interfacethe base implementation for which can possibly be implemented byNamespacedTranslatoritself and hence can remain out of concern of the plugin developer - types.go// Experimental!!! type ReverseMapper interface { GetReverseMapper() MapperConfig GetWatchers() []Watchers }
Problem Statement
The currently operation of vcluster SDK requires plugin developers to implement interfaces like
SyncerandUpSyncerfor their syncers and implement the bahavior of syncing of their particular CRDs.While the directly
SyncedDownroot resources are relatively straight forward to implement for eg.Kservicefrom knative:While this works fine because we can always deterministically calculate the name and namespace for the physical object and add
annotationsorlabelson its creation to map with the corresponding virtual object. The problem quickly arises when a controller acts on one of these CRDs and a new CRD is created by the controller.This new CRD only has the physical object in existence first and a virtual name has to be calculated and from the parent CRDs and accordingly synced to the virtual cluster. This can be demonstrated with the
Config-Revisionrelationship of knative serving module:Here the syncing of
Configobjects is relatively straight forward but because the resultingrevisionobjects a re controller created, they never carry forward the virtual-physical mapping labels. Hence we cannot easily determine a name for the Virtual Object (virtual revision) that the physical one to map to.The typical pattern here is to:
configin this case forrevision)revisionin this case)revisionnumber)Based on this we are able to to calculate a
types.NamespacedNamefor the virtual object and record the right mappings for the same which can be reused further whenver reconcile happens and syncers need to step in for field updated.Current Implementation
The current implementation for this pattern requires the plugin developer to do the following:
Indexerbetween the related resources (pRevision->vRevisionin this case), by overriding thesyncer.RegisterIndicesmethod on the syncer object.Watcheron the parent resource (configin this case) by overriding thesyncer.ModifyControllermethod on the syncer object.revisionmight depend onconfigand also onroutes) then those additional indices and watchers need to be registered in the above functions itself.This design can become cumbersome and buggy very soon, hence we propose to abstract away these details in such a way that:
Proposed Redesign
The way we propose to do this is to have a
MapperConfigstructure in the translator / syncer defined as:With this added our asbtraction boils down to simply calling the method:
Along with this, an additional
nameCacheof the formnameCache map[types.NamespacedName]types.NamespacedNameis proposed that can hold the calculated reverse mappings and be subsequently reused:The user still needs to define:
MapperFuncEnqueuerfuncAs in the previous implmentation as well but now they don't need to register
indicesandwatchersthemselves. For comparision, the code would now become something like:Compared to the previous approach of registering indices and watchers: