ibaldin
commented
3 years ago 2 has been addressed in #11
Closed ibaldin closed 3 years ago
ibaldin
commented
3 years ago 2 has been addressed in #11
ibaldin
commented
3 years ago for 3 it is true that Shared vs SmartNIC types are the only ones that share a model and a special model name can stand in as a proxy for type. I don't think eliminating type completely is a good idea, but for add component removing it is certainly possible. @paul-ruth
ibaldin
commented
3 years ago for 1 there is already an init.py under fim/user that renames a bunch of things. We can create another package that starts with fabric. namespace but it would be fake and just import from other packages. I would not be in favor of deep renaming of existing packages at this point as that naming serves multiple purposes. 'fim' is shorter to spell than 'fabric', and at this point all users need to import is fim.user they can do import fim.user as exp and have the same effect as above.
I suggest we wait a little bit until the client side API for CF also stabilizes - it may make sense at this point to create a meta package that imports from FIM and from CF client APIs to create a single point of import for experimenters. That package (via imports from other packages) can unify credential handling, FIM and CF API under one roof for experimenters.
ibaldin
commented
3 years ago Bullet 1 will be addressed via ticket https://github.com/fabric-testbed/software-planning/issues/35
ibaldin
commented
3 years ago Bullet 1 has been addressed.
[x] 1. Consider naming the packages from the user's perspective. The users will think in terms of "experiments", "topologies", "nodes", "links", etc.. Naming the API "fabric-information-model" focuses on how we are implementing the API and not how the users will interact with it. The user tools for creating topologies should be called something like "fabric-toolkit" or just "fabric". Then the import in the python could be "import fabric.experiment as exp" or "import fabric-toolkit.experiment" and used like "t = exp.topology()"
[x] 2. Can the name of the components be re-used across different nodes? I'm thinking that maintaining unique names across a large experiment may be an unnecessary difficulty. For example, if you have a bunch of nodes with a single nic each you might want them all called "nic1" or "eth0" or something like that. Also, you might have a pattern like all your nodes have there gpu called "gpu1".
[x] 3. In add_component the user needs to supply the component type and the model. The type is redundant and will only lead to confusion/errors. It seems that the type is mostly needed to specify if a component on a connectx-6 card is shared or not. To the user, a shared nic and a full nic are just different models of nic. It does not matter that the nics are supported by a physical card that is the same model.
I really think the shared nic idea should be merged with nic and we should add a nic model called "ConnectX-6-sriov-vf" or something like that. If we really want to shared nics to be first-level different types then we should try to hide that from the user. If the api only required a model name (regardless of type) then system could find that model and set the type with out the user needing to know about it. This would also be true for other types like FPGA, GPUs, etc.
@paul-ruth