Ideally, we could just install our whole tree somewhere, and leave it up to the packagers to do system specific stuff. For example, with CentOS we could dump a whole tree in /opt, then in the packaging create symlinks to /opt/whatever in the places an admin would expect to see config files, copy an init script that starts cloudstack in the location we chose for the tree, etc.
As far as the recent fixes, I've fixed things like: change places where cloud-agent and cloud-setup-agent scripts were called in java code to use cloudstack-agent various things that were looking in /var/lib/cloud to /var/cloudstack, fixed things such as ssh key generation and unable to log in with default admin/password upon install change the path to systemvm.iso in the kvm agent from /usr/lib64/cloud to /usr/share/cloudstack-common (this issue was only apparent after noticing that dhcp wasn't working on the routers, then noticing that the systemvm.iso was out of date, then finding the path was bad) Were being told to install vhd-util in /usr/share/cloud rather than /usr/share/cloudstack on mgt server On Thu, Feb 14, 2013 at 10:06 AM, Alex Huang <alex.hu...@citrix.com> wrote: > Marcus, > > It's a good rant! I brought up the whole download an archive and run it and > partly because I figure there's problems like this since CloudStack has > always been installed one way and one way only. > > But I don't know the specifics. Do you have any examples you can share? > That way we can show people why this should not be done. Will be a good > lesson for us all. Also if you show some examples, other developers can help > in locating similar problems so you don't have to do all the work alone? > > Thanks! > --Alex > >> -----Original Message----- >> From: Marcus Sorensen [mailto:shadow...@gmail.com] >> Sent: Thursday, February 14, 2013 8:38 AM >> To: cloudstack-dev@incubator.apache.org >> Subject: name change of cloud- to cloudstack- explosion >> >> I (and others) have been working through a ton of issues revolving >> around this name change, and while I think it's a good move in >> general, I wanted to bring up two points to consider for similar >> changes in the future. I've been primarily working in the 4.1 branch. >> >> 1) This is showing me just how tied the code is to the installation. >> Mostly on the agent side, but a bit on the server side as well. >> Someone mentioned in the future being able to download an archive and >> just run it wherever you extract it, I think there's going to be a bit >> of work there in making paths compatible. It has also been mentioned >> that we should make some globals such that we don't have paths >> sprinkled all over the code, that's probably worthwhile as well. >> >> 2) I'm beginning to think that this sort of thing should be done in a >> branch, thoroughly tested, and then merged in. I'm not sure what the >> thinking was here as-is. If someone moves a file elsewhere, are they >> thinking "this needs to be done, we'll just do it, see what breaks and >> fix it later", or are they just unaware of item #1 above and have no >> idea what code might be relying on that file being there in the right >> place. I would hope that someone would at least do a grep through the >> code or something. This is perhaps a subtle thing because changing >> paths doesn't necessarily cause builds to break or some tests to fail. >> >> Sorry for the rant. I understand that we didn't have packages at all a >> few weeks ago, so this should be a step up. Ideally, changing the way >> something is packaged shouldn't require changes to the code, or at >> worst minimal changes, but we're not there and I think it caught us >> off guard. Perhaps I don't understand all of the subtleties, but the >> lesson I take from this is that we should have first made packaging >> work as it did before, instead of introducing sweeping changes at the >> same time.
