On 13-Jan-2013, at 10:30 AM, Wido den Hollander <w...@widodh.nl> wrote:
> Hi, > > On 01/11/2013 04:05 PM, Noa Resare wrote: >> (This email is probably mostly for Wido and possibly Hugo but I'm sending >> it to the list to get a bit more transparency) >> > > Great! :) > >> Looking at the packaging branch(1) I think the work to reduce the number of >> subpackages is a very good initiative. The current setup for 4.0 with lots >> of packages with somewhat counterintuitive naming adds complexity both to >> the build process and to users of the package. >> >> The current state of the packaging branch contains subpackages -server, >> -scripts, -setup, -python, -agent, -system-iso and -usage. >> >> I think that packages should be as few as possible but that we should avoid >> payload duplication. In practice that would translate to one package per >> server use case (in my case, agent and server) and have shared artifacts in >> a common package. >> > > Yes, that seems to be a very logical and commonly used way of packaging. > >> If we are doing any change where subpackages will be obsoleted we would >> need to follow the http://wiki.debian.org/Renaming_a_Package guidelines >> (which means creating an empty last version of the old package depending in >> the new package to get the upgrade path properly) and if we are doing that >> for any package we might as well do it for everything and bite bullet with >> the cloud -> cloudstack renaming. >> >> So, my proposal: three new packages: >> >> - cloudstack-server (containing everything specific to the server) >> - cloudstack-agent (containing everything specific to the agent) >> - cloudstack-common (containing the things needed by both) >> > > How great this would be, I don't think that it would actually work, a > couple of things: > > The CloudStack management server consists out of the API and the UI. The > UI does nothing else then connecting to the API. > > Currently they are packaged both, but it's not a requirement that you > actually run the CloudStack UI. > > I'm currently working on a setup where we actually run the UI on a > different server then the API runs on. We do a lot of proxying the > requests around, but it's mainly due to different styling we need. But > it's to much to explain what we are doing and it's not relevant here. > > My point is that it's not a requirement to actually run the UI, just the > API should be enough. > > So we should have -server AND -client where the latter just contains the UI. > > I'm also not confident that all the "common" stuff can go into a common > package. > > We have: > - Scripts > - The SystemVM ISO > > Now, the SystemVM thing is something that has been bothering me for a > long time now and it will probably change soon. > > If you run KVM you need the ISO locally on your Agent, but if you run > any other Hypervisor the ISO is needed on the Management server. > > While that is a weird quirk in the way CS works right now, we as package > maintainers need to have this working. > > For now we can just simply put this ISO file in the "common" package > since we know it will change at some point, but it has to be noted that > this works in this way. > > Same goes for the scripts currently in cloud-scripts. Some are used by > the management server, some by the agent, some by both. > > And then there is de AWS API, that also needs a package. It's just like > the UI not mandatory to run the AWS API, it's a decision you make. > > Same goes for the usage server here, you don't need it, but if you want > it, then it needs to run on the management server. > > Well, it's not actually required, but by default > /etc/cloud/usage/db.properties is a symlink to ../management/db.properties. > > A lot of symlinking goes on here, so we probably have to be creative in > the pre-inst and post-inst files to get that all sorted out nicely. > > While I personally would like to see every Bash script disappear from > the CloudStack codebase we still have to work with this. > > So yes, I'm behind the decision to trim down the packages with the > exception that I think the UI deserves it's own package. > > We should also be aware of the fact that the common package will be kind > of messy since it contains all kinds of files. > > So in the end I think we end up with: > - cloudstack-server > - cloudstack-client > - cloudstack-usage > - cloudstack-awsapi > - cloudstack-agent (maybe -kvm-agent or -agent-kvm?) > - cloudstack-common +1, cloudstack-agent is fine (agent is used in systemvm.iso and we've agents running in systemvms like cpvm,ssvm as well). May be we should split common as common (common to all pkgs) and systemvm (we can put iso and scripts here), but both ways is fine. Regards. > > Makes that sense? > > Wido > >> and a separate source package emitting new empty versions of all current >> packages that could be added once to the repo referenced on >> http://incubator.apache.org/cloudstack/downloads.html >> >> /noa >> >> >> 1) https://github.com/noaresare/incubator-cloudstack/commits/packaging >> >>
