Conversation
Take over already existing application description data model. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
|
How are the png drawings created? I worry without the source it's an additional item that will need to be maintained when a change impacts any element. |
|
Looking at commit d5e85be, the data model seems to be a group of isolated classes. But looking at the details lots of commonalities can be identified. We have in fact many different places defining the same type of data! Consolidation is needed and will follow in posterior commits in this PR.
|
As of now, I'm using LinkML to generate PlantUML code, which I manually send to a PlantUML server to generate the PNGs. But that's just WIP for the time being. Before the PR is marked as ready for merging, I need add code to automatically generate the diagrams in SVG format, validate the examples and provide the JSON-Schemas for validation. |
|
@ajcraig @nilanjan-samajdar @singhmj-1 this is still a draft, not ready for review! Therefore I've removed all reviewers. Sorry, I've created it initially as "Ready to merge" and you probably got therefore a notification. |
|
Once it's ready for review, I'll ask any contributor to the different parts covered by the data model to review it and some specification maintainers. |
Cleanup tailing whitespaces. Remove `rank` attributes, only needed for serialization sorting that will come later and probably require some changes. Make `kind` attribute a "type designator", meaning that its value is at the same time the designator of the class in the data model. Add application description validation examples Add application description class diagram Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Take over already existing desired state (AKA ApplicationDeployment) data model. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Remove `rank` attributes, only needed for serialization sorting that will come later and probably require some changes. Make `kind` attribute a "type designator", meaning that its value is at the same time the designator of the class in the data model. Add desired state validation examples Add application deployment class diagram Rename desired state to application deployment In order to keep consistency at data model level, renaming desired state to application deployment. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Add DesiredStateManifest data model, examples and class diagram. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Add DeviceCapabilities data model, including examples and a class diagram. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Computing resources are defined in an application description, device capabilities and the derived OpenAPI specification. This patch consolidate them all in a single place. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
d5e85be to
aa9371a
Compare
Definition of requirements for deployments (ApplicationDescription) and requesting a deployment (ApplicationDeployment specifying the desired state) have a lot of commonalities, this patch consolidates the relevant classes. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
69989a7 to
4d2c376
Compare
|
@Silvanoc,
|
I'm working on it. The generation of the All other parts of the OpenAPI specification would be provided externally and they are simply appended programatically. But my intention is to have a LinkML generator that takes two arguments (at least):
The generator makes sure that any resource referenced in the |
Yes, for other elements of the OpenAPI/Swagger, maybe we can keep a template yaml that the LinkML generator uses. |
|
Data model currently looks so: The only thing that hasn't been generated with LinkML are the dashed lines. Because the references use "hidden" IDs (see #161) that cannot be natively modeled with LinkML. |
b4c6983 to
5367f5f
Compare
Combine all the individual data models into a unified data model for the whole Margo specification. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Validate the examples against the LinkML data model. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Add tool to generate JSON-Schemas to validate instances of the top-level data types: - ApplicationDeployment - ApplicationDescription - DesiredStateManifest - DeviceCapabilities Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Add tool that creates a class diagram in SVG format that shows all data types involved in the Margo specification. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Add DeploymentStatus and ComponentStatus missing in the data model. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Add class-relationships that cannot be modelled with LinkML and add possibility to generate multiple class-focused diagrams. Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
5367f5f to
856b95a
Compare
Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
|
@Silvanoc I misread one of your comments yesterday and took this out of draft. After realizing my mistake, I put it back as a draft. |
|
@Silvanoc / @ajcraig - I have mixed feelings about this. Having a single source of truth is very helpful, but I'm concerned about the complexity this is introducing and the risk of someone accidentally missing something. This raises the bar for contributions quite high, with all the additional stuff someone will need to understand, instead of creating a simple markdown page. I like what this enables, but I think we'll need to figure out some way of managing this so we're not causing people to not be able/or want to contribute because of this additional overhead. |
As can be seen nicely in the data model graphs above, we already do have that complexity and it's likely to even more increase rather than decrease., i.e., there is this complexity (already now) and it's not going to go away. This is not introducing complexity but a means to tame the existing (and growing) complexity into a coherent and consistent single source of truth – which is really needed as the PlugFest has shown where we uncovered (very) small inconsistencies here and there that in sum break the whole thing. We cannot hide complexity, it's there, and trying hiding even parts of it makes it overall an inconsistent mess. The only question IMO is what is the right tooling to help us managing that complexity?
This is actually prevented by having rigor here.
Granted, this needs to be made as convenient as possible with automation and tooling. |
@stormc the complexity I was refering too is more on the tooling side. Contributors will need to learn how to use LinkML, Jinja, understand all the bash and Python scripts, and all the templates. If they want to make an update, they'll need to figure out a bunch of files that need to be updated and checked. If they want to create a new page, it's going to be even more complex. I acknowledge the need for something to keep all the content consistent, but unless we do something to help make creating and updating content easier, there is a good chance we'll see even fewer contributions. So, whether we have a small team of people that are available to help take someone's markdown and update all these files, or introduce some tooling or AI to make the process easier, we'll need to do something, I think. |
If you have to fully understand all the gory details of this, then the automation/tooling is insufficient. You will have to follow some (probably extra) steps, granted, but that shouldn't force you to understand the whole machinery. It will be a process getting to this stage, but I do not see an alternative to be honest.
Fully agree. We need tooling, good tooling, that doesn't stand in between you and contributing, quite the opposite. |

Description
Provide a comprehensive data model
This PR does not change the specification at all. In fact it does not even change the generation of any artifacts yet. Those changes should be part of following PRs.
Issues Addressed
#150
Change Type
Please select the relevant options:
Checklist