cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lsimons <>
Subject [GitHub] cloudstack pull request: Feature cenik123 vpcvrr 1.1.1
Date Tue, 02 Dec 2014 08:50:05 GMT
Github user lsimons commented on the pull request:
    Hey folks,
    Karl thanks for contributing. Looks like quite a bit of work!
    Rohit thanks for CC-ing me in :)
    It's a bit hard to read the pull request right now and provide review comments:
    * Github says there's nearly 7000 changed files so at a guess something went wrong there?
I had a look, and it looks like KarlHarrisSungardAS/cloudstack is quite a ways behind master,
which may explain that...? It's probably a good idea to make a copy of the feature branch,
rebase it against current master, squash some of the commits together, and then re-send the
pull request. Or, start another branch, and cherry-pick over just the changes that _should_
be in the change set.
    * git hasn't picked up on the relation between veewee and packer, it's probably good idea
to give it some more hints. For example it would be good to see
    compared to the veewee equivalent.
    * there's a lot of 'shuffling' and/or adding comments intermixed with functional changes.
For example
you might think the 'set -x' is getting removed here, but it just moved down a bit amidst
a few new comments.
    * there's a lot of commits that are seemingly unrelated to the actual change (probably
cherry-picked from master onto the feature branch?), those will need to be filtered out I
    * there's a lot of 'archive' commits which have unfinished 'checkpoint' code. I imagine
all that work gets finished 'later on' (like renaming _gitignore to .gitignore is one that
I tracked) but it's not so easy to see. It'd be great if those things could be squashed together.
    As far as content goes...
    1) Like sebastien says, veewee is in maintenance mode and moving to packer (replacing
veewee) is definitely a good idea. This looks like a straightforward port, which if it works
ok seems like the way to go. We _should_ make sure to do it in a way that's somewhat compatible
with the setup. I don't think we could sustain maintenance of both
packer and veewee builds for long, it'll be a pain to keep changes in sync. I'd want to drop
veewee use completely.
    2) Testing the systemvm using vagrant is also obviously a good idea (we're doing much
the same, over at
see for an abandoned
branch having just test-related commits), though I don't understand why we'd need to use vagrant
templates? The .box file that we get out of the veewee-based systemvm build imports (
just fine...
    3) For the stuff that seems to be planned _beyond_ these changes, it might be a good idea
to pop by on the development mailing list and discuss plans. A few people at Schuberg Philis
(my employer, where there's a few people working on cloudstack) have been working on redundancy
for the virtual router for a few months now. We've found that making it work also involves
a lot of changes outside of the systemvm, too, i.e. changing the orchestration logic in the
java code to match changed behavior of the vpc router (see
/ ). @spark404 please do have
a look at Karl's approach :)

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message