date:20141202

Re: [GitHub] cloudstack pull request: Feature cenik123 vpcvrr 1.1.1

2014-12-02 Thread sebgoa


On Dec 2, 2014, at 8:32 AM, bhaisaab g...@git.apache.org wrote:

 Github user bhaisaab commented on the pull request:
 
https://github.com/apache/cloudstack/pull/33#issuecomment-65192819
 
Wrong question, I should asked about veewee vs packer. The current 
 systemvm building scripts uses veewee to build systemvms and to export 
 appliances in various image/file formats (such as vhd, qcow2, raw, ova) we 
 depend on vbox-manage, qemu etc. We further use veewee to build vagrant 
 boxes. I just want to understand how easy it is to build/export appliances 
 using packer as I have never played with it and veewee/vagrant requires ruby 
 and other dependencies that are hard to setup?
 

veewee is being abandoned in favor of packer. so ultimately we should start 
using packer.

 
 ---
 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 infrastruct...@apache.org or file a JIRA ticket
 with INFRA.
 ---

Re: 05bec59c - kvm, qcow, systemvm qemu-img -o compat

2014-12-02 Thread Nux!

As I said above EL7 comes with qemu-img 1.5.3 and it requires the compat 
option, so it's not only 1.7+.
Personally I'm in favour of Will's approach.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Rohit Yadav bhais...@apache.org
 To: Will Stevens wstev...@cloudops.com
 Cc: Edison Su edison...@citrix.com, Wilder Rodrigues 
 wrodrig...@schubergphilis.com, dev@cloudstack.apache.org,
 Leo Simons lsim...@schubergphilis.com
 Sent: Tuesday, 2 December, 2014 07:36:21
 Subject: Re: 05bec59c - kvm, qcow, systemvm qemu-img -o compat

 Hi Will,
 
 While we can use your first solution that checks exit status ($?) but in
 case some is running the script with a set -e, the script will simply
 break when $? is not zero. I think if we know above which qemu-img version
 we should we the compat option (1.7?) than that's great we should we that.
 Thanks for looking into this.
 
 Regards.
 
 On Tue, Dec 2, 2014 at 8:01 AM, Will Stevens wstev...@cloudops.com wrote:
 
 Thanks for that. Does that mean that we prefer to do an if else based on
 version rather than basically doing a try catch?

 I have not been involved in previous bash scripting for CS, so I am
 willing to fall in line with the preferred method. What I proposed was
 based on how similar problems were solved in other code in the same file.

 If I check for version, do you agree that I should check for 1.7 as the
 version since that is the version where the compact default changed?

 I will try to get this resolved tomorrow.

 Cheers,

 Will
 On Dec 1, 2014 9:16 PM, Edison Su edison...@citrix.com wrote:

  qemu-img |head -n 1|awk '{print $3}'

 should show the version of qemu-img



 *From:* williamstev...@gmail.com [mailto:williamstev...@gmail.com] *On
 Behalf Of *Will Stevens
 *Sent:* Monday, December 01, 2014 2:17 PM
 *To:* dev@cloudstack.apache.org
 *Cc:* Leo Simons; Wilder Rodrigues; Rohit Yadav; Edison Su
 *Subject:* Re: 05bec59c - kvm, qcow, systemvm qemu-img -o compat



 Alright, so far I have found the following:
 https://github.com/qemu/qemu/commit/9117b47717ad208b12786ce88eacb013f9b3dd1c



 Basically, if the qemu-img version is less than 1.7, we should run the
 non 'compat' option version and if the version is 1.7 or greater, we should
 run the new command with the 'compat' version.



 Unfortunately I am not able to find a way to get the qemu-img version
 from the command line.



 I am looking to basically add a conditional to try running with the
 compat option and if that fails, then run it without the compat option.



 Basically, I would be replacing this:



 qemu-img convert -o compat=0.10 -f raw -c -O qcow2 raw.img
 ${appliance_build_name}-kvm.qcow2



 With this:



 set +e

 qemu-img convert -o compat=0.10 -f raw -c -O qcow2 raw.img
 ${appliance_build_name}-kvm.qcow2

 local qemuresult=$?

 set -e

 if [ ${qemuresult} != 0 ]; then

   log INFO qemu-img convert failed, trying without compat option

   qemu-img convert -f raw -c -O qcow2 raw.img
 ${appliance_build_name}-kvm.qcow2

 fi



 What do you guys think?  Is this a good enough solution?  If you guys
 agree I will implement it in master and make sure it works, then we can
 merge the change back to 4.5 to fix that branch as well.



 Let me know if you have issues with this approach...



 Cheers,



 Will




 *Will STEVENS*

 Lead Developer



 *CloudOps | *Cloud Solutions Experts

 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6

 w cloudops.com *|* tw @CloudOps_



 On Mon, Dec 1, 2014 at 4:06 PM, Will Stevens wstev...@cloudops.com
 wrote:

 Edison,

 According to this page the default compat option is 0.10:
 http://manpages.ubuntu.com/manpages/trusty/man1/qemu-img.1.html



 Did you find that to not be the case and is that why you had to add the
 compat option?



 BTW, in an attempt to get the master system vms building again, I
 committed a change to master to remove the compat option.  We now have
 master system vms building correctly, but Rohit rightly pointed out that I
 had basically reverted your change.



 I created a Jira ticket for this issue:
 https://issues.apache.org/jira/browse/CLOUDSTACK-7959



 I have not reverted my change in master at this point, so it is building
 right now, but I also did not make the change to 4.5, so that branch is
 currently failing to build system vms.



 I will see if I can track down in which version of qemu the compat option
 was added so we can add some intelligent logic around this command.



 Will








 *Will STEVENS*

 Lead Developer



 *CloudOps | *Cloud Solutions Experts

 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6

 w cloudops.com *|* tw @CloudOps_



 On Thu, Nov 20, 2014 at 1:07 PM, edison su sudi...@gmail.com wrote:

 Hi Leo,
 Our new internal build system are using ubuntu 14.04 or something like
 that, which has qemu 1.x installed by default, that's why I added the
 compat option in the build script, otherwise, the image build by
 qemu 1.x, won't

Re: NFS overprovisioning of 0.5 ???

2014-12-02 Thread Nux!

I think your approaching this from the wrong side. 
Why not just nfs export half of the space instead? (you could use lvm, thin-lvm 
etc)?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
 From: Andrija Panic andrija.pa...@gmail.com
 To: us...@cloudstack.apache.org, dev@cloudstack.apache.org
 Sent: Tuesday, 2 December, 2014 07:53:37
 Subject: NFS overprovisioning of 0.5 ???

 Hi.
 
 wondering if it is possible to set overprovisioning factor to less than 1 ?
 
 I have 1 NFS box, 2 x 10GB cards inside, don't want to do bonding, but
 efectively present this single box as 2 boxes via 2 IP adresses - so in
 this scenario I need to set overprovisioning factor to less than 1, to i.e.
 0.5 - because of disk space etc...
 
 This is for test purposes, but again...
 
 --
 
 Andrija Panić

Re: NFS overprovisioning of 0.5 ???

2014-12-02 Thread Andrija Panic

true... ZFS pool under NFS...will consider...but I;'m just wondering, since
it is math of available space = overprovisioningFactor x realspace - I
guess this is technicaly possible...

On 2 December 2014 at 09:34, Nux! n...@li.nux.ro wrote:

 I think your approaching this from the wrong side.
 Why not just nfs export half of the space instead? (you could use lvm,
 thin-lvm etc)?

 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
  From: Andrija Panic andrija.pa...@gmail.com
  To: us...@cloudstack.apache.org, dev@cloudstack.apache.org
  Sent: Tuesday, 2 December, 2014 07:53:37
  Subject: NFS overprovisioning of 0.5 ???

  Hi.
 
  wondering if it is possible to set overprovisioning factor to less than
 1 ?
 
  I have 1 NFS box, 2 x 10GB cards inside, don't want to do bonding, but
  efectively present this single box as 2 boxes via 2 IP adresses - so in
  this scenario I need to set overprovisioning factor to less than 1, to
 i.e.
  0.5 - because of disk space etc...
 
  This is for test purposes, but again...
 
  --
 
  Andrija Panić




-- 

Andrija Panić

[GitHub] cloudstack pull request: Feature cenik123 vpcvrr 1.1.1

2014-12-02 Thread lsimons

Github user lsimons commented on the pull request:

https://github.com/apache/cloudstack/pull/33#issuecomment-65199170

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

https://github.com/KarlHarrisSungardAS/cloudstack/commit/892b11ec0230ce87d14370fd1055ac223096cc77#diff-67bdab8b08f1e110ceabe1a23c3d4011R1
compared to the veewee equivalent.
* there's a lot of 'shuffling' and/or adding comments intermixed with
functional changes. For example
https://github.com/KarlHarrisSungardAS/cloudstack/commit/7f55a1ef032c29cb955e02c90da43c91739108d7#diff-95748c84d8b6be2da502091e69b748d9L30
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 think.
* 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 jenkins.buildacloud.org
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
https://github.com/schubergphilis/cloudstack/tree/feature/systemvm-persistent-config/tools/vagrant/systemvm
see https://github.com/schubergphilis/cloudstack/commits/feature/systemvm-test
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
(https://github.com/apache/cloudstack/blob/master/tools/appliance/build.sh#L466)
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
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
/ https://www.slideshare.net/LeoSimons1/toolkit-posterccceu14-v2 ). @spark404
please do have a look at Karl's approach :)

cheers,

Leo

---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

60 matches

Mail list logo