Dimitri, Thank you for reviewing documents and email. In my mind, Manage Image->Edit Image Profile->Edit Image is the best place to put this feature. and yes it is not a good idea to give access to end-users to change network requirements, so it should be done by admin.
About notifying VCLD ,not sure what do you mean. But I think, we may add another columns into image table at the database which represents topology id. On Thu, Aug 9, 2012 at 2:26 PM, Dmitri Chebotarov <[email protected]> wrote: > > In my opinion adding vNIC to VM in image profile will make more sense, > since software installed on the image defines need for additional > network(s). > > As for use interface, one more field (Custom vNetworks ? ) could be added > to Manage Image->Edit Image Profile->Edit Image, print-screen attached (new > field is after Minimum Network Speed) > > > There is a need to notifying VCL when image profiles changes, so vcld > process can reload the image with new networking. At this time vcld checks > for image revision and if it matches then e. > > Also, do you plan to give access to create/assign/modify custom networks > to an end-user? Or is it going to be handled my image administrator (and > coordinated with VCL admins) ? I agree with Josh in keeping end-user > portion of the site as simple as possible. Current 3-click reservation > process works well. > > Thanks. > > On Aug 9, 2012, at 12:29 , Mani Shafa'atDoost <[email protected]> > wrote: > > I think we need to make some decisions at this level. For example should we > add a VNIC to VM in image profile or it is better to add it > in customizing level and just load theses new VNIC at provisioning time. > Also, as far as I know, you have done something on interface, so would you > mind to share it with us? or some documents to show which shows what are > you planing to do. > At the end, orks together and the submit it as a > > contribution to VCL. So, I think it is better to make a better design at > this stage. > > > > > On Wed, Aug 8, 2012 at 4:58 PM, FNU Georgy Mathew Kallumkal < > [email protected] > > wrote: > > > 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 esigning 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 customi 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 > "topo 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 > > 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 > > ** > > 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. &nb 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 > - -- > - ------------ sh 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 > > > > > > -- > Best Regards > Mani > > > > -- > Thank you, > > Dmitri Chebotarov > Virtual Computing Lab Systems Engineer, TSD - Ent Servers & Messaging > 223 Aquia Building, Ffx, MSN: 1B5 > Phone: (703) 993-6175 > Fax: (703) 993-3404 > < v> > -- Best Regards Mani
