-
Notifications
You must be signed in to change notification settings - Fork 16
Architectural changes discussion #99
Comments
@knikolla would appreciate your thoughts on this |
#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. |
@naved001 Can you explain what you mean by provision here. I mean, series of steps that provision would do?
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.
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, |
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.
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. |
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.
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).
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). |
Ok I am confused now. Will Multi-tenant version come with HIL support ? The way I understood it is 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. |
I guess, he meant all tenants will be given a default provisioning network to use. which should be good from implementation perspective. |
Do you mean all tenants in a project ? |
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. |
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.
Let us know in the comments section below @CCI-MOC/bmi-breakers
The text was updated successfully, but these errors were encountered: