Let me rant again: A symlink would just have worked if they dislike cloud-, cloudstack- prefix opens just another can of worms.
Regards. On Thu, Feb 14, 2013 at 10:56 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > 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.
