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----- > >
