-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Comments inline below. I'll go ahead and untag the ones that were agreed on.
On Thursday, September 25, 2014 3:00:48 PM Andy Kurth wrote: > > I'd like to bump these issues to 2.5. I think they will delay us too much > > in getting a release out. Please reply if there are any you really think > > should be in 2.4. On Friday, I'd like to bump to 2.5 any of them that no > > one replies about keeping in 2.4. > > I agree we need to complete 2.4 and several issues can be untagged > from 2.4. I know I mentioned changing the tags to 2.5 in my previous > email. However, looking though the ones you brought up made me > realize that rather than simply upping the version tag, we should > reevaluate each issue. If you look at the history of a few of the > issues, the tag changed from 2.2 to 2.3 to 2.4, and now possibly 2.5. > This kick-the-can method of release management isn't working too well. > For the issues don't make it into 2.4 we still deem beneficial, I > think it would be better to just untag the issues' "Fix Version" until > the release. After the release, we can go through every issue and > devise a thoughtful and realistic roadmap. What does everyone think? I like this idea. > My individual issue votes and comments inline below: > > VCL-66 - Reservations for newly created images may be assigned to > > management nodes or computers on which the image can't run > > https://issues.apache.org/jira/browse/VCL-66 > > +1 (close, won't fix) > I created this one and sure went crazy with the description. Although > this would be an improvement, the complexities outweigh its value. It > would only benefit deployments with multiple management nodes and was > really only intended to resolve an issue where certain images could > only run in certain places. This problem this issue described can be > avoided with proper mapping. > > > 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? > > VCL-216 - seat licensing - user group based SW licensing > > https://issues.apache.org/jira/browse/VCL-216 > > +1 (untag from 2.4, lack of time) > This would be a very useful feature but would only benefit a narrow > range of images. > > > VCL-290 - user managed image scripts > > https://issues.apache.org/jira/browse/VCL-290 > > +1 (close, duplicate) > The description needs more detail. From what was given, it sounds > like this is describing concepts that the configuration management > feature would cover. > > > VCL-296 - option for VM placement to minimize VM hosts or to spread load > > https://issues.apache.org/jira/browse/VCL-296 > > +1 (untag from 2.4, lack of time) > This needs a fair amount of discussion. It would be good if the scope > of this issue is broadened to cover VM scheduling optimization for > performance and power saving. I have some ideas regarding this. > Whoever decides to work on this, please start a thread on the dev > list. > > > 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. > > VCL-369 - Tools to search the privilege tree > > https://issues.apache.org/jira/browse/VCL-369 > > +1 (untag from 2.4, lack of time) > Although extremely needed, this involves the privilege tree and I can > see how it could consume a bit of time. > > > VCL-372 - allocate a new computer to blockComputers if one is put in > > maintenance, vmhostinuse, or hpc > > https://issues.apache.org/jira/browse/VCL-372 > > +1 (untag from 2.4) > I'm tempted to vote -1 for this one because this seems like a pretty > trivial change. However, every time I touch blockrequest.pm I'm > reminded it needs some cleanup. Regardless, this issue only affects a > fairly rare case and isn't very critical. > > > VCL-448 - allow access to edit computers without needing access to edit a > > schedule > > https://issues.apache.org/jira/browse/VCL-448 > > +1 (untag from 2.4, more discussion needed) > The whole "schedule is a resource" design should be discussed. I > agree with the intention of this issue, but think it may be bandaging > the underlying architecture which could be improved. Whoever works on > this, please start a thread on the dev list first. > > > VCL-449 - add max concurrent reservations per affiliation > > https://issues.apache.org/jira/browse/VCL-449 > > +1 (untag from 2.4, lack of time) > It doesn't seem like this issue alone would take too much time to > implement. However, there is currently no way of managing > affiliations via the website. Without this, it would be pretty > useless for most. > > > 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). > > 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. > > VCL-561 - Image inventory > > https://issues.apache.org/jira/browse/VCL-561 > > +1 (untag from 2.4, lack of time) > Some code is complete to retrieve software information from Windows > images but nothing to store it in the database or present it via the > website. This will be a very useful feature but there is a lot of > work to do. > > > VCL-566 - Separate image type from OS in database > > https://issues.apache.org/jira/browse/VCL-566 > > +1 (untag from 2.4) > This is a huge undertaking and should be a top priority after 2.4. > The code I'm working on to replace update-vcl.sql should make the > transition easier. > > > 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. > > VCL-591 - Image copy/push for distributed management nodes > > https://issues.apache.org/jira/browse/VCL-591 > > +1 (untag from 2.4, lack of time) > Although useful, this would be a lot of work. There are higher priorities. > > > VCL-645 - store/update fingerprint info for machines for end-user > > reservations https://issues.apache.org/jira/browse/VCL-645 > > +1 (untag from 2.4) > Not a high priority. It apparently came from a single end user request at > NCSU. > > VCL-689 - Configuration Management > > https://issues.apache.org/jira/browse/VCL-689 > > +1 (untag from 2.4) > This is a hugely ambitious feature nowhere near complete. > > -Andy > > > Josh > > > > On Monday, September 22, 2014 1:55:21 PM Andy Kurth wrote: > >> I'd like to start discussing and planning the VCL 2.4 release. This is a > >> good opportunity to review and improve several aspects of the project > >> including our testing and release procedures, documentation, and the > >> roadmap. I will be best to create separate threads for the various > >> topics. This thread is devoted to the progress of development work which > >> remains to be done. Separate threads will be created to discuss > >> documentation, etc. > >> > >> Please use this thread to detail everything you are working on or plan to > >> work on related to VCL 2.4. If the technical details of any particular > >> issue needs to be discussed further, start a dedicated thread. > >> > >> Here is a link to the open 2.4 issues: > >> https://issues.apache.org/jira/issues/?filter=12329339 > >> > >> And to all of the 2.4 issues: > >> https://issues.apache.org/jira/issues/?filter=12329344 > >> > >> Some of the open issues can be closed. I will be going through and > >> updating the ones I have worked on this week. > >> > >> I have added a "fix version" 2.4 tag to all of the issues which were only > >> tagged 2.3.3, and these are included in this filter. We should probably > >> delete 2.3.3 from Jira. I have also added a 2.5 version to Jira. There > >> will be a few issues we will decide to shelve for 2.4. These can be > >> untagged 2.4 and tagged 2.5. Please DO NOT untag any issues from 2.4 > >> without first asking the dev list! > >> > >> There are a few significant issues I plan to work on over the next few > >> weeks: > >> > >> * Database changes for VCL 2.4 ( > >> https://issues.apache.org/jira/browse/VCL-764) > >> I will be working on a Perl script which reads vcl.sql and either imports > >> the schema into a new database for new installs or compares the file to > >> an > >> existing database's schema and executes 'alter' statements. This will > >> eliminate the need for the unwieldy update-vcl.sql file. > >> > >> * Allow dynamic private IP addresses, remove /etc/hosts requirement ( > >> https://issues.apache.org/jira/browse/VCL-767) > >> There is still some work to do to remove the reliance on /etc/hosts being > >> populated on each management node. The code is still using the hostname > >> for SSH commands. This needs to be changed. It is required in order to > >> properly test the Openstack module. For this issue, we need an upgrade > >> path since this is a significant change would could significantly break > >> things. When an upgrade to 2.4 is performed, each management node will > >> need to check every computer mapped to it and make sure the private IP > >> address the hostname resolves to matches the database. The database > >> should > >> be updated if the private IP address is missing or incorrect. This > >> functionality may be included in the script to update the schema, making > >> it > >> a more general install/upgrade script. > >> > >> * Improve user connection checking and how firewall is locked down ( > >> https://issues.apache.org/jira/browse/VCL-753) > >> This is also a significant change and needs a lot of testing. The code > >> to > >> use the connectlog table is mostly complete but I have not committed it > >> yet. > >> > >> * Add support for 64-bit cygwin ( > >> https://issues.apache.org/jira/browse/VCL-783) > >> This is a pretty easy one. The Windows module was designed to funnel > >> everything which would be affected by 32 vs 64-bit versions through > >> is_64_bit and get_system32_path so the changes will be minor. The > >> cygwin-sshd-config.sh and update_cygwin.cmd scripts also need an update. > >> > >> As always, your thoughts and comments are welcome. > >> > >> Thank You, > >> Andy > > > > - -- > > - ------------------------------- > > 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.22 (GNU/Linux) > > > > iEYEARECAAYFAlQjErQACgkQV/LQcNdtPQPIDACdFjlV31Dybx0h96ThRGtOBiXt > > DXYAn0xIGIbp5yEKdpbQVLLGY7ZdQnGD > > =e+5V > > -----END PGP SIGNATURE----- - -- - ------------------------------- 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.22 (GNU/Linux) iEYEARECAAYFAlQr/joACgkQV/LQcNdtPQMxcQCdH4+B3hcGavCx9UADQHtaQ/tC aOgAn3LjnZr6upVyGQqBO/Z0HfmSfB/G =3vg2 -----END PGP SIGNATURE-----
