3lang: tfgrid: define actions and do the implementation

[MarioBassem]

Issue: https://github.com/threefoldtech/web3_proxy/issues/94

[MarioBassem]

@brandonpille i think we can do both, customizable and simple, and it should still be easy to use. for the actions part, if this is the users gateway to deploying stuff, then the options are many. so i need to know which solutions would be exposed. right now we have solutions for deploying:

• machines
• kubernetes clusters
• gateways
• discourse
• funkwhale
• peertube
• presearch
• zdbs
• taiga
• machine with a mounted qsfs

[brandonpille]

@brandonpille i think we can do both, customizable and simple, and it should still be easy to use. for the actions part, if this is the users gateway to deploying stuff, then the options are many. so i need to know which solutions would be exposed. right now we have solutions for deploying:

• machines
• kubernetes clusters
• gateways
• discourse
• funkwhale
• peertube
• presearch
• zdbs
• taiga
• machine with a mounted qsfs

Eventually all should be possible. So we can already start defining the actions

[brandonpille]

@robvanmieghem what do you mean by have main as default instead of tgrid.main?

[robvanmieghem]

@brandonpille Don't call the action tfgrid.main to indicate mainnet but a grid property for example that deploys to mainnet by default if not specified.

[brandonpille]

@brandonpille Don't call the action tfgrid.main to indicate mainnet but a grid property for example that deploys to mainnet by default if not specified.

Ah yes makes sense! Or I would introduce an action load or keys where you put your mnemonic or seed and where you can add the grid property too.

[robvanmieghem]

a separate action with tfgrid.settings does make sense, it's better than a property on every action. It's context, which might be provided in a different way too. It's also meant to be usable in wiki's and the main story states "when info needs to requested, it will just return json formatted info"

[MarioBassem]

i added some code, it should be a bit more clear now how parsing works.

[brandonpille]

i added some code, it should be a bit more clear now how parsing works.

Can you first define the actions in a markdown file? It's not a good idea to start the implementation if the input is not yet known. Let's define the input first, provide some examples. After that we can start the implementation.

[MarioBassem]

i added some code, it should be a bit more clear now how parsing works.

Can you first define the actions in a markdown file? It's not a good idea to start the implementation if the input is not yet known. Let's define the input first, provide some examples. After that we can start the implementation.

@Omarabdul3ziz and i udpated the parser.md file, and added tfgrid actions' docs here

[MarioBassem]

@Omarabdul3ziz and i were discussing some specifications about 3lang, and we had some questions:

• Will the md files contain more than one action, or just one action per document?
• If there are multiple actions per file, should the actions be processed in any particular order?
  • Currently for the tfgrid, only actions per project are processed in order, but there is no guarantee which project will be processed first
• For the 3lang parser, how should the output be formatted?
  • If there is only one action per file, then we could just return the result of this action
  • If there are multiple actions, then a format should be documented since there could also be multiple modules performing these actions.

[MarioBassem]

i resolved some comments, commented on some others. i'll just work on the machines with gateways solution to allow updates, then add the appropriate documentation for it

[brandonpille]

i resolved some comments, commented on some others. i'll just work on the machines with gateways solution to allow updates, then add the appropriate documentation for it

Alright thanks! Could you also check why CI is red?

[MarioBassem]

@Omarabdul3ziz and i did the required refactoring for the tfgrid actions. we had some remarks, which may or may not be important, but here they are anyway:

• in the proposed version of the parser here , the actions are run in a specific order defined only by us. i don't know if this a desired behavior, but at least we need to know which actions to do before which. and as @brandonpille suggested, we believe it's best to execute them one by one, and let the user be responsible of the ordering of the actions.
• in the proposed version of the parser here, arguments are not used, and instead parameters with 'yes' or 'no' values are used. we didn't really get why, but if arguments are well documented, shouldn't a flag, or an argument in our case, be enough?
• in the proposed version of the parser here, a vm name is provided while creating a set of machines in the same network. if the desired behavior here is to deploy a number of vms with the same name, this would be prone to error as there is no guarantee that each vm will be deployed on a distinct node. if this is a problem, maybe we should randomly create vm names, or else restrict users to deploying single machines at a time and let them provide names as they want?

regardless of the remarks above, we did the refactoring as proposed for most of the basic tfgrid, but i think it would be useful to get some feedback on this before continuing

[MarioBassem]

resolved @brandonpille latest comments in https://github.com/threefoldtech/web3_proxy/pull/132

[robvanmieghem]

I understand this PR is about 3lang for tfgrid and the implementation requires tfgrid to be implemented. The examples are not just 3lang in this PR but also tfgrid solutions but those are not documented in the manual

[robvanmieghem]

Do want all solution structs and definitions like peertube and funkwhale to be directly in the threefoldtech.threebot.tfgrid module in the v client? Same for the serverside go package.

[brandonpille]

solutions

I think they are. Look under manual/src/threelang/tfgrid

[brandonpille]

Do want all solution structs and definitions like peertube and funkwhale to be directly in the threefoldtech.threebot.tfgrid module in the v client? Same for the serverside go package.

What do you mean? Do you want all structs and definitions under lib/tfgrid?

[MarioBassem]

solutions

I think they are. Look under manual/src/threelang/tfgrid

actually these are the docs for the old examples, they're there but they still need to be updated. will update them.

[robvanmieghem]

Do want all solution structs and definitions like peertube and funkwhale to be directly in the threefoldtech.threebot.tfgrid module in the v client? Same for the serverside go package.

What do you mean? Do you want all structs and definitions under lib/tfgrid?

It was a question, I misformulated it ( should have been "Do we want"). I actually don't like it all flat in the root tfgrid module/package. Off course, this does not mean that 3lang ( which is an easy to use intermediate language) should follow the same naming as the modules/packages do.

[robvanmieghem]

solutions

I think they are. Look under manual/src/threelang/tfgrid

Well, the non 3lang examples/tfgrid have been heavily modified while the non 3lang manual is not.

[brandonpille]

Do want all solution structs and definitions like peertube and funkwhale to be directly in the threefoldtech.threebot.tfgrid module in the v client? Same for the serverside go package.

What do you mean? Do you want all structs and definitions under lib/tfgrid?

It was a question, I misformulated it ( should have been "Do we want"). I actually don't like it all flat in the root tfgrid module/package. Off course, this does not mean that 3lang ( which is an easy to use intermediate language) should follow the same naming as the modules/packages do.

Where else woudl you put it?

[brandonpille]

Oh I see. @MarioBassem can you make sure that the documentation on the tfgrid examples is up to date?