Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Choose refacto of brick precedence #137

Open
3 tasks
arthur91f opened this issue May 1, 2023 · 3 comments
Open
3 tasks

Choose refacto of brick precedence #137

arthur91f opened this issue May 1, 2023 · 3 comments
Labels
question Further information is requested refactoring
Milestone

Comments

@arthur91f
Copy link
Owner

arthur91f commented May 1, 2023

We have to choose an algo for brick deploying order:
Today we have choose one but I challenge that vision:

  • the actual vision : parent-relative priorization ou no depth perception priorization
  • the layer number vision : where two super-bricks or rooms can be deployed in in the same time
  • the savage vision : where directory numbers are ignored in first place, they just have to be valid with a valid sequence according to deps

The problem is that we have to choose between

  • the agility of the code and the fact that you want organize it in a functional way.
  • the transparency of the precedence.
@arthur91f arthur91f added this to exeIaC Apr 30, 2023
@arthur91f arthur91f converted this from a draft issue May 1, 2023
@arthur91f arthur91f added enhancement New feature or request good first issue Good for newcomers labels May 1, 2023
@arthur91f arthur91f added this to the alpha milestone May 1, 2023
@arthur91f
Copy link
Owner Author

arthur91f commented Jun 25, 2023

What is a brick layer ?
It's the number of the brick directory seprate by dot.
infra-ground/2-envs/1-production/3-database -> 1.2.1.3

TOTHINK
We can have multiple order of brick layer. So we have to think and choose one solution

  • be able to compare layer of different order 1.3 to 1.3.2.4.1 and 1.3 to 1.3.1 (prefered)

  • search the max order we have and replace 1.3 by 1.3.0.0

  • define a max order of 8 or 16 and replace 1.3 by 1.3.0.0.0.0.0.0

  • [] replace or not the ending 0 when you display

TODO:

  • a) Let room define their brick layer (one order)
  • b) At brick creation add the field layerNumber
  • c) Add a function to order a list according to brick layer
  • d) CreateInfra should modify the brick order
    It should be all : the other brick comparison shouldn't change as it will still be based on the abitrary right brick order defined by createInfra.
    Check if it changes something in the algorythme of functions that search dependencies and linked in bricks.

@arthur91f
Copy link
Owner Author

To don't do: we want to keep the brick unit. It's less agile but we can't know what is the layer of brick in other room or in other super brick.

If we want to keep agility we can say that exeiac find its own order without regarding directory number. And then check if the directory order is valid.

@arthur91f arthur91f changed the title Give layer number to brick to define their precedence Choose refacto of brick precedence Jun 25, 2023
@arthur91f arthur91f added question Further information is requested refactoring and removed enhancement New feature or request good first issue Good for newcomers labels Jun 25, 2023
@arthur91f
Copy link
Owner Author

To add agility we can add access-brick with a suffix or a seccond prefix They can make bridge between two rooms

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested refactoring
Projects
Status: Todo
Development

No branches or pull requests

1 participant