Hi Karuna Do you consider different user roles? For example, admin users and regular users? I think adding user roles to VCL cloud broker tool might be good if an admin user can set security policy for specific images and VCL can set it when instance creates, for instance.
I agree that the current VCL data base does not have much detail information about images and consistency might be an issue. I think Image inventory management is necessary for VCL to store detailed image information as metadata and other project can use them like VCL cloud broker tool. Regards, -------------------------------------------------------------------- Young Hyun Oh From: Karuna P Joshi <kjos...@umbc.edu> To: vcl-dev@incubator.apache.org, Date: 05/24/2012 09:38 PM Subject: Re: VCL cloud broker tool - first look Hello Aaron, Thanks for your suggestions. I agree that there should be a mechanism for users to be able to search on the software components that they are looking for. Unfortunately, the current VCL database doesn't associate any such information with the images. At best we find some information in the description or name of the image, but that is also not consistent. In our previous correspondence, Andy Kurth had mentioned that there is a need for maintaining an "image inventory" . (I believe a JIRA issue has been created about this https://issues.apache.org/jira/browse/VCL-561 ). This inventory project will complement the broker that I plan to design since it will enable more complex querying capability. I have incorporated the additional data and security constraints to make the VCL broker compliant with NIST's cloud computing standards. The fields were taken from the NIST use case 3.9 Query Cloud-Provider Capabilities and Capacities, http://www.nist.gov/itl/cloud/3_9.cfm . One of the research areas that my mentor at IBM is very interested in is how to make VCL compliant with US federal agencies' cloud computing policies. As for the buttons - my aim is to code to 3 functions - discovery, negotiation (or constraint relaxation) and reserve images. Discovery will try to search all available images for the attributes specified. Failing this, the broker will begin relaxing the constraints and refresh the list. For instance, if a user specifies - "I want MatLab, R and at least version 1.6 of JAVA's runtime environment" and no image is discovered, the tool will attempt to find images by relaxing the constraint of JAVA version . I will most likely reduce the number of buttons depending on how easily I am able to do this with SPARQL. I feel that I might need 3 buttons to ensure the functionality since SPARQL returns results in a XML/RDF format which I will have to process to allow reservation. Yes, I plan to run this user interface as an external service . However, I will have to design a server component of this which will interface directly with the VCL APIs or database. If time permits, I can extend this broker tool to query multiple VCL installations at the same time - allowing users to reserve the most suitable image across various VCL systems. regards, Karuna On Thu, May 24, 2012 at 12:54 PM, Aaron Coburn <acob...@amherst.edu> wrote: > Karuna, > > I looked at what you are proposing here, and it is quite exciting. I have > recently been working a fair amount with RDF and SPARQL, and it can be very > powerful. > > You asked for some feedback on the interface. I think this is a good > start. Given the number of possible permutations of thirteen (mostly) > categorical attributes, the interface you designed would be great for > navigating through reasonably large image collections. For smaller > collections of images, I think the number of attributes would be a bit > cumbersome for the average user. > > The one attribute that users would most certainly want to be able to > specify is one related to the software available on the image. And this > would need to be a multi-valued field. (i.e. "I want MatLab, R and at least > version 1.6 of JAVA's runtime environment") > > The way I would go about this (borrowing from the language of search > engines) is to see these attributes as "facets" that help narrow a search. > The value of each facet would be a constraint in the logic of your query, > and these constraints could be turned on or off, affecting the result list. > > It should be possible to design the interface so that you could > effectively eliminate all four of the blue rectangular buttons. "List all > images" would be achieved by removing all selected constraints; it would > also be the initial state of the interface. "Discover images that match" > would not be necessary if the result list is auto-updated when any > constraint is added or removed. From a user's perspective I'm not sure how > "Negotiate and Finalize Image" differs from "Reserve Image". Either of them > could be achieved by clicking on the name of the relevant SPARQL result. > > From a systems architecture perspective, it seems that you anticipate > having this tool running in an external (e.g. Joseki) service. I assume > that the service would query the VCL API (on behalf of a given user) to > identify the list of all accessible images along with the relevant > attributes for each image. By extending the API slightly, I can see how > this could work very well. Using the VCL's API, reservations could also be > made and managed directly through this brokering tool. > > Thanks for preparing this information. I look forward to seeing more! > > Aaron > > > -- > Aaron Coburn > Systems Administrator and Programmer > Academic Technology Services, Amherst College > acob...@amherst.edu<mailto:acob...@amherst.edu> > > > > On May 23, 2012, at 5:56 PM, Karuna P Joshi wrote: > > Hello, > > I have designed the User interface for the VCL cloud broker tool and have > uploaded the screenshot of this interface into the JIRA issues wiki. > I look forward to feedback on the interface from VCL developers. > > On a related note, how does one assign the JIRA issue ? I want to assign > this issue (VCL-577) to myself, but the field appears un-editable. > > regards, > Karuna > ____________________ > Karuna Pande Joshi > PhD Candidate, > CSEE Dept, UMBC > kjos...@umbc.edu<mailto:kjos...@umbc.edu>, karuna.jo...@umbc.edu<mailto: > karuna.jo...@umbc.edu> > > -- regards, Karuna ____________________ Karuna Pande Joshi PhD Candidate, CSEE Dept, UMBC kjos...@umbc.edu, karuna.jo...@umbc.edu
