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

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


Reply via email to