Thanks for the feedback. One request when anyone untags an issue, please add a comment with the corresponding discussion from this thread or a link to this thread. This will make it easier to evaluate the issues later on.
> > > VCL-178 - enable checkuser flag for per reservation instead of image > only > > > https://issues.apache.org/jira/browse/VCL-178 > > > > -1 (keep in 2.4) > > This is one that was created in 2009 and got bumped all the way from > > the 2.2 release. The backend code has supported this feature since > > 2010. This would be pretty useful. How much time would it take to > > implement this? > > The easy part is adding a checkbox for reservations that says not to do > user > login checks. The hard part is determining who sees the checkbox (i.e. > permissions). How do we determine who gets to see this functionality? Is > it > a global permission? Is it something that is image specific? Is it image > specific but also tied to a user permission? Though not ideal, what about doing something similar to the special "Specify End Time" group? If we want to do something more elaborate in the future such as adding a new privilege, it should be relatively easy to transition by granting the single special group the new privilege. > > > VCL-343 - image capture process summary for end-user > > > https://issues.apache.org/jira/browse/VCL-343 > > > > +? > > The description needs more detail. What details? In an email? On > > the website? What details are not communicated which would be useful? > > This may be a pretty trivial change and could possibly be included. > > Nothing is communicated about the image capture process other than > completed/failed via email, for users that have email working. It would be > great to keep reservations in the state of being captured on the > Reservations > page with a link where "Pending" normally is that pops up a window showing > information about where things are in the capture process. > +1 (untag, lack of time) That makes sense. I changed the description of the issue to this and untagged it. > > > > > VCL-525 - explain how to install non autoprovisioned connect methods > > > https://issues.apache.org/jira/browse/VCL-525 > > > > +? > > The description needs more detail. Is this referring to text that > > needs to be displayed on the website where connect methods are > > configured? > > Connect methods can be flagged as "autoprovisioned" or not. If > autoprovisioned, it is assumed either all images using some OS will have > the > connect method available (i.e. RDP on Windows), or vcld will be able to > provision the method if it is not already there. If not autoprovisioned, > it > is the responsibility of the image creator to install the connect method. > It > would be useful for connect methods that are not autoprovisioned to have > some > text somewhere associated with the connect method that explains to an image > creator how to install that connect method (i.e. To install xRDP, you need > to > install x, y, z packages and modify j, k, l configuration files). > +1 (untag, lack of time) Thanks for the clarification. I'd like to revisit the connectmethodmap.autoprovisioned flag and how different connect methods show up as (1) being a valid method a user sees on the Connect page and (2) to image administrators as being an option to enable for an image. It may be best to use separate columns or a separate mapping table for each use. > > > VCL-526 - add section to site to manage connect methods > > > https://issues.apache.org/jira/browse/VCL-526 > > > > -1 (or replace with a new issue) > > How much time will this take? We added the connect methods feature in > > 2.3 without a way to manage them other than directly modifying the > > database. Not good. If adding a feature to the website takes too > > much time we could add something to "vcld -setup" for 2.4. I'm not > > voting +1 for the release without some way to manage this. > > Again, this is a permissions issue. Who gets to see and manage each > connect > method? It would also require creating a new section of the site for > managing > it. It may work to make them a new resource. > So, add to "vcld -setup"? This wouldn't be too difficult and would only be available to admins with access to a management node. > > VCL-577 - Cloud Broker tool for VCL > > > https://issues.apache.org/jira/browse/VCL-577 > > > > +? > > This was submitted by Karuna Joshi. We need to reach out to her and > > make sure she is involved in this discussion. If she is interested > > and willing to assist, we should make an effort to include this in > > 2.4. If she is interested but it is not feasible timewise to include > > it in 2.4, it should be top priority after the release. We need to > > encourage these contributions. > This is more something that uses VCL instead of something that is part of > VCL. > So, I don't see a need for it being included in a release. However, if it > were, Karuna would need to step up as a committer to maintain it, in which > case, she should be contacted. I don't necessarily see it as needing to be included, but the issue includes a patch file to the VCL code and there was a fair amount of communication in the issue comments. The responsibility of testing it and getting it into the release rests on her. We have been bitten in the past by removing a module someone contributed who was not active in the community at the time. Although this is not the same situation, we need to be completely transparent and be sure to not surprise anyone. I'll send her a direct message. If she doesn't respond or is not able to prepare it for the release within our time constraints then we shelve it. Thanks, Andy
