Open surajssd opened 7 months ago
Xynnn007
commented
7 months ago I agree. A whole thing makes it easy to deploy, but KBS/AS should involve much duplication and couple things. Micro services makes it easier to use the concrete components separately in different scenarios and also helps decouple in KBS and AS API design. For example we might not need register_reference_value() for AS and set_policy() for KBS.
mkulke
commented
7 months ago As a counterpoint: having a self-contained binary + flat config file contributes to a good developer ux. If there is an option to keep that option, that would be good. It doesn't need to be the prescribed or reference method.
surajssd
commented
7 months ago As a counterpoint: having a self-contained binary + flat config file contributes to a good developer ux. If there is an option to keep that option, that would be good. It doesn't need to be the prescribed or reference method.
But we have the docker-compose for that, no?
fitzthum
commented
7 months ago I am hesitant about removing the built-in support. First, I agree that we want an easy developer experience. Personally I think Docker compose is pretty easy, but I suspect there are people who are going to want to build everything locally without a container. You can build the microservices approach this way, but it's more complex to configure. I think it's reasonable to a simple (conceptually and practically) version.
More importantly, I think some people might want to avoid the complexity that the microservices approach introduces, In particular having components talk to each other over the network increases the attack surface of the KBS/AS. Here's one example of how that could possibly be an issue.
@surajssd are there other issues you have run into besides https://github.com/confidential-containers/kbs/issues/310? When it comes to the RVPS I think the reality is that the component is not very mature. @Xynnn007 has done a great job to create a couple possible flows but we still have a long way to go in terms of understanding how people want to use the component and how it should be implemented. I think the solution to something like #310 is to work more on the RVPS rather than to just stop supporting it in the configurations that we haven't happened to implement yet.
mkulke
commented
7 months ago As a counterpoint: having a self-contained binary + flat config file contributes to a good developer ux. If there is an option to keep that option, that would be good. It doesn't need to be the prescribed or reference method.
But we have the docker-compose for that, no?
locally maybe. what I mean is, a self-contained kbs can be deployed into an environment with kubectl deploy --image ghcr.io/bla/kbs:something if you have to orchestrate several containers to iterate/test changes, it will slow down your debug cycle (at least for me). what I predict from a mandatory microservice soup, is that folks (me) end-up not bothering how to actually deploy this anymore and just let stuff run on the CI which is a big hit on velocity.
bpradipt
commented
7 months ago Sometimes a monolith is a better choice than microservices based approach ;)
surajssd
commented
7 months ago Generally, with focusing only on making developer experience better, the user experience tends to get neglected.
And developer experience is generally what gets tested as well in CI or locally because that's what devs are comfortable with. Then we start seeing such regressions only when a user files an issue.
I don't want to slow down anybodys' debug cycle but at the same time if our test cycles (local or in CI) are divergent from what people will be using then we are creating less productive solution overall. Users will always be playing catch-up.
Ultimately if running KBS and related components on k8s is the key then we should get rid of the docker-compose approach and only support doing local development and k8s.
Three different ways to do things, one of the two will always suffer.
bpradipt
commented
7 months ago @surajssd we should update the CI to add both the cases - all-in-one image with features built-in as well as the micro-services approach. Built-in also has advantages in some cases w.r.to packaging and shipping. Right now I don't think we have enough insights to decide one way or the other. My suggestion will be to use both the approaches, include it in the CI/CD pipeline and take a call after few releases of what makes sense.
fitzthum
commented
7 months ago I think this test already tests the built-in AS (without any containers).
I agree that it's too early to know what users really want.
Xynnn007
commented
7 months ago Nice conversation. Let me take back my original words. To me the core problem is RVPS. Currently the only API not exposed by KBS is RVPS'. @lmilleri also once raised this in https://github.com/confidential-containers/kbs/issues/310#issue-2110486044. To me, RVPS is still an abstract/developing module to work with software supply chain, which is not mature, so it might not be a great issue. Even if its API is not exposed, we can also use the policy to reach the same goal, by configuring the reference values manually. Before RVPS implements deterministic semantics and functionality, it would be ok to keep as-is, s.t. both mono service and micro service.
About RVPS, @thomas-fossati has raised some great ideas and we have discussed some interesting ideas. The work would be carried on. Let's go and see.
Right now, with KBS we support two modes where the AS and KBS runs in one container. But it is becoming evident that some services cannot be cramped into one container, for e.g. RVPS.
I think we should abandon the single container approach and start supporting all microservices with each process running in its own container. This two-approach support is causing greater confusion.
Related: https://github.com/confidential-containers/kbs/issues/310