Comments (6)
This is off the top of my head, and I think bringing in @viovanov would be useful too…
- It might be better to actually bake multiple-container support into fissile, rather than doing it as sidecar containers, to be more obvious what's going on. Essentially, only
name
,description
, andtags
(maybetype
?) would apply to the whole role… Not sure yet, though.- If you're worried about sharing containers between roles, YAML has anchors and things that should make that easier to deal with (but internally fissile would just see them as copies).
- The type of resource to create (statefulset vs deployment) would be the same for all containers… and we currently based that on volumes and tags. I think this would be the thing that determines which path we go down: what happens if the sidecar looks like it needs to be a statefulset, but the main role doesn't?
- Would it make sense to have a new volume type (where we currently have
persistent-volumes
andshared-volumes
)?
from fissile.
Thanks for your feedback. We went through your points and compared it to our thoughts on the topic. We see four main topics at the moment:
- Name/class of the issue
- YAML structure/configuration
- Resource type (StatefulSet vs Deployment)
- Volumes
Name/class of the issue
You are right, just naming it sidecar
does not fully reflect the container co-location. It is more like that sidecar
could be one of the flavours of that co-location of containers in pods. Maybe we start to call it either multi-container support, or container co-location in a pod.
YAML structure
We played around with different ideas on where to place it and to find reasons for and against different approaches. We strongly see the container co-location configuration on the same level as the current roles (bosh, bosh-task, docker?). A second (or third, ...) container in a pod is on the same level as the first one in the eyes of Kube. So putting the configuration nested into an existing role feels not right from a model kind of view. We played with the idea of configuring it in a role and using YAML anchors, but it looked kind of wrong at the end, especially since the co-located container configuration does include more than just a name, and description. It actually is pretty much the same amount like a current role. One other idea was to introduce a new root level key for the "roles" that only serve as co-location containers, but that felt like overkill.
Resource Type
Here we thought about that if one container of the pod is stateful and therefore requires a StatefulSet as its Kube form, it will become a StatefulSet even if the other container does not require that.
Volumes
There are multi-container in pod scenarios where you just want to share a directory between containers without the need to have a volumes claim, e.g. the emptyDir
example. However, the current state of fissile with shared-volumes
and persistent-volumes
always create the volume claim section and that's why we suggested the emptyDir
key as an addition. It would be also fine to introduce a whole new <some-suitable-name>-volumes
key for the role.
Like suggested in the Slack channel, a meeting would be nice to talk about this.
from fissile.
Hi! Thanks for the (much more detailed than what I wrote) response!
The reason I was thinking of putting the container stuff inside the role is because I was mentally thinking of the role as the pod level construct (so having more containers in there is actually closer to the kube view); I can totally understand that if the role maps instead to a container the sidecar style matches better.
In case it wasn't clear: I'm totally not against the proposal, I'm just bouncing idea around to help me understand things
Thanks again!
from fissile.
@mook-as I admit, our comment became a bit bigger than initially intended. Your feedback was very helpful for us to revisit everything we thought to have thought through. And that's why we figured it might be helpful to just write everything down in a hopefully organized way in preparation for the meeting this week.
from fissile.
Some notes after the call with @viovanov, @HeavyWombat.
YAML Structure
The role
block should support two features(aka keys):
- existing
type
should support thecollocated-container
type. This will indicate that the role will never generate a helm template/pod, but its configuration will be used to inject a second container inside another role. - new key
extra-pod-containers
. A list of existing roles of they typecollocated-container
, that are intended to be place in this role as secondary containers.
Resource type
Master node have priority and collocated containers cannot be stateful. This should be checked through a sanity check.
Volumes
We need a new feature to specify that we want to share directories between containers that not necessarily be persistent volumes. In other words: We need a way to specify we want Kube's emptyDir
feature.
from fissile.
@viovanov @mook-as We finished a first draft of the proposal including all the sanity-checks we discussed so far. This does not include the volumes yet. We wanted to touch base with you about feedback at the current stage and if that matches your assumptions.
Update: We added the emptyDir
volume support as well as the promised sanity check that a role of type colocated-container
does not have tags that would make it stateful.
from fissile.
Related Issues (20)
- [question] do you have a plan to support the Cloud Foundry releases for this? HOT 1
- [WIP] Dockerfile for Fissile build
- Unauthorized HOT 6
- fissile does not build HOT 1
- Walkthrough manifests are unusable HOT 3
- New compilation cache code creates broken archives
- Update dependencies once mholt/archiver#92 has landed HOT 1
- Pod runtime information is in a non-sensical spot HOT 2
- add pre-built binaries to github releases? HOT 1
- `fissile diff` only works with already unpacked release directories and not with URLs
- Race condition for active/passive pods when no leader is available HOT 4
- Example doc for build in configuration.md is wrong (create-release.sh not found) HOT 1
- Deployment fails on clusters with containerd when credentials are empty HOT 6
- Role manifest shared volume validation bug HOT 1
- Services generated by fissile make Istio malfunction HOT 2
- Move to Go Modules HOT 1
- Generated K8s resources will not be supported in K8s 1.16
- docker run example for nats-release fails: cannot access '/usr/local/bin/create-release.sh': No such file or directory HOT 7
- Cut releases with release notes? HOT 3
- Why not create docker images from rev releases?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fissile.