Move configSecretName key

[asymmetric]

If my interpretation of the rationale behind the Habitat type is correct, the spec.service field should only be used for flags passed to the supervisor binary.

It follows then that the configSecretName key shouldn't be there.

Is it worth it to move it elsewhere (e.g. one level up)? Or am I being pedantic? 😂

[krnowak]

I'm trying to think with my "spanning ring" hat on here. At some point I will want to add something to the manifest. Basically a bunch of ports that would be opened on the cluster:

• one for SWIM/gossip communication between supervisors inside and outside the cluster
• zero or more ports for service specific needs

This normally would be solved with the k8s Service resource, like we currently do in some examples. But I wanted to add separate fields for the ports in the manifest, because this information needs to be passed to the supervisor too. It would have a double purpose and that would make the ports to fit neither category of fields, I think.

In general, I think that categorization of the fields based on whether this stuff is passed to habitat via flags or not is rather arbitrary. I mean - what do we do with those fields is an implementation detail, no? If we want to categorize the fields, I suppose it should be based on functionality. Something like:

• setup:
  • image
  • count
• runtime
  • env
  • ring key
  • group
  • topology
  • config secret name
  • bind
  • persistent storage
  • name
  • channel

So, I dunno. Maybe just flattening all this would be best… OTOH, setup could serve as a dumping ground for some k8s specific stuff if we ever will need to add something (like image pull policy, which we didn't add in the end), and runtime - for habitat specific stuff. But not sure where the port fields for spanning ring would fit into this picture.

So, you wanted my opinion so there you have it. :)