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  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" 
> To: "Will Stevens" 
> Cc: "Edison Su" , "Wilder Rodrigues" 
> , dev@cloudstack.apache.org,
> "Leo Simons" 
> 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  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"  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 
>>> 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 *|* Mont

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" 
> 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!  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" 
> > 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