You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, OAM looks very promising. We are into something very similar in my organisation.
I hope we will be able to contribute on the OAM and some implementations of it.
I am creating this issue in order to ask for some more details on how some use cases should be handled from an "operational" point of view. Let me be more specific:
My question is on how this would be reflected from a developer point of view in a ComponentSchematic? Indeed using a S3 in ApplicationConfiguration would then required to have the proper library in the code to handle S3 API.
From my understanding, developers should be only writing ComponentSchematic and ApplicationConfiguration can eventually be handled by some operators. Therefore what property would reflect the usage of an S3 bucket in a ComponentSchematic?
I am sorry if the answer to my question could be obvious, but I only went around OAM spec and Rudr implementation details only a couple of days ago. So I may surely have missed something.
P:S: the Story thing is very nice ❤️in order to have very concrete examples to wrap the one head around.
Cheers!
The text was updated successfully, but these errors were encountered:
@AdrienFromToulouse welcome! Just to clarify, the dependency story docs you read are part of a larger discussion that hasn't actually made into the spec yet on how to handle dependencies between components and other resources or external services. This is probably something we can include in the roadmap discussion as well (#229).
So you're understanding is correct that users only author ComponentSchematics and ApplicationConfigurations at this point. The question you're getting at is - I think - when it comes to external dependencies like S3 buckets or a managed Redis service from a cloud provider, can those be modeled some way in OAM?
Our initial take on this is in the ComponentSchematic as an extended workload type. At this stage it is very immature. Right now it just lets an implementation define a completely custom workload with a set of key-value parameters to configure it. There isn't much structure to it, and no way to define dependencies yet. Any ideas here are certainly welcome!
Got it. After reading in your comment ComponentSchematic as an extended workload type
then I realised that I missed the Component: Mysql -> **Workload**: Mysql in the Google Doc. Makes sens. I better understand now.
Hi there,
First of all, OAM looks very promising. We are into something very similar in my organisation.
I hope we will be able to contribute on the OAM and some implementations of it.
I am creating this issue in order to ask for some more details on how some use cases should be handled from an "operational" point of view. Let me be more specific:
In the following document, the story 2 (Claiming static resource) mentions about a web app for which the dependency is a S3 bucket:
https://docs.google.com/document/d/1TSr6eHWz5g-uA5-M4e9MKty_Lvuyl0liS7YihFjKnPY/edit
My question is on how this would be reflected from a developer point of view in a
ComponentSchematic
? Indeed using a S3 inApplicationConfiguration
would then required to have the proper library in the code to handle S3 API.From my understanding, developers should be only writing
ComponentSchematic
andApplicationConfiguration
can eventually be handled by some operators. Therefore what property would reflect the usage of an S3 bucket in aComponentSchematic
?I am sorry if the answer to my question could be obvious, but I only went around OAM spec and Rudr implementation details only a couple of days ago. So I may surely have missed something.
P:S: the
Story
thing is very nice ❤️in order to have very concrete examples to wrap the one head around.Cheers!
The text was updated successfully, but these errors were encountered: