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

Reply via email to