Skip to content
This repository has been archived by the owner on Apr 27, 2022. It is now read-only.

Architectural changes discussion #99

Closed
naved001 opened this issue Apr 5, 2017 · 10 comments
Closed

Architectural changes discussion #99

naved001 opened this issue Apr 5, 2017 · 10 comments

Comments

@naved001
Copy link
Contributor

naved001 commented Apr 5, 2017

BMI architectural changes

@apoorvemohan and I had some discussions about BMI's structure.

Remove BMIs dependency on a network isolator like HIL.

  • This way BMI becomes standalone, and we need not worry about making it pluggable, or supporting various network isolators. So this is how it goes in my head; the user reserves some node using whatever network isolator he has, and then he uses BMI to provision it, so if the user is reserving node he might as well just connect the networks too.

  • This way we can still use BMI as a global provisioning system. A user can attach/remove his nodes to a global BMI provisioning network.

Support more diskless provisioning techniques.

  • Currently, we only support iSCSI which has its pros and cons. We should support other techniques like NFS-root, ceph fs, etc.

Let us know in the comments section below @CCI-MOC/bmi-breakers

@naved001 naved001 added this to the BMI Refatoring milestone Apr 5, 2017
@naved001
Copy link
Contributor Author

naved001 commented Apr 5, 2017

@knikolla would appreciate your thoughts on this

@chemistry-sourabh
Copy link
Contributor

#40 @ravisantoshgudimetla will object to this :P, also this wont prevent BMI from being pluggable, we will still need to make it pluggable for supporting The second part.

The second part is not clear to me. Instead of serving through iscsi, but directly contact ceph or NFS ? Ceph part sort of makes sense, but what about NFS ? where will the image come from ceph again ?

Also why do we want to support more provisioning techniques wont that be a different project altogether ? Like I guess Ironic only does copying the disk right ? It doesnt do iSCSI or something (Correct me if I am wrong ).

I would suggest extending support to more iscsi variants and FSs as that will allow more people to use it.

@ravisantoshgudimetla
Copy link
Contributor

@naved001 Can you explain what you mean by provision here. I mean, series of steps that provision would do?

This way we can still use BMI as a global provisioning system. A user can attach/remove his nodes to a global BMI provisioning network.

If BMI has to pxe boot a node, it has to be part of some network and booting every node through this global network is a security concern.

Currently, we only support iSCSI which has its pros and cons. We should support other techniques like NFS-root, ceph fs, etc.

I think, we can try doing that but iSCSI is something that we are much more comfortable with. We can create a back log card or project for this on github and come back later,

@apoorvemohan
Copy link
Collaborator

@ravisantoshgudimetla:

If BMI has to pxe boot a node, it has to be part of some network and booting every node through this global network is a security concern.

If a user needs to provision his nodes - he can either use a public BMI service (that he trusts) or can deploy his own BMI. BMI will have the capability to be deployed in 2 modes (1. Stand-alone and 2. Multi-tenant). For mode 2 deployment, we will have an Auth driver loaded in BMI that for security purpose.

I think, we can try doing that but iSCSI is something that we are much more comfortable with. We can create a back log card or project for this on GitHub and come back later.

Yes, this is a later task. But now that we are considering a refactoring of BMI, we should design a pluggable BMI that reconsiders all the decisions that were taken when developing BMI for the first time.

@ravisantoshgudimetla
Copy link
Contributor

ravisantoshgudimetla commented Apr 6, 2017

If a user needs to provision his nodes - he can either use a public BMI service (that he trusts) or can deploy his own BMI.

So, BMI always was thought to be a provisioning engine for a project. Not sure, why we want to support stand-alone use-case now.

BMI will have the capability to be deployed in 2 modes (1. Stand-alone and 2. Multi-tenant). For mode 2 deployment, we will have an Auth driver loaded in BMI that for security purpose.

I was talking about security risks the user can pose to other user's nodes that are being provisioned on the same network.(not only as user but as attacker), we need to understand this better. For 2, we don't need an auth driver, we can piggy back on existing network isolators(usually they provide tenancy through projects or something).

Yes, this is a later task. But now that we are considering a refactoring of BMI, we should design a pluggable BMI that reconsiders all the decisions that were taken when developing BMI for the first time.

Adding support may not change our code from architectural stand-point. Instead of implementing iSCSI, we can implement a generic provisioning protocol interface(naming to be changed).

@chemistry-sourabh
Copy link
Contributor

Ok I am confused now. Will Multi-tenant version come with HIL support ? The way I understood it is
BMI will create a target on a specific interface (If multi vlan is implemented) nothing more than this. It is the user's headache to connect the networks using HIL or whatever they want to use.

In Security point of view, Why will 2 users have same networks ? The network is bound to the project right ? If using with HIL I guess users won't be able to create admin networks.

The code wise probably as per @ravisantoshgudimetla's idea we need to make a parent interface which ISCSI, NFS, ... will extend.

@ravisantoshgudimetla
Copy link
Contributor

In Security point of view, Why will 2 users have same networks ? The network is bound to the project right ? If using with HIL I guess users won't be able to create admin networks.

I guess, he meant all tenants will be given a default provisioning network to use. which should be good from implementation perspective.

@chemistry-sourabh
Copy link
Contributor

Do you mean all tenants in a project ?

@naved001
Copy link
Contributor Author

The call to the network isolator has been removed. All we do is check the ownership of the node when we provision it. Since this issue is now stale, we can open up another thread with more specific architectural discussion.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants