Skip to content
This repository was archived by the owner on Nov 9, 2022. It is now read-only.
This repository is currently being migrated. It's locked while the migration is in progress.

Changes to the StorageOSCluster CR get applied to StorageOS#336

Merged
croomes merged 4 commits intomasterfrom
mutate-cm
May 24, 2021
Merged

Changes to the StorageOSCluster CR get applied to StorageOS#336
croomes merged 4 commits intomasterfrom
mutate-cm

Conversation

@croomes
Copy link
Contributor

@croomes croomes commented May 20, 2021

Previously the StorageOSCluster CR was treated as immutable. With this change, a user can modify settings in the CR spec and those changes will get passed to StorageOS.

Some configuration items at set via an API call to the StorageOS control plane API. Others are set in a ConfigMap that is passed to the node container as env vars. Items that are configured via the API are also set in the ConfigMap once they have been successfully applied.

The control plane determines which configuration items can be updated at run-time, with a restart, or not at all.

@croomes croomes requested review from Arau, avestuk, darkowlzz and mhmxs May 20, 2021 18:25
Copy link
Contributor

@mhmxs mhmxs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small

return fmt.Errorf("failed to get storageos status: %v", err)
}
if status.Phase != storageosv1.ClusterPhaseRunning {
return fmt.Errorf("storageos api not ready, retrying")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

errors.New does the same but in more efficient way.

configmap := &corev1.ConfigMap{}
err := cm.client.Get(context.TODO(), cm.NamespacedName, configmap)
return configmap, err
if err := cm.client.Get(context.TODO(), cm.NamespacedName, configmap); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it is out of the scope of the change, but are we able to replace TODO or we really don't know what to do with context here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it would be better to pass in a proper context, but this is a wider change to do consistently. The k8s client function signature changed and this is in keeping with the existing code. I'd prefer to leave as-is for now and we can do a follow-on PR if needed.

if logErr != nil {
t.Error(errors.Wrap(logErr, "failed to fetch operator logs"))
}
t.Log(logs)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to Log first and than check logErr, because for me looks more readable if Error and Fatal appear at the end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to leave the Fatal at the end as it exits, but I'm re-arranged to try and make it more readable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perfect i just say:

t.Log(logs)
if logErr != nil t.Error(errors.Wrap(logErr, "failed to fetch operator logs"))
t.Fatal(err)

Because Error doesn't stops execution.

Timeout: HTTPTimeout,
Transport: transport,
}
config.HTTPClient = httpc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason that you assign &http.Client{} to httpc first?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, well spotted!

func (s *Deployment) ensureConfigMap() error {
config := configFromSpec(s.stos.Spec, CSIV1Supported(s.k8sVersion))

labels := make(map[string]string)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's going on here?

It looks like the call to s.k8sResourceManager.ConfigMap(configmapName, s.stos.Spec.GetResourceNS(), labels, config).Get() calls ResourceManager.combineLabels() which creates a new map and combines the ResourceManager.Labels with the labels that are passed in.

Would passing in nil risk causing an explosion later because we'd instantiate r with a nil map for it's labels?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be just fine to pass nil. The checks are handled internally.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, combineLabels checks for nil and returns r.labels, which is never nil since it's set in the constructor. So passing in nil is ok, and it would be safe to remove labels := make(map[string]string). I'd prefer to keep it as I think it makes it more clear that we don't want to set specific labels.

// dynamically via the API.
if existing != nil {
// Don't update if unchanged.
if reflect.DeepEqual(config, existing) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can a map[string]string and *v1.ConfigMap ever be deeply equal? Would you not need to turn the configMap into a map in order to compare them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doh! Very well spotted. It needs to compare with existing.Data. I'm adding a unit test for the function...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So that test became a bit more involved than I expected...

@croomes croomes force-pushed the mutate-cm branch 4 times, most recently from 775765d to 937b81e Compare May 21, 2021 20:53
Copy link
Contributor

@darkowlzz darkowlzz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!
A lot of detailed tests. Thanks.

@croomes croomes merged commit 3193990 into master May 24, 2021
@croomes croomes deleted the mutate-cm branch May 24, 2021 13:44
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants