[Discussion] BMI Re-designing

[apoorvemohan]

New BMI Requirements:

• Standalone BMI deployment (flat network).
• Multi-tenant BMI deployment (shared network).
• Add authentication module for multi-tenant deployments (verify if the node belongs to the user who requested the operation - drivers should be written for each auth type - in our current setup HIL is used for node authentication).
• Network Isolation Operations should be performed by user instead of BMI.
• Making BMI modular - any components on which BMI depends should be replaceable (to change datastore, provisioning system, node authentication etc.).

BMI's Capabilities:

• BMI is a bare-metal provisioning and image management solution and should perform/expose operations/APIs pertaining to that.

[apoorvemohan]

@ravisantoshgudimetla we can continue our discussion here.

[naved001]

I am mostly happy with the new ideas except for the multi-tenant BMI.

Multi-tenant BMI deployment (shared network).

We already do this and we know it's not safe to have a shared provisioning network. Since we are redesigning this I think we should focus on coming up with ways to avoid sharing a network.
If we do it the right way (which I don't know yet), then we would not have to worry about authentication because if nodes are not sharing a network we can't provision them anyway. I had a chat with @okrieg and he mentioned that this is not a good idea.

Network Isolation Operations should be performed by user instead of BMI.

If I remember correctly, @ravisantoshgudimetla had strong opinions that BMI should be doing this? Can you tell us what those are since we are discussing it here.

Making BMI modular - any components on which BMI depends should be replaceable (to change datastore, provisioning system, node authentication etc.).

Absolutely, in fact there's an open PR #95 that started the work on this. I can pick up on it and push more commits to it to make it ready to merge.

[apoorvemohan]

@naved001

I had a chat with @okrieg and he mentioned that this is not a good idea.

The new proposal is no different (as insecure) from the current implementation. Can you setup a meeting (regarding the security aspect) when Orran is back? I think I have some ideas about this and would like to discuss them.

Absolutely, in fact there's an open PR #95 that started the work on this. I can pick up on it and push more commits to it to make it ready to merge.

In order to make BMI code modular, we will need to rewrite most of the code - I am not sure how much of such refactored code can we re-use.

[pgrosu]

@henn also had some suggestions.

[chemistry-sourabh]

@apoorvemohan we don't need to rewrite most of the code for the modular thing. We just need to establish interfaces and implement driver loading.

Also we need to establish terminologies to avoid confusion. ( Remember the project/user argument?)

[apoorvemohan]

we don't need to rewrite most of the code for the modular thing. We just need to establish interfaces and implement driver loading.

@chemistry-sourabh Currently there are too many hard-coding's for different components (HIL, Ceph, etc.). Also, the current interfaces and code does not entirely support multi-tenancy. I think simply redefining the interfaces might not be sufficient. If we try to change the interface based on the current code then either we might end up compromising modularity or we will eventually end-up re-writing the code (but will take way more time). So I think the easiest and the fastest way would be to re-define the interfaces and write the code from scratch against them (instead of modifying existing code for the new interfaces).

Also we need to establish terminologies to avoid confusion. ( Remember the project/user argument?)

Yes we need to (re)define the terminology carefully.

[chemistry-sourabh]

@apoorvemohan I still don't see a need to rewrite the entire code. For the multi tenancy thing we need to update the iscsi server to support multi vlan and update the iscsi driver to accept an additional network parameter. We already have a network parameter in the pro call so no need to change anything in Picasso side.

Modularity is easy to do as I thought about it and wrote code accordingly. multi tenancy will need some work in the iscsi section thats it. We will be able to reuse most of the code.

Let me know if I missed anything.

[chemistry-sourabh]

Related to #99

[ravisantoshgudimetla]

I agree with @chemistry-sourabh, we need to refactor code and moving functions here and there.

[apoorvemohan]

We already have a network parameter in the pro call so no need to change anything in Picasso side.

The current implementation/abstractions are based on HIL terminology. E.g. Network name, project name etc. All such calls/functions needs to be made more generic (independent of HIL).

Modularity is easy to do as I thought about it and wrote code accordingly. multi tenancy will need some work in the iscsi section thats it. We will be able to reuse most of the code.

There is much more to modularity than just using different software iSCSI implementations. Components like data store, authentication service, provisioning service (something other than iSCSI) etc. needs to be modular. I don't think that simply moving functions here and there can make BMI modular.

Having said all of this, there are many more things are yet to be discussed.

[ravisantoshgudimetla]

There is much more to modularity than just using different software iSCSI implementations. Components like data store, authentication service, provisioning service (something other than iSCSI) etc. needs to be modular. I don't think that simply moving functions here and there can make BMI modular.

So, I guess you are talking about the discussion that we had offline couple of weeks ago @apoorvemohan. While I agree with approach which is modular, it doesn't need a complete rewrite is what I think.

Also, I want to get this discussion started with what pieces BMI should comprise of. For example:

• An Image management service(For various operations like clone, create etc).
• Image exposure service.(For exposing the image to node using various protocols like iSCSI, nfs etc).
• Discovery service.(For discovering various objects available in the system like images etc ).
• An object store(For storing meta-data related to objects like images, snapshots etc).

The above are the things that I could think of and we can add more.

What we need is an orchestrator piece, the one that is currently in operations.py which will drive all these services.

[chemistry-sourabh]

Aren't image management service and object store same in our case ?

[ravisantoshgudimetla]

Aren't image management service and object store same in our case ?

Nope, what I meant by object store is a database kind of system to store meta-data. I should have been clear on that. Let me update the comment.