Hi Mani, By Customizing i meant the same things that you mentioned about adding interfaces and adding the nodes as a part of some VLAN etc. Yes we can start implementing these features. A basic User Interface design should be made and then we can go into the backend code design and integrating with Open VSwitch.
Thanks Georgy On Wed, Aug 8, 2012 at 3:47 PM, Mani Shafa'atDoost <[email protected]>wrote: > I hope you got a chance to review emails. > Since most important issues has been mentioned, so I think we can start > designing a solution to implement these features. > Please let me know, how can we continue this work to the design and > implementation stage. > > Best Regards > Mani > > On Mon, Aug 6, 2012 at 12:01 PM, Mani Shafa'atDoost <[email protected] > >wrote: > > > Georgy, I have a question about Cluster Customization options, would you > > mind to explain it more. > > Josh, Thank you very much for summing up everything. > > > > I think we need to have following features: > > * we should be able to add more than two VNIC to each VM > > There are two option for this, first is to add more VLAN on image > > specification, second is to add VNIC just in the provisioning time > > I think the first solution is better > > *Add each VNIC to one VLAN which allow you to customize your network > > Again, we have three options for adding VLAN tag, first is in the host > > level (A lot of customization in each host) - not good. second to do > > tagging on the Vmware Vswitch which is reasonable. Third is adding tag > > on physical switch ( good for bare-metal images) > > * Add a resource managing tab in VCL which allow user to make > > a customize network by using VLANs( also it is possible to add IP for > each > > NIC) Then we can give permission to user to have access to this tab. > > * It is possible to make a topology and reserve it as a normal image in > > reservation menu ( like an image with sub-images) > > > > Best Regards > > Mani > > > > > > On Thu, Aug 2, 2012 at 2:06 PM, Georgy Mathew Kallumkal <[email protected] > >wrote: > > > >> Adding to the above list: > >> > >> -Just like we have normal reservation, imaging reservation we can have > >> "topology reservations" under the resource Manage Topologies. (We can > then > >> design the UI on the similar lines as imaging reservation. For Imaging > >> reservations we have the forimaging field set in the "request" table. we > >> can have a new entry called "fortopology"). > >> - Able to reserve a cluster of computers which may span over multiple > >> servers. > >> - Configuring the cluster with either "Default" settings or "Customize" > >> - Things that can be customized: Image environment, Interconnecting > >> topology, private networks, VLAN's. > >> > >> -Georgy > >> > >> On Thu, Aug 2, 2012 at 12:29 PM, Josh Thompson <[email protected] > >> >wrote: > >> > >> > -----BEGIN PGP SIGNED MESSAGE----- > >> > Hash: SHA1 > >> > > >> > VCL can be enhanced by the ability to configure networks between > >> > provisioned > >> > systems and existing network infrastructure. Mani Shafa'atDoost and > >> Georgy > >> > Kallumkal already started discussing the possibility of using Open > >> vSwitch > >> > to > >> > provide some level of functionality. That discussion can be viewed at > >> this > >> > thread: > >> > > >> > http://mail-archives.apache.org/mod_mbox/vcl- > >> > dev/201208.mbox/<CAOhH3q+4kaYOE3=h6g5BCPyJnE8S7BNXmWMbqGW=5eYJ= > >> > [email protected]> > >> > > >> > I'd like to start a discussion to design out a more generalized form > of > >> > network management. Here are some initial thoughts to guide things. > >> > > >> > Remember to design in security from the beginning. If users will need > >> to > >> > apply some type of "network config" to a reservation, who will be able > >> to > >> > access which network configs? It would probably be best to make them > a > >> new > >> > resource. That would provide a way to control who can use them, who > can > >> > administer them, and to which other resources they can be applied > >> > (mapping). > >> > > >> > Another thing to keep in mind is modularity. For simple installs, > >> people > >> > may > >> > not want to do any network management. So, there should either be the > >> > option > >> > to not use it, or to have a default configuration that is just applied > >> to > >> > everything that is deployed. Also, it should be possible to change > out > >> > which > >> > technology is used for network management, as well as being able to > use > >> > multiple technologies at the same time. Open vSwitch has already been > >> > mentioned and looks to be a great thing to start with. However, VCL > can > >> > also > >> > provision bare metal installs. In this case, it would be good to be > >> able > >> > to > >> > interface with the physical switches to which the bare machines are > >> > connected. > >> > It would also be good to have the option of supporting options other > >> than > >> > Open > >> > vSwitch. > >> > > >> > Try to design things such that there can be a somewhat simple UI for > the > >> > end > >> > users. One of VCL's strong points is that it has a simple UI for an > end > >> > user > >> > in making a reservation for an image (though the admin UI can get > rather > >> > complicated). I like the idea of trying to keep an admin portion of > the > >> > site > >> > where things can be controlled with high granularity, but a user > >> portion of > >> > the site where things can be reserved with simplicity. > >> > > >> > So, those are some good guidelines to keep in mind when adding > features > >> to > >> > VCL. I'd suggest the first step in developing a new feature would be > to > >> > list > >> > out the requirements. Here are a few things to use as a starting > point > >> of > >> > a > >> > feature set: > >> > > >> > * connect a specific VLAN to a reserved image > >> > * configure a "private network" among a cluster of images > >> > * allow either of the above to be associated with an image so that > >> > it gets configured when a reservation for the image is made > >> > * allow an image/cluster and a network config to be selected > >> > independently at deploy time (i.e. opposite of previous item) > >> > * authorization controls of who has access to which network configs > >> > > >> > Others - please add further requirements to this as you see fit. > >> > > >> > Josh > >> > - -- > >> > - ------------------------------- > >> > Josh Thompson > >> > VCL Developer > >> > North Carolina State University > >> > > >> > my GPG/PGP key can be found at pgp.mit.edu > >> > > >> > All electronic mail messages in connection with State business which > >> > are sent to or received by this account are subject to the NC Public > >> > Records Law and may be disclosed to third parties. > >> > -----BEGIN PGP SIGNATURE----- > >> > Version: GnuPG v2.0.17 (GNU/Linux) > >> > > >> > iEYEARECAAYFAlAaqtUACgkQV/LQcNdtPQM+PACfRB1leBItS/hJi1SZTEV8yQVg > >> > +EcAn0Yu5Ye/INZnWm2Q5+qrUSYZ+3Bv > >> > =8lFv > >> > -----END PGP SIGNATURE----- > >> > > >> > > >> > > > > > > > > -- > > Best Regards > > Mani > > > > > > > -- > Best Regards > Mani >
