Re: [ANNOUNCE] Demetrius Tsitrelis as committer

[Rajani Karuturi]

Congratulations Demetrius.. 


~Rajani



On 08-Jun-2014, at 11:09 am, Ahmad Emneina  wrote:

> Great news, congrats Demetrius!
> 
> Ahmad
> 
>> On Jun 6, 2014, at 4:17 PM, John Kinsella  wrote:
>> 
>> Folks - this one’s a little belated - we went through the invite process 
>> around the
>> time of the mail issues, and somehow we didn’t send the announcement to dev@.
>> I noticed while doing some housekeeping this week, and wanted to send out the
>> announcement anyways just to give Demetrius the recognition. :)
>> 
>> The Project Management Committee (PMC) for Apache CloudStack has
>> asked Demetrius Tsitrelis to become a committer and we are pleased to 
>> announce
>> that he has accepted.
>> 
>> Being a committer allows many contributors to contribute more autonomously. 
>> For
>> developers, it makes it easier to submit changes and eliminates the need to
>> have contributions reviewed via the patch submission process. Whether
>> contributions are development-related or otherwise, it is a recognition of a
>> contributor's participation in the project and commitment to the project and
>> the Apache Way.
>> 
>> Please join me in congratulating Demetrius!
>> 
>> -John, on behalf of the CloudStack PMC

ssvm logs

[Ekta Agrawal]

HI,

I need logs for all functioning of ssvm, can somebody send the logs showing
all function which are happening properly.

if somebody can point the code of cloudstack , I  want  to understand logs
written for process of management and functioning done by ssvm .

Please help me if you can.


Regards,
Ekta

Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...

[Rohit Yadav]

Hi Sheng,

On Sun, Jun 8, 2014 at 8:57 AM, Sheng Yang  wrote:

> Hi Rohit,
>
> Well, I don't quite understand why gerrit is "old". Google has a team
> actively working on it and the release of new version seems pretty fast to
> me(https://code.google.com/p/gerrit/, latest release at June(2.9-rc2) and
> May(2.8.5) this year). Since Google, SAP and OpenStack are using it I don't
> think quality or functionality would be an issue generally. The most
> enticing feature of gerrit for me is itself is the repo, and you cannot go
> around the gerrit to check in without proper process in any case.
>
> I didn't look into deep about Phabricator currently but I don't want to
> bring "A is better than B" discussion at this moment. I think that can be
> up to evaluation after we decided that test and review need to be enforced
> through automation process.


+1 can we have a PMC member to lead this effort and start discussion/voting
on having a test/review process?


> Which tool is best for that purpose can be up
> to discuss.
>

Sure. This thread started like "Let's start using Gerrit", on the face
value I thought it's like we've already considered which tool to use and we
just want to start with setup/adoption process.

By "old", I was implying low commit/development activity and
technical/design debt it carries. Since I've used both of them (and
Gitlab/Github) for writing real software, I'll list couple of specific pain
points wrt code reviewing, but before that I would like everyone to try
both of them before making mind;

Try Gerrit2 with your github repo: http://gerrithub.io
Explore Phabricator: https://secure.phabricator.com

You may google to find reviews on both, I was going to write a comparative
summary but this quora answer summarizes my pain points:
http://qr.ae/sudCG

Phabricator is more like a swiss knife but has three great tools inside it
IMO useful for ACS like Differential (code reviews, pre-commit), Audit
(review, post-commit), Arcanist (command line tool),  Herald (alarms on
certain parts of code, such as db files etc.). Unnecessary features can be
turned off.

Arcanist is awesome, it speeds up the workflow of sending patch, testing
it, merging it etc. The whole patch can be viewed in one tab, in-line
comments work, the UI is much better, works better with JIRA/Confluence,
they are opensource too and have a more active development community.

Companies using Phabricator: http://leanstack.io/phabricator
Code reviewing compared: http://leanstack.io/code-review

I'm sharing my opinion just to help us consider best tool for the job and
adopt it in future.

Regards.


> --Sheng
>
>
> On Fri, Jun 6, 2014 at 10:48 PM, Rohit Yadav  wrote:
>
> > Hi,
> >
> > On Sat, Jun 7, 2014 at 4:56 AM, Sheng Yang  wrote:
> >
> > > Hi all,
> > >
> > > Seems it's a good timing to bring back the discussion about the gerrit.
> > >
> > > We want to do CI, and improve our code quality. One obvious way of
> doing
> > > and reduce the workload of devs is introduce a tool to enforce the
> > process.
> > >
> > > I've checked out quite a few projects using gerrit, which would force
> you
> > > to ask for review, and validation before the code can be committed to
> the
> > > repo. Looks it's really a easier way for devs according what I've
> heard.
> > >
> > > Even our competitor laid out a very detail workflow based on the use of
> > > gerrit( https://wiki.openstack.org/wiki/Gerrit_Workflow ). I guess it
> > can
> > > make a good reference.
> > >
> >
> > I've used gerrit before, it's old and has its own pain points. I suppose
> we
> > need an on-premise solution that ASF infra folks can help setup for
> > projects such as CloudStack.
> >
> > So, can we consider other/better opensource alternatives such as
> > Phabricator (phabricator.org), I've used it before and it's great. It
> > comes
> > with a command line tool and a web ui for all tasks and comes with
> > following stuff;
> >
> > - a command line tool (called archanist) which allows you to
> > review/test/merge patches and while committing it hooks up linters and
> unit
> > testing
> > - it allows you to audit patches i.e. review commits already pushed on a
> > branch
> > - it has alarms (herald) which can trigger on bunch of rules and alert us
> > via email, for example if someone changes database files we can put an
> > alarm on set of files to get alert emails
> > - people who have used Github reviewing would have less time learning to
> > use it
> > - works with git (hg, svn etc.)
> > - high quality software with many awards and used/maintained by tons of
> > companies such as Facebook, Dropbox etc.
> >
> > Before we start with the actionable items, please just explore it here
> > http://phabricator.org/tour
> >
> > Regards.
> >
> >
> > > Well, gerrit has been brought up a few times before. And now the new
> > > process we want to enforce just fits what gerrit(or other automation
> > > review/test/commit software) is for.
> > >
> > > Maybe it's the time for us to review t

Re: [ACS44] 112 unpicked cherries in 4.4-forward. why?

[sebgoa]

On Jun 8, 2014, at 5:31 AM, Sheng Yang  wrote:

> To my understanding 4.4-forward is a staging tree for 4.4.1 release
> currently, and only issues critical enough would go for 4.4 branch,

I disagree. That makes things messy, 4.4-forward should only exist till 4.4 is 
out, really everything in 4.4-forward should go in 4.4.0.
then folks commit to 4.4 for future bug fix releases...

-sebastien


> and
> author would ask for pick up in that case. I think that's what's happened
> with 4.3-forward branch.
> 
> --Sheng
> 
> 
> On Sat, Jun 7, 2014 at 3:05 PM, Sudha Ponnaganti <
> sudha.ponnaga...@citrix.com> wrote:
> 
>> Wondering why not baseline with 4.4-forward branch.
>> 
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Saturday, June 07, 2014 2:53 AM
>> To: dev
>> Subject: [ACS44] 112 unpicked cherries in 4.4-forward. why?
>> 
>> H,
>> 
>> To start with my personal finger pointing: especially test authors and UI
>> devs seem to be to blame for the difference (and me of course).
>> please take a moment to make sure your important work is not going to be
>> lost for future generations.
>> 
>> I am sure I did it way more complicated then needed but here it is:
>> 
>> git config pretty.blame "format:blame %H '%aN <%aE>' - '%cn <%cE>' - '%s'"
>> git cherry 4.4 4.4-forward | grep -e ^+ | cut -f 2 -d ' ' - | xargs -L
>> 1 git show --pretty=blame | grep -e ^blame
>> 
>> this gave me a nice list of commits that are not going into 4.4 as things
>> are.
>> There is some noise in there that might be filtered out by even more
>> clever scripting on the output with ^- in the first grep command:
>> 
>> 1. things that where picked the other way around for instance
>>   fc52e641d8f69d8c0b552119203b0a2bc58e488f 'Daan Hoogland <
>> d...@onecht.net>' - 'Daan Hoogland ' -
>> 'try-with-resource to prevent resource leaks'
>> 2. things that were reverted in the branch (8 occurs so that is a minus 16
>> dropping the number under 100)
>> 
>> this leaves a lot of things though.
>> 
>> Please have a look in the list below or execute the commands your self and
>> decide what to do about them:
>> 
>> blame 617826d16b4d5220bb3b51ed511b3c065d0e8926 'Koushik Das <
>> kous...@apache.org>' - 'Daan Hoogland ' -
>> 'CLOUDSTACK-6445: Simulator enhancements Refer FS -
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+enhancements
>> '
>> blame 953167808c3e9a9c40a6f7be6e16ebf32c608a4c 'Jessica Wang <
>> jessicaw...@apache.org>' - 'Jessica Wang ' -
>> 'BUG-ID: CS-19795: UI > Add LDAP Account - fix a bug that a LDAP account
>> that does not have email and all LDAP accounts below it are missing from
>> the listing. Reviewed-by: Brian'
>> blame a542b6fd825da1d3582a282bcc0e67abd62964bf 'Mike Tutkowski <
>> mike.tutkow...@solidfire.com>' - 'Mike Tutkowski <
>> mike.tutkow...@solidfire.com>' - 'CLOUDSTACK-6170 (VMware root-disk
>> support for managed storage)'
>> blame beb26237bceabfc3ebeae57431f9affb21d041e5 'Brian Federle <
>> brian.fede...@citrix.com>' - 'Brian Federle ' -
>> 'Create form: Store passed JSON object in select options, for plugin use'
>> blame 4a85e2226436c62e781db3449d262cb385b977c1 'Anshul Gangwar <
>> anshul.gang...@citrix.com>' - 'Devdeep Singh ' -
>> 'CLOUDSTACK-6470: while stopping vm in hyper-v, now we are first trying to
>> shutdown it gracefully before turning it off forcefully'
>> blame 66f8e0e1b5c81cbfde926c0c65c4d5969767cab9 'Anshul Gangwar <
>> anshul.gang...@citrix.com>' - 'Devdeep Singh ' -
>> 'CLOUDSTACK-6504: removed warnings coming in building hyper-v agent code'
>> blame 5a49bb2db76f8dda9d41d9f700afd54d172ed415 'Sanjay Tripathi <
>> sanjay.tripa...@citrix.com>' - 'Sanjay Tripathi <
>> sanjay.tripa...@citrix.com>' - 'Fix log messages for vgpu creation.'
>> blame 404ac549bfd84e97c756009f214e74cdb73548de 'SrikanteswaraRao Talluri <
>> tall...@apache.org>' - 'SrikanteswaraRao Talluri ' -
>> 'Marvin + test changes from master
>> Signed-off-by: SrikanteswaraRao Talluri '
>> blame 4f1f182cba5579da2fc7ce1f02019a0afa00efeb 'SrikanteswaraRao Talluri <
>> tall...@apache.org>' - 'SrikanteswaraRao Talluri ' -
>> 'CLOUDSTACK-5674:Fixed pep8 errors in python files in marvin folder
>> Signed-off-by: SrikanteswaraRao Talluri '
>> blame de114f554895c24c0d25106a775f1405eac79c6d 'Koushik Das <
>> kous...@apache.org>' - 'Koushik Das ' -
>> 'CLOUDSTACK-4371: [Performance Testing] Basic zone with 20K Hosts,
>> management server restart leaves the hosts in disconnected state for very
>> long time Fixed simulator code to handle local storage during host
>> reconnect'
>> blame dcd3ce5ce03eeb0675776622e757e6e638cb433d 'SrikanteswaraRao Talluri <
>> tall...@apache.org>' - 'SrikanteswaraRao Talluri ' -
>> 'CLOUDSTACK-5674:Fixes for BVT and Regression test failures. Signed-off-by:
>> SrikanteswaraRao Talluri '
>> blame 1b74f3f3c864db55e3cd8e1f704c35b81d97ffbf 'Anthony Xu <
>> anthony...@citrix.com>' - 'Anthony Xu ' - 'disable
>> XS event'
>> blame db153062dbe356021924d9b3441b9d2561d06

RE: [ACS44] 112 unpicked cherries in 4.4-forward. why?

[Sudha Ponnaganti]

Agree with Sebastien. 4.4 is cut too early. By cherry picking and missing some 
of the critical fixes in to 4.4, isn't it safe to baseline with 4.4-forward 
which has majority of the fixes. It is not like new features are added to 4.4 
forward. Looks like most of them are fixes to existing functionality on 4.4. 

Thanks
/Sudha

-Original Message-
From: sebgoa [mailto:run...@gmail.com] 
Sent: Sunday, June 08, 2014 4:52 AM
To: dev@cloudstack.apache.org
Subject: Re: [ACS44] 112 unpicked cherries in 4.4-forward. why?


On Jun 8, 2014, at 5:31 AM, Sheng Yang  wrote:

> To my understanding 4.4-forward is a staging tree for 4.4.1 release 
> currently, and only issues critical enough would go for 4.4 branch,

I disagree. That makes things messy, 4.4-forward should only exist till 4.4 is 
out, really everything in 4.4-forward should go in 4.4.0.
then folks commit to 4.4 for future bug fix releases...

-sebastien


> and
> author would ask for pick up in that case. I think that's what's 
> happened with 4.3-forward branch.
> 
> --Sheng
> 
> 
> On Sat, Jun 7, 2014 at 3:05 PM, Sudha Ponnaganti < 
> sudha.ponnaga...@citrix.com> wrote:
> 
>> Wondering why not baseline with 4.4-forward branch.
>> 
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Saturday, June 07, 2014 2:53 AM
>> To: dev
>> Subject: [ACS44] 112 unpicked cherries in 4.4-forward. why?
>> 
>> H,
>> 
>> To start with my personal finger pointing: especially test authors 
>> and UI devs seem to be to blame for the difference (and me of course).
>> please take a moment to make sure your important work is not going to 
>> be lost for future generations.
>> 
>> I am sure I did it way more complicated then needed but here it is:
>> 
>> git config pretty.blame "format:blame %H '%aN <%aE>' - '%cn <%cE>' - '%s'"
>> git cherry 4.4 4.4-forward | grep -e ^+ | cut -f 2 -d ' ' - | xargs 
>> -L
>> 1 git show --pretty=blame | grep -e ^blame
>> 
>> this gave me a nice list of commits that are not going into 4.4 as 
>> things are.
>> There is some noise in there that might be filtered out by even more 
>> clever scripting on the output with ^- in the first grep command:
>> 
>> 1. things that where picked the other way around for instance
>>   fc52e641d8f69d8c0b552119203b0a2bc58e488f 'Daan Hoogland < 
>> d...@onecht.net>' - 'Daan Hoogland ' - 
>> 'try-with-resource to prevent resource leaks'
>> 2. things that were reverted in the branch (8 occurs so that is a 
>> minus 16 dropping the number under 100)
>> 
>> this leaves a lot of things though.
>> 
>> Please have a look in the list below or execute the commands your 
>> self and decide what to do about them:
>> 
>> blame 617826d16b4d5220bb3b51ed511b3c065d0e8926 'Koushik Das < 
>> kous...@apache.org>' - 'Daan Hoogland ' -
>> 'CLOUDSTACK-6445: Simulator enhancements Refer FS - 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+enha
>> ncements
>> '
>> blame 953167808c3e9a9c40a6f7be6e16ebf32c608a4c 'Jessica Wang < 
>> jessicaw...@apache.org>' - 'Jessica Wang ' -
>> 'BUG-ID: CS-19795: UI > Add LDAP Account - fix a bug that a LDAP 
>> account that does not have email and all LDAP accounts below it are 
>> missing from the listing. Reviewed-by: Brian'
>> blame a542b6fd825da1d3582a282bcc0e67abd62964bf 'Mike Tutkowski < 
>> mike.tutkow...@solidfire.com>' - 'Mike Tutkowski < 
>> mike.tutkow...@solidfire.com>' - 'CLOUDSTACK-6170 (VMware root-disk 
>> support for managed storage)'
>> blame beb26237bceabfc3ebeae57431f9affb21d041e5 'Brian Federle < 
>> brian.fede...@citrix.com>' - 'Brian Federle 
>> ' - 'Create form: Store passed JSON object in 
>> select options, for plugin use'
>> blame 4a85e2226436c62e781db3449d262cb385b977c1 'Anshul Gangwar < 
>> anshul.gang...@citrix.com>' - 'Devdeep Singh ' -
>> 'CLOUDSTACK-6470: while stopping vm in hyper-v, now we are first 
>> trying to shutdown it gracefully before turning it off forcefully'
>> blame 66f8e0e1b5c81cbfde926c0c65c4d5969767cab9 'Anshul Gangwar < 
>> anshul.gang...@citrix.com>' - 'Devdeep Singh ' -
>> 'CLOUDSTACK-6504: removed warnings coming in building hyper-v agent code'
>> blame 5a49bb2db76f8dda9d41d9f700afd54d172ed415 'Sanjay Tripathi < 
>> sanjay.tripa...@citrix.com>' - 'Sanjay Tripathi < 
>> sanjay.tripa...@citrix.com>' - 'Fix log messages for vgpu creation.'
>> blame 404ac549bfd84e97c756009f214e74cdb73548de 'SrikanteswaraRao 
>> Talluri < tall...@apache.org>' - 'SrikanteswaraRao Talluri 
>> ' - 'Marvin + test changes from master
>> Signed-off-by: SrikanteswaraRao Talluri '
>> blame 4f1f182cba5579da2fc7ce1f02019a0afa00efeb 'SrikanteswaraRao 
>> Talluri < tall...@apache.org>' - 'SrikanteswaraRao Talluri 
>> ' - 'CLOUDSTACK-5674:Fixed pep8 errors in python 
>> files in marvin folder
>> Signed-off-by: SrikanteswaraRao Talluri '
>> blame de114f554895c24c0d25106a775f1405eac79c6d 'Koushik Das < 
>> kous...@apache.org>' - 'Koushik Das ' -
>> 'CLOUDSTACK-4371: [Performance Testing] Basic zone with 20K Hosts, 
>> ma

Re: [Proposal] NuageVsp Network Plugin

[Suresh Ramamurthy]

Hi Ilya,

We have plans to support KVM too. We are working on it.

Thanks,
Suresh


On Wed, Jun 4, 2014 at 9:19 PM, ilya musayev 
wrote:

> Hi Suresh
>
> Hope all is well,
>
> Are there any plans to support KVM or is it just XEN?
>
> Thanks
> ilya
>
> On 6/4/14, 9:08 PM, Suresh Ramamurthy wrote:
>
>> Hi Dev Team,
>>
>> Thanks for allowing us to submit NuageVsp Network Plugin support to
>> CloudStack.
>>
>> I have added the design specification in the wiki. Please find the link
>> below
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
>> NuageVsp+Network+Plugin
>>
>> Please review it and let me know if I need to provide more information in
>> the spec.
>>
>> Could you please point me to any link that describes about the branching
>> strategy that we need to followed to add our code.
>>
>> Thanks,
>> Suresh
>>
>>
>

Re: SNAT iptable entry on VirtualRouter

[Sachchidanand Vaidya]

Hi Sheng,
   Thanks. We are using XenServer 6.2 SP1. After adding debug in the code, I 
see that addVif never gets called  in my case.
That's why nic deviceId is zero. Code falls thru the case where vif is already 
present.If I dump "correctVif.getDevice(conn)"
it returns zero.

Does this command handler also gets called when Public-ip is associated with 
VM's private ip (StaticNAT) ?
Do we create a new interface in DomainRouter when staticNAT entry is created?

Thanks,
Sachin

From: Sheng Yang mailto:sh...@yasker.org>>
Date: Friday, June 6, 2014 4:12 PM
To: "mailto:dev@cloudstack.apache.org>>" 
mailto:dev@cloudstack.apache.org>>, Sachchidanand 
Vaidya mailto:vaidy...@juniper.net>>
Subject: Re: SNAT iptable entry on VirtualRouter

Hi Sachin,

The nicDevId() you see is coming from 
prepareNetworkElementCommand(IpAssocCommand cmd) in CitrixResourceBase in case 
of Xen.

You would see this:

if (addVif) {
// Add a new VIF to DomR
String vifDeviceNum = getLowestAvailableVIFDeviceNum(conn, 
router);

if (vifDeviceNum == null) {
throw new InternalErrorException("There were no more 
available slots for a new VIF on router: " + router.getNameLabel(conn));
}

nic.setDeviceId(Integer.valueOf(vifDeviceNum));

correctVif = createVif(conn, routerName, router, null, nic);
correctVif.plug(conn);
// Add iptables rule for network usage
networkUsage(conn, routerIp, "addVif", "eth" + 
correctVif.getDevice(conn));
}

And nic.setDeviceId() should set the public nic id(which should be 2 in your 
case) to it.

And what's the XenServer version you're using? Could you help to debug it 
further more? Sadly we cannot reproduce it in our lab...

Thanks!

--Sheng


On Fri, Jun 6, 2014 at 12:29 AM, Sachchidanand Vaidya 
mailto:vaidy...@juniper.net>> wrote:
Hi,
   I'm seeing the same issue with 4.4 code.  After further debug, I see
that CS mgmt server is sending
following command to XenHost,
xensource.log:  /opt/cloud/bin/ipassoc.sh -A -s -f -l
10.84.59.131/24<http://10.84.59.131/24> -c eth0 -g 10.84.59.254 
VirtualRouter's public interface is eth2. Also as per dump of VIF list on
XenHost, deviceid for public interface
of domainRouter is 2.
As part of VirtualRoutingResource.java:generateConfig(), CS mgmt server
generates this command.
It generates publicNic = "eth" + ip.getNicDevId()?
Which deviceId does it refer to? Shouldn't it be the deviceid as per the
XenHost dump?
Does anyone have input on what could he happening here ?

Thanks,
Sachin



>Hi,
>I have an isolated network (192.168.3.x/24) being served by
>VirtualRouter, where 10.84.59.131 is SourceNAT address
>and eth0 is VN interface of VirtualRouter & eth2 is  the public interface
>of VirtualRouter.
>
> When I look at the nat table entries on the VirtualRouter, it shows
>following :
>
>root@r-6-VM:~# iptables -L -t nat -n -v
>..
>..
>Chain POSTROUTING (policy ACCEPT 330 packets, 22113 bytes)
> pkts bytes target prot opt in out source
>destination
>0 0 SNAT   all  --  *  eth00.0.0.0/0
>0.0.0.0/0to:10.84.59.131
>
>--> Why the "out" interface for the SNAT entry is VN interface (eth0)
>instead of Public interface (eth2) ?
>
>I'm using "Cloudstack Release 4.3.0 (64-bit) Thu Apr 10 20:27:11 UTC
>2014" cloudstack-release template.
>
>Thanks,
>Sachin
>
>---
>root@r-6-VM:~# ifconfig
>eth0  Link encap:Ethernet  HWaddr 02:13:87:88:e6:dd
>  inet addr:192.168.3.226  Bcast:192.168.3.255  Mask:255.255.255.0
>  inet6 addr: fe80::13:87ff:fe88:e6dd/64 Scope:Link
>  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>  RX packets:350 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:1000
>  RX bytes:29400 (28.7 KiB)  TX bytes:602 (602.0 B)
>  Interrupt:25
>
>eth1  Link encap:Ethernet  HWaddr 0e:00:a9:fe:02:6b
>  inet addr:169.254.2.107  Bcast:169.254.255.255  Mask:255.255.0.0
>  inet6 addr: fe80::c00:a9ff:fefe:26b/64 Scope:Link
>  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>  RX packets:3293 errors:0 dropped:0 overruns:0 frame:0
>  TX packets:2934 errors:0 dropped:0 overruns:0 carrier:0
>  collisions:0 txqueuelen:1000
>  RX bytes:444768 (434.3 KiB)  TX bytes:539100 (526.4 KiB)
>  Interrupt:26
>
>eth2  Link encap:Ethernet  HWaddr 06:d5:1c:00:00:0b
>  inet addr:10.84.59.131  Bcast:10.84.59.255  Mask:255.255.255.0
>  inet6 addr: fe80::4d5:1cff:fe00:b/64 Scope:Link
>  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>  RX packets:133 errors:0 dropped:0 overruns:0 frame:0
>  TX pac

wiki editing rights

[Dave Scott]

Hi,

I’d like to add a design doc to the wiki. Could someone assign me the 
appropriate wiki permissions?

My account username is djs55.

Thanks,
Dave

Re: wiki editing rights

[sebgoa]

On Jun 8, 2014, at 4:21 PM, Dave Scott  wrote:

> Hi,
> 
> I’d like to add a design doc to the wiki. Could someone assign me the 
> appropriate wiki permissions?
> 
> My account username is djs55.
> 

should be good now

> Thanks,
> Dave

Jenkins build is back to normal : build-systemvm64-4.2 #304

[jenkins]

See 

[DISCUSS] extending the libvirt/KVM plugin to also support libvirt/Xen

[Dave Scott]

Hi,

Following on from the earlier "[PROPOSAL] Support pure Xen as a hypervisor”, 
I’ve added a design doc to the wiki:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Allow+hosts+running+the+Xen+hypervisor+to+be+managed+via+libvirt

This design would allow people who want to manage their hypervisors purely 
through the libvirt tools to choose the Xen hypervisor.

>From the code point of view, I want to maximise sharing between the KVM and 
>Xen code paths, partly to make QA easier and partly to maximise the chance 
>that adding a feature for “Xen” causes it to work for “KVM” and vice-versa. In 
>particular this means that, if a genuinely-useful capability is currently 
>missing from the libvirt libxl driver, I want to implement it rather than work 
>around it.

Comments appreciated!

Cheers,
Dave

[1] 
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201403.mbox/%3ccajgxtbnbmqtq81ralgh2kma7v5wjyzkr3xnyasmkc_br+uk...@mail.gmail.com%3e

Review Request 22354: CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

[Olivier Lemasle]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22354/
---

Review request for cloudstack and Kishan Kavala.


Bugs: CLOUDSTACK-6850
https://issues.apache.org/jira/browse/CLOUDSTACK-6850


Repository: cloudstack-git


Description
---

This patch updates VMInstanceUsageParser to process usage details (cpu cores, 
cpu speed and memory) for dynamic compute offering usages, in order to save 
them in table cloud_usage.cloud_usage and return them with the API 
(listUsageRecords).

See CLOUDSTACK-6850.

A change in database model is required for this patch (three new columns in 
cloud_usage.cloud_usage).

The patch should apply on master and 4.4.


Diffs
-

  api/src/org/apache/cloudstack/api/response/UsageRecordResponse.java 5e2e85d 
  api/src/org/apache/cloudstack/usage/Usage.java 20dc189 
  engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java 06d4876 
  engine/schema/src/com/cloud/usage/UsageVO.java 67014ef 
  engine/schema/src/com/cloud/usage/dao/UsageVMInstanceDaoImpl.java b94e12f 
  server/src/com/cloud/api/ApiResponseHelper.java 119f56d 
  setup/db/db/schema-430to440.sql d149a65 
  usage/src/com/cloud/usage/parser/VMInstanceUsageParser.java ba0d4bf 

Diff: https://reviews.apache.org/r/22354/diff/


Testing
---

Packaged in RPMs, installed and manually tested.

1. Create a VM with compute offering "Small instance".
2. Stop the VM.
3. Change service offering to a custom offering, with cpu_number=1, 
cpu_speed=500 MHz, memory=512 MB
4. Start the VM, wait... Stop the VM.
6. Change service offering to an other custom offering, with cpu_number=2, 
cpu_speed=800 MHz, memory=1024 MB
7. Start the VM, wait... Stop the VM.
8. Change service offering to the first custom offering, with same "details" 
(cpu_number=2, cpu_speed=800 MHz, memory=1024 MB)
9. Start the VM, wait... Stop the VM.
10. Change service offering to "Medium instance".

Usages and details are reflected in database and in API response. There is no 
regression found for other usage types.
Details are returned (and saved in database) only for RUNNING_VM and 
ALLOCATED_VM, only if the service offering is a custom one.

Example of response:


admin
184a6564-edab-11e3-b629-0050569ed71c
fbc7578a-edaa-11e3-b629-0050569ed71c
e5047089-c911-40ea-8251-4a76810ac1e0
california allocated (ServiceOffering: 12) (Template: 
5)
0.098078 Hrs
2
0.098078
e89c22af-65cf-42a2-8905-6f4bbd7d59a1
california
b05b64e9-8e0f-4335-b0e0-acc5bad81938
fbca2564-edaa-11e3-b629-0050569ed71c
e89c22af-65cf-42a2-8905-6f4bbd7d59a1
XenServer
1
500
512
2014-06-08'T'17:05:52+02:00
2014-06-08'T'17:15:52+02:00


admin
184a6564-edab-11e3-b629-0050569ed71c
fbc7578a-edaa-11e3-b629-0050569ed71c
e5047089-c911-40ea-8251-4a76810ac1e0
california allocated (ServiceOffering: 1) (Template: 
5)
0.068594 Hrs
2
0.068594
e89c22af-65cf-42a2-8905-6f4bbd7d59a1
california
84bbf38f-b582-440b-8a8d-20e63e0dbed7
fbca2564-edaa-11e3-b629-0050569ed71c
e89c22af-65cf-42a2-8905-6f4bbd7d59a1
XenServer
2014-06-08'T'17:05:52+02:00
2014-06-08'T'17:15:52+02:00



Thanks,

Olivier Lemasle

Re: [ACS44] 112 unpicked cherries in 4.4-forward. why?

[Daan Hoogland]

As I read your comments you actually don't agree with Sebastien,
Sudha. 4.4-forward was cut of at code freeze. Since then fixes are
committed there and cherry-pick are done by the RM. It seems that this
is exactly what Sebastien meant it to be for.

@Sebastien: in Shengs words I read that some of the things in
4.4-forward would only go in 4.4 after the release (thing with lower
priority then critical)

We all don't agree, let's agree on that.;}

On Sun, Jun 8, 2014 at 2:27 PM, Sudha Ponnaganti
 wrote:
> Agree with Sebastien. 4.4 is cut too early. By cherry picking and missing 
> some of the critical fixes in to 4.4, isn't it safe to baseline with 
> 4.4-forward which has majority of the fixes. It is not like new features are 
> added to 4.4 forward. Looks like most of them are fixes to existing 
> functionality on 4.4.
>
> Thanks
> /Sudha
>
> -Original Message-
> From: sebgoa [mailto:run...@gmail.com]
> Sent: Sunday, June 08, 2014 4:52 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ACS44] 112 unpicked cherries in 4.4-forward. why?
>
>
> On Jun 8, 2014, at 5:31 AM, Sheng Yang  wrote:
>
>> To my understanding 4.4-forward is a staging tree for 4.4.1 release
>> currently, and only issues critical enough would go for 4.4 branch,
>
> I disagree. That makes things messy, 4.4-forward should only exist till 4.4 
> is out, really everything in 4.4-forward should go in 4.4.0.
> then folks commit to 4.4 for future bug fix releases...
>
> -sebastien
>
>
>> and
>> author would ask for pick up in that case. I think that's what's
>> happened with 4.3-forward branch.
>>
>> --Sheng
>>
>>
>> On Sat, Jun 7, 2014 at 3:05 PM, Sudha Ponnaganti <
>> sudha.ponnaga...@citrix.com> wrote:
>>
>>> Wondering why not baseline with 4.4-forward branch.
>>>
>>> -Original Message-
>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>>> Sent: Saturday, June 07, 2014 2:53 AM
>>> To: dev
>>> Subject: [ACS44] 112 unpicked cherries in 4.4-forward. why?
>>>
>>> H,
>>>
>>> To start with my personal finger pointing: especially test authors
>>> and UI devs seem to be to blame for the difference (and me of course).
>>> please take a moment to make sure your important work is not going to
>>> be lost for future generations.
>>>
>>> I am sure I did it way more complicated then needed but here it is:
>>>
>>> git config pretty.blame "format:blame %H '%aN <%aE>' - '%cn <%cE>' - '%s'"
>>> git cherry 4.4 4.4-forward | grep -e ^+ | cut -f 2 -d ' ' - | xargs
>>> -L
>>> 1 git show --pretty=blame | grep -e ^blame
>>>
>>> this gave me a nice list of commits that are not going into 4.4 as
>>> things are.
>>> There is some noise in there that might be filtered out by even more
>>> clever scripting on the output with ^- in the first grep command:
>>>
>>> 1. things that where picked the other way around for instance
>>>   fc52e641d8f69d8c0b552119203b0a2bc58e488f 'Daan Hoogland <
>>> d...@onecht.net>' - 'Daan Hoogland ' -
>>> 'try-with-resource to prevent resource leaks'
>>> 2. things that were reverted in the branch (8 occurs so that is a
>>> minus 16 dropping the number under 100)
>>>
>>> this leaves a lot of things though.
>>>
>>> Please have a look in the list below or execute the commands your
>>> self and decide what to do about them:
>>>
>>> blame 617826d16b4d5220bb3b51ed511b3c065d0e8926 'Koushik Das <
>>> kous...@apache.org>' - 'Daan Hoogland ' -
>>> 'CLOUDSTACK-6445: Simulator enhancements Refer FS -
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+enha
>>> ncements
>>> '
>>> blame 953167808c3e9a9c40a6f7be6e16ebf32c608a4c 'Jessica Wang <
>>> jessicaw...@apache.org>' - 'Jessica Wang ' -
>>> 'BUG-ID: CS-19795: UI > Add LDAP Account - fix a bug that a LDAP
>>> account that does not have email and all LDAP accounts below it are
>>> missing from the listing. Reviewed-by: Brian'
>>> blame a542b6fd825da1d3582a282bcc0e67abd62964bf 'Mike Tutkowski <
>>> mike.tutkow...@solidfire.com>' - 'Mike Tutkowski <
>>> mike.tutkow...@solidfire.com>' - 'CLOUDSTACK-6170 (VMware root-disk
>>> support for managed storage)'
>>> blame beb26237bceabfc3ebeae57431f9affb21d041e5 'Brian Federle <
>>> brian.fede...@citrix.com>' - 'Brian Federle
>>> ' - 'Create form: Store passed JSON object in 
>>> select options, for plugin use'
>>> blame 4a85e2226436c62e781db3449d262cb385b977c1 'Anshul Gangwar <
>>> anshul.gang...@citrix.com>' - 'Devdeep Singh ' -
>>> 'CLOUDSTACK-6470: while stopping vm in hyper-v, now we are first
>>> trying to shutdown it gracefully before turning it off forcefully'
>>> blame 66f8e0e1b5c81cbfde926c0c65c4d5969767cab9 'Anshul Gangwar <
>>> anshul.gang...@citrix.com>' - 'Devdeep Singh ' -
>>> 'CLOUDSTACK-6504: removed warnings coming in building hyper-v agent code'
>>> blame 5a49bb2db76f8dda9d41d9f700afd54d172ed415 'Sanjay Tripathi <
>>> sanjay.tripa...@citrix.com>' - 'Sanjay Tripathi <
>>> sanjay.tripa...@citrix.com>' - 'Fix log messages for vgpu creation.'
>>> blame 404ac549bfd84e97c756009f214e74cdb73548de 'SrikanteswaraRao
>>>

RE: ssvm logs

[Santhosh Edukulla]

Ekta,

If we don't have a resource, say hypervisor, storage etc, you can still play 
with cloudstack features using simulator.  Check the below link on running and 
using simulator. This way, you can play yourself and collect logs required.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Validating+check-ins+for+your+local+changes%2C+using+Simulator

You just need a simple linux machine\vm to start with.

Regards,
Santhosh

From: Ekta Agrawal [ektacloudst...@gmail.com]
Sent: Sunday, June 08, 2014 3:12 AM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: ssvm logs

HI,

I need logs for all functioning of ssvm, can somebody send the logs showing
all function which are happening properly.

if somebody can point the code of cloudstack , I  want  to understand logs
written for process of management and functioning done by ssvm .

Please help me if you can.


Regards,
Ekta

Re: [ACS44] 112 unpicked cherries in 4.4-forward. why?

[Mike Tutkowski]

Yes, there appears to be at least two lines of thought on x.y-forward
branches (specifically using 4.4-forward as an example here).

1) 4.4-forward and 4.4 should eventually be the same. Once the 4.4 release
goes out the door, 4.4-forward should be removed and changes for 4.4.1,
should such a release ever be made, should go into 4.4.

2) 4.4-forward contains changes that might go into 4.4 (if a cherry pick is
requested) and changes that would go into 4.4.1, should such a release ever
be made.

In both cases: Most all changes that go into 4.4-forward would need to go
into master (unless that part of the codebase in master has been modified
in such a way as to no longer make this 4.4-forward change relevant for
master).

We should gain some consensus on what x.y-forward means.


On Sun, Jun 8, 2014 at 10:51 AM, Daan Hoogland 
wrote:

> As I read your comments you actually don't agree with Sebastien,
> Sudha. 4.4-forward was cut of at code freeze. Since then fixes are
> committed there and cherry-pick are done by the RM. It seems that this
> is exactly what Sebastien meant it to be for.
>
> @Sebastien: in Shengs words I read that some of the things in
> 4.4-forward would only go in 4.4 after the release (thing with lower
> priority then critical)
>
> We all don't agree, let's agree on that.;}
>
> On Sun, Jun 8, 2014 at 2:27 PM, Sudha Ponnaganti
>  wrote:
> > Agree with Sebastien. 4.4 is cut too early. By cherry picking and
> missing some of the critical fixes in to 4.4, isn't it safe to baseline
> with 4.4-forward which has majority of the fixes. It is not like new
> features are added to 4.4 forward. Looks like most of them are fixes to
> existing functionality on 4.4.
> >
> > Thanks
> > /Sudha
> >
> > -Original Message-
> > From: sebgoa [mailto:run...@gmail.com]
> > Sent: Sunday, June 08, 2014 4:52 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [ACS44] 112 unpicked cherries in 4.4-forward. why?
> >
> >
> > On Jun 8, 2014, at 5:31 AM, Sheng Yang  wrote:
> >
> >> To my understanding 4.4-forward is a staging tree for 4.4.1 release
> >> currently, and only issues critical enough would go for 4.4 branch,
> >
> > I disagree. That makes things messy, 4.4-forward should only exist till
> 4.4 is out, really everything in 4.4-forward should go in 4.4.0.
> > then folks commit to 4.4 for future bug fix releases...
> >
> > -sebastien
> >
> >
> >> and
> >> author would ask for pick up in that case. I think that's what's
> >> happened with 4.3-forward branch.
> >>
> >> --Sheng
> >>
> >>
> >> On Sat, Jun 7, 2014 at 3:05 PM, Sudha Ponnaganti <
> >> sudha.ponnaga...@citrix.com> wrote:
> >>
> >>> Wondering why not baseline with 4.4-forward branch.
> >>>
> >>> -Original Message-
> >>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> >>> Sent: Saturday, June 07, 2014 2:53 AM
> >>> To: dev
> >>> Subject: [ACS44] 112 unpicked cherries in 4.4-forward. why?
> >>>
> >>> H,
> >>>
> >>> To start with my personal finger pointing: especially test authors
> >>> and UI devs seem to be to blame for the difference (and me of course).
> >>> please take a moment to make sure your important work is not going to
> >>> be lost for future generations.
> >>>
> >>> I am sure I did it way more complicated then needed but here it is:
> >>>
> >>> git config pretty.blame "format:blame %H '%aN <%aE>' - '%cn <%cE>' -
> '%s'"
> >>> git cherry 4.4 4.4-forward | grep -e ^+ | cut -f 2 -d ' ' - | xargs
> >>> -L
> >>> 1 git show --pretty=blame | grep -e ^blame
> >>>
> >>> this gave me a nice list of commits that are not going into 4.4 as
> >>> things are.
> >>> There is some noise in there that might be filtered out by even more
> >>> clever scripting on the output with ^- in the first grep command:
> >>>
> >>> 1. things that where picked the other way around for instance
> >>>   fc52e641d8f69d8c0b552119203b0a2bc58e488f 'Daan Hoogland <
> >>> d...@onecht.net>' - 'Daan Hoogland ' -
> >>> 'try-with-resource to prevent resource leaks'
> >>> 2. things that were reverted in the branch (8 occurs so that is a
> >>> minus 16 dropping the number under 100)
> >>>
> >>> this leaves a lot of things though.
> >>>
> >>> Please have a look in the list below or execute the commands your
> >>> self and decide what to do about them:
> >>>
> >>> blame 617826d16b4d5220bb3b51ed511b3c065d0e8926 'Koushik Das <
> >>> kous...@apache.org>' - 'Daan Hoogland ' -
> >>> 'CLOUDSTACK-6445: Simulator enhancements Refer FS -
> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+enha
> >>> ncements
> >>> '
> >>> blame 953167808c3e9a9c40a6f7be6e16ebf32c608a4c 'Jessica Wang <
> >>> jessicaw...@apache.org>' - 'Jessica Wang ' -
> >>> 'BUG-ID: CS-19795: UI > Add LDAP Account - fix a bug that a LDAP
> >>> account that does not have email and all LDAP accounts below it are
> >>> missing from the listing. Reviewed-by: Brian'
> >>> blame a542b6fd825da1d3582a282bcc0e67abd62964bf 'Mike Tutkowski <
> >>> mike.tutkow...@solidfire.com>' - 'Mike Tutkowski <
> >>> 

Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...

[Mike Tutkowski]

I agree that we should be using a process tool like Gerrit or Phabricator
with CloudStack.

Do you guys have a feel for how much work is involved if we decide to move
forward with using one of these tools?

I'm curious to see how disruptive it will be to our release schedule (if at
all), should we proceed forward with Gerrit or Phabricator.

Thanks!


On Sun, Jun 8, 2014 at 2:31 AM, Rohit Yadav  wrote:

> Hi Sheng,
>
> On Sun, Jun 8, 2014 at 8:57 AM, Sheng Yang  wrote:
>
> > Hi Rohit,
> >
> > Well, I don't quite understand why gerrit is "old". Google has a team
> > actively working on it and the release of new version seems pretty fast
> to
> > me(https://code.google.com/p/gerrit/, latest release at June(2.9-rc2)
> and
> > May(2.8.5) this year). Since Google, SAP and OpenStack are using it I
> don't
> > think quality or functionality would be an issue generally. The most
> > enticing feature of gerrit for me is itself is the repo, and you cannot
> go
> > around the gerrit to check in without proper process in any case.
> >
> > I didn't look into deep about Phabricator currently but I don't want to
> > bring "A is better than B" discussion at this moment. I think that can be
> > up to evaluation after we decided that test and review need to be
> enforced
> > through automation process.
>
>
> +1 can we have a PMC member to lead this effort and start discussion/voting
> on having a test/review process?
>
>
> > Which tool is best for that purpose can be up
> > to discuss.
> >
>
> Sure. This thread started like "Let's start using Gerrit", on the face
> value I thought it's like we've already considered which tool to use and we
> just want to start with setup/adoption process.
>
> By "old", I was implying low commit/development activity and
> technical/design debt it carries. Since I've used both of them (and
> Gitlab/Github) for writing real software, I'll list couple of specific pain
> points wrt code reviewing, but before that I would like everyone to try
> both of them before making mind;
>
> Try Gerrit2 with your github repo: http://gerrithub.io
> Explore Phabricator: https://secure.phabricator.com
>
> You may google to find reviews on both, I was going to write a comparative
> summary but this quora answer summarizes my pain points:
> http://qr.ae/sudCG
>
> Phabricator is more like a swiss knife but has three great tools inside it
> IMO useful for ACS like Differential (code reviews, pre-commit), Audit
> (review, post-commit), Arcanist (command line tool),  Herald (alarms on
> certain parts of code, such as db files etc.). Unnecessary features can be
> turned off.
>
> Arcanist is awesome, it speeds up the workflow of sending patch, testing
> it, merging it etc. The whole patch can be viewed in one tab, in-line
> comments work, the UI is much better, works better with JIRA/Confluence,
> they are opensource too and have a more active development community.
>
> Companies using Phabricator: http://leanstack.io/phabricator
> Code reviewing compared: http://leanstack.io/code-review
>
> I'm sharing my opinion just to help us consider best tool for the job and
> adopt it in future.
>
> Regards.
>
>
> > --Sheng
> >
> >
> > On Fri, Jun 6, 2014 at 10:48 PM, Rohit Yadav 
> wrote:
> >
> > > Hi,
> > >
> > > On Sat, Jun 7, 2014 at 4:56 AM, Sheng Yang  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Seems it's a good timing to bring back the discussion about the
> gerrit.
> > > >
> > > > We want to do CI, and improve our code quality. One obvious way of
> > doing
> > > > and reduce the workload of devs is introduce a tool to enforce the
> > > process.
> > > >
> > > > I've checked out quite a few projects using gerrit, which would force
> > you
> > > > to ask for review, and validation before the code can be committed to
> > the
> > > > repo. Looks it's really a easier way for devs according what I've
> > heard.
> > > >
> > > > Even our competitor laid out a very detail workflow based on the use
> of
> > > > gerrit( https://wiki.openstack.org/wiki/Gerrit_Workflow ). I guess
> it
> > > can
> > > > make a good reference.
> > > >
> > >
> > > I've used gerrit before, it's old and has its own pain points. I
> suppose
> > we
> > > need an on-premise solution that ASF infra folks can help setup for
> > > projects such as CloudStack.
> > >
> > > So, can we consider other/better opensource alternatives such as
> > > Phabricator (phabricator.org), I've used it before and it's great. It
> > > comes
> > > with a command line tool and a web ui for all tasks and comes with
> > > following stuff;
> > >
> > > - a command line tool (called archanist) which allows you to
> > > review/test/merge patches and while committing it hooks up linters and
> > unit
> > > testing
> > > - it allows you to audit patches i.e. review commits already pushed on
> a
> > > branch
> > > - it has alarms (herald) which can trigger on bunch of rules and alert
> us
> > > via email, for example if someone changes database files we can put an
> > > alarm on set of file

Re: [DISCUSS] extending the libvirt/KVM plugin to also support libvirt/Xen

[Wido den Hollander]

On 06/08/2014 06:23 PM, Dave Scott wrote:

Hi,

Following on from the earlier "[PROPOSAL] Support pure Xen as a hypervisor”, 
I’ve added a design doc to the wiki:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Allow+hosts+running+the+Xen+hypervisor+to+be+managed+via+libvirt

This design would allow people who want to manage their hypervisors purely 
through the libvirt tools to choose the Xen hypervisor.

 From the code point of view, I want to maximise sharing between the KVM and 
Xen code paths, partly to make QA easier and partly to maximise the chance that 
adding a feature for “Xen” causes it to work for “KVM” and vice-versa. In 
particular this means that, if a genuinely-useful capability is currently 
missing from the libvirt libxl driver, I want to implement it rather than work 
around it.



Seems like a great route to me! You also want to support Xen+Qemu with 
this way?


We have to be aware that there might be some storage differences between 
KVM and Xen like Ceph which is not fully supported yet by Xen.


If anything is missing in libvirt or the Java bindings we have to fix 
that indeed instead of hacking around it.


Wido


Comments appreciated!

Cheers,
Dave

[1] 
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201403.mbox/%3ccajgxtbnbmqtq81ralgh2kma7v5wjyzkr3xnyasmkc_br+uk...@mail.gmail.com%3e

RE: [MERGE] Review Request 22270: Xen 2 XenServer refactoring

[Santhosh Edukulla]

Logged a bug to track and fix devcloud issue.

https://issues.apache.org/jira/browse/CLOUDSTACK-6860

Santhosh


On Jun 6, 2014, at 3:53 PM, sebgoa  wrote:

>
> On Jun 6, 2014, at 9:35 PM, Rohit Yadav  wrote:
>
>>
>>
>>
>> On Sat, Jun 7, 2014 at 12:51 AM, sebgoa  wrote:
>>
>> On Jun 6, 2014, at 8:41 PM, Rohit Yadav  wrote:
>>
>>> Hi again,
>>>
>>> I was unable to deploy basic zone, I did:
>>>
>>> # marvin and python dependencies were pre-installed
>>> cd tools/devcloud;
>>> python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
>>>
>>> The error I got was related to agent communication, if this can help 
>>> resolve the issue:
>>> Exception Occurred :['Traceback (most recent call last):\n', '  File 
>>> "../marvin/marvin/deployDataCenter.py", line 136, in addHosts\nret = 
>>> self.__apiClient.addHost(hostcmd)\n', '  File 
>>> "/Library/Python/2.7/site-packages/Marvin-0.1.0-py2.7.egg/marvin/cloudstackAPI/cloudstackAPIClient.py",
>>>  line 1492, in addHost\nresponse = 
>>> self.connection.marvinRequest(command, response_type=response, 
>>> method=method)\n', '  File 
>>> "/Library/Python/2.7/site-packages/Marvin-0.1.0-py2.7.egg/marvin/cloudstackConnection.py",
>>>  line 378, in marvinRequest\nraise e\n', 'CloudstackAPIException: 
>>> Execute cmd: addhost failed, due to: errorCode: 530, errorText:Cannot 
>>> transit agent status with event AgentDisconnected for host 1, mangement 
>>> server id is 4278190080,Unable to transition to a new state from Creating 
>>> via AgentDisconnected\n']
>>>
>>
>> DevCloud is broken with 4.4 and master...
>>
>> o.O How do people test ACS who lack dedicated infrastructure? In that case, 
>> let's merge the patch?
>>
>
> I will wait till tomorrow morning, and merge then if no-one complained. This 
> will be a fast merge, but if people are not happy later on, I will revert.
>
> Tim went the extra mile to get this done, so I don't want to miss the window.
>
> -sebastien
>
>> Regards.
>>
>>
>>> But, in the management server log I see that it identified the product 
>>> version:
>>> "Found host devcloud ip=192.168.56.10 product version=1.6.0"
>>>
>>> In this case I'm suspecting my local env issue, the logs suggested it was 
>>> unable to create the directory "/opt/cloud/bin" and some agent exceptions.
>>>
>>> Tim, I think it works but failed on my env due to some env specific issue; 
>>> what modification etc. do we have to do to make it work against DevCloud, 
>>> or install libs/dependencies inside it?
>>>
>>> The patch is clean, builds and ACS runs and upon adding host it identified 
>>> and triggered the XenServer plugin so I think we can allow it to merge on 
>>> master (but we need to fix it to make it work with Xen.org xen server used 
>>> inside DevCloud using deployDataCenter script).
>>>
>>> If no one objects, may I merge it on master?
>>>
>>> Regards.
>>>
>>>
>>>
>>>
>>> On Fri, Jun 6, 2014 at 11:46 PM, Rohit Yadav  wrote:
>>> On Fri, Jun 6, 2014 at 10:14 PM, sebgoa  wrote:
>>> Folks,
>>>
>>> Tim has prepared a pretty significant patch in the review it lists below.
>>> There is also a wiki page describing the change.
>>>
>>> Basically it splits XenServer and XenProject (pure Xen) in two separate 
>>> hypervisors. Until now we had used XenServer to also handle XenProject.
>>> It will allow to split the way we connect to the two hypervisors.
>>>
>>> Now Tim's patch is actually a patch to *master* and not the xen2server 
>>> branch.
>>>
>>> Since it's a ton of work to rebase such a big refactoring, I am wondering 
>>> if we could not allow this patch to be applied in master directly.
>>> And apply quickly…we are 24 hours now since Tim sent his email, another 48 
>>> would make it 72.
>>>
>>> Thoughts ?
>>>
>>>
>>> +1 I just reviewed the patch, I was able to apply it cleanly on latest 
>>> master and successfully do a clean build. I next tested it with DevCloud 
>>> and currently in middle of deploying a basic zone. If if this fails, I 
>>> guess it looks good to me for merging, if there are some issues we can 
>>> always revisit.
>>>
>>> Command log:
>>> wget https://reviews.apache.org/r/22270/diff/raw/  -O xen-tim.patch # the 
>>> patch was about 1.8M in size
>>> cd cloudstack
>>> git pull --rebase origin master
>>> git am --ignore-whitespace ../xen-tim.patch
>>> mvn clean install -P systemvm,developer # build was successfully, the 
>>> plugin is now Hypervisor XenServer
>>> mvn -P developer -pl developer -Ddeploydb # clean db deployed successfully
>>> mvn -pl :cloud-client-ui jetty:run # UI was up, I'm now in middle of 
>>> deploying basic zone
>>>
>>> Regards.
>>>
>>>
>>>
>>>
>>>
>>> -sebastien
>>>
>>> On Jun 5, 2014, at 8:02 PM, Tim Mackey  wrote:
>>>
 I've just submitted a review request which is essentially a merge of
 the xen2server feature branch back into master.  Since this is a
 refactoring of the Xen plugin to make it more explicitly a XenServer
 plugin per the feature:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/C

Review Request 22356: Fixed few coverity issues reported

[Santhosh Edukulla]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22356/
---

Review request for cloudstack and daan Hoogland.


Repository: cloudstack-git


Description
---

Fixed few coverity issues reported for resource leak, value comparison, invalid 
loop check for result set.


Diffs
-

  engine/schema/src/com/cloud/upgrade/DatabaseCreator.java 91ef318 
  engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java c20a418 
  engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java 0761c9f 
  framework/db/src/com/cloud/utils/crypt/EncryptionSecretKeyChanger.java 
58584f9 
  framework/db/src/com/cloud/utils/db/Merovingian2.java 6eeea9f 
  framework/db/src/com/cloud/utils/db/ScriptRunner.java 6614527 
  framework/db/src/com/cloud/utils/db/TransactionLegacy.java ac0ea21 
  server/src/com/cloud/test/IPRangeConfig.java 1d56471 
  usage/src/com/cloud/usage/UsageSanityChecker.java 5e6123b 
  utils/src/com/cloud/utils/crypt/EncryptionSecretKeySender.java 086e8a8 

Diff: https://reviews.apache.org/r/22356/diff/


Testing
---

1.Built the code and found no issues.
2.Built the simulator and ran a deploy datacenter with the changes.


Thanks,

Santhosh Edukulla

Re: [DISCUSS] extending the libvirt/KVM plugin to also support libvirt/Xen

[Dave Scott]

Hi Wido,

Thanks for your mail!

On 8 Jun 2014, at 19:02, Wido den Hollander  wrote:

> On 06/08/2014 06:23 PM, Dave Scott wrote:
>> Hi,
>> 
>> Following on from the earlier "[PROPOSAL] Support pure Xen as a hypervisor”, 
>> I’ve added a design doc to the wiki:
>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Allow+hosts+running+the+Xen+hypervisor+to+be+managed+via+libvirt
>> 
>> This design would allow people who want to manage their hypervisors purely 
>> through the libvirt tools to choose the Xen hypervisor.
>> 
>> From the code point of view, I want to maximise sharing between the KVM and 
>> Xen code paths, partly to make QA easier and partly to maximise the chance 
>> that adding a feature for “Xen” causes it to work for “KVM” and vice-versa. 
>> In particular this means that, if a genuinely-useful capability is currently 
>> missing from the libvirt libxl driver, I want to implement it rather than 
>> work around it.
>> 
> 
> Seems like a great route to me! You also want to support Xen+Qemu with this 
> way?

Yes, it should be possible to run fully virtualised VMs with Xen + Qemu. I 
think we’ll be able to choose whether to run VMs as PV or HVM.

> We have to be aware that there might be some storage differences between KVM 
> and Xen like Ceph which is not fully supported yet by Xen.

Ceph is an interesting one. Xen itself doesn’t know anything about storage— 
instead the dom0 takes care of it either via a kernel driver (blkback) or 
userspace program (qemu or tapdisk). When I tried to make Ceph work about a 
year ago[1] I hit a bug in libxl (the Xen control library). The good news is 
the fix made it into Xen 4.4, so with luck we can get it to work.


> If anything is missing in libvirt or the Java bindings we have to fix that 
> indeed instead of hacking around it.

Great :)

Cheers,
Dave

[1] 
http://xenserver.org/discuss-virtualization/virtualization-blog/entry/tech-preview-of-xenserver-libvirt-ceph.html

> 
> Wido
> 
>> Comments appreciated!
>> 
>> Cheers,
>> Dave
>> 
>> [1] 
>> http://mail-archives.apache.org/mod_mbox/cloudstack-users/201403.mbox/%3ccajgxtbnbmqtq81ralgh2kma7v5wjyzkr3xnyasmkc_br+uk...@mail.gmail.com%3e
>> 

Re: Need help on the CS First class object hiding feature.

[Girish Chaudhari]

Hi Nitin,

Can you please reply back to my previous mail thread.

As well like to update you that I have even tried this feature with
Networks object. Even in this case, I could set the display flag as
'0', it get hided from normal users as well admin user similar to what
I have mentioned above for virtual machine.

Thanks,
Girish

On Thu, Jun 5, 2014 at 9:18 AM, Girish Chaudhari
 wrote:
> Thanks Nitin for immediate response.
>
> "... I see that some more first class entities have gotten added but
> the underlying concept remains the same."
>
> => Can you please name the newly added first class entities if
> possible, or what could be the best way to figure it out.
>  Is there any criteria which is used to decided whether particular CS
> resource is first class candidate or not. Or every resource can be
> taken as first class object and hiding can be applied to it.
> Can you please let me know what steps/efforts will be involved in
> hiding new CS first class object using this feature?
>
> "I would think that would be a bug. Please file it and I will try and
> look into it."
>
> => I will double check on it and try the same steps with another
> mentioned resource. Will file the bug accordingly.
>
>>Also like to check whether Admin can update this feature flags or
>>provide the meta data through UI?
>
>
> "Yes, admin can update the display flag during creation time or using
> update apis. Check deployvm and updateVm apis."
>
> -> You mean to say current CS UI(4.3 or upcoming 4.4) has ability to
> mark the existing VM as hidden or create new VM with hide flag? I
> could try it, using API programatically only.
>
> As well I have follow up extended questions as:
>
> Do this feature only applied to Root Admin vs the users Or even
> equally applied to "Any Sub Domain Admin User" vs its non admin users?
>
>
> Thanks,
> Girish
>
> On Wed, Jun 4, 2014 at 8:19 PM, Nitin Mehta  wrote:
>>
>>
>> On 04/06/14 4:52 AM, "Girish Chaudhari" 
>> wrote:
>>
>>>Hi Team,
>>>
>>>I am looking into the CS first class object hiding feature to verify
>>>how the Admin user has better control over the display of CS resources
>>>to end users.
>>>
>>>The only reference link I could find is
>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+bet
>>>ter+control+over+first+class+objects+in+CS
>>>
>>>Is there any other documentation available around this feature
>>>providing more use cases and examples..etc.
>>
>> This is the functional spec and should provide you most of the
>> information. I see that some more first class entities have gotten added
>> but the underlying concept remains the same.
>>
>>>
>>>Whereas I have tried to verify this feature by creating the
>>>resources(VM) by Admin and associated it with the account. In usual
>>>case Account user as well the admin user can retrieve the VM using the
>>>listVMs call. When I am trying to set the display_vm flag as false, as
>>>expected the account user don't see the VM. But even the Admin user
>>>can't see the VM in list.
>>>
>>>Not sure whether I am following the right steps or its buggy behavior.
>>
>> I would think that would be a bug. Please file it and I will try and look
>> into it.
>>
>>
>>
>>>
>>>Also like to check whether Admin can update this feature flags or
>>>provide the meta data through UI?
>>
>> Yes, admin can update the display flag during creation time or using
>> update apis. Check deployvm and updateVm apis
>>
>>>
>>>Curious to know whether anyone is using this feature in production and
>>>how?
>>>
>>>Thanks,
>>>Girish
>>

RE: [ANNOUNCE] Demetrius Tsitrelis as committer

[Suresh Sadhu]

Congratulations Demetrius!

-sadhu
-Original Message-
From: John Kinsella [mailto:j...@stratosec.co] 
Sent: Friday, June 06, 2014 4:18 PM
To: 
Subject: [ANNOUNCE] Demetrius Tsitrelis as committer

Folks - this one's a little belated - we went through the invite process around 
the time of the mail issues, and somehow we didn't send the announcement to 
dev@.
I noticed while doing some housekeeping this week, and wanted to send out the 
announcement anyways just to give Demetrius the recognition. :)

The Project Management Committee (PMC) for Apache CloudStack has asked 
Demetrius Tsitrelis to become a committer and we are pleased to announce that 
he has accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Demetrius!

-John, on behalf of the CloudStack PMC

Re: [ANNOUNCE] Demetrius Tsitrelis as committer

[Jayapal Reddy Uradi]

Congratulations Demetrius!

On 07-Jun-2014, at 4:47 AM, John Kinsella  wrote:

> Folks - this one’s a little belated - we went through the invite process 
> around the
> time of the mail issues, and somehow we didn’t send the announcement to dev@.
> I noticed while doing some housekeeping this week, and wanted to send out the
> announcement anyways just to give Demetrius the recognition. :)
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Demetrius Tsitrelis to become a committer and we are pleased to announce
> that he has accepted.
> 
> Being a committer allows many contributors to contribute more autonomously. 
> For
> developers, it makes it easier to submit changes and eliminates the need to
> have contributions reviewed via the patch submission process. Whether
> contributions are development-related or otherwise, it is a recognition of a
> contributor's participation in the project and commitment to the project and
> the Apache Way.
> 
> Please join me in congratulating Demetrius!
> 
> -John, on behalf of the CloudStack PMC

2014-6-09 Japanese CloudStack Community Weekly Update

[Mayumi K]

Hi everyone

Activities of Japanese CloudStack Community.

## Event

[6/12] JCSUG will hold a Meet-up in Hokkaido
[6/13] Interop Tokyo 2014 : JCSUG will have a session.
http://www.interop.jp/2014/index2.html
[6/14] OSC Hokkaido: JCSUG will have a session and booth.
[6/22] July Tech Festa : JCSUG will have a session.
http://2014.techfesta.jp/

[7/04] JCSUG will hold a Meet-up in Nagoya
[7/05] OSC Nagoya: JCSUG will have a session and booth.

[8/02] OSC Kansai@kyoto: JCSUG will have a session and booth.

If you have any comment, please let ad...@cloudstack.jp know.

Thanks,
JCSUG (Japan CloudStack User Group)
Mayumi Koshimizu (samem...@gmail.com)

--
Web: http://cloudstack.jp
Ustream http://www.ustream.tv/channel/cloudstackja
Twitter: @cloudstackja
Facebook: https://www.facebook.com/cloudstackjapan
Admin ML: ad...@cloudstack.jp
User ML: us...@cloudstack.jp

Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...

[Rohit Yadav]

Hi,

On Sun, Jun 8, 2014 at 11:19 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I agree that we should be using a process tool like Gerrit or Phabricator
> with CloudStack.
>
> Do you guys have a feel for how much work is involved if we decide to move
> forward with using one of these tools?
>

IMO -- We should first have voting/decisions regarding this (heya PMC
folks!), the tools and timelines. Next, the ASF infra team can be requested
provision servers to setup Gerrit or Phabricator or anything else for that
matter (with a CI if we want unit testing automation for each commit or
periodically), and have CloudStack repos linked to it. After that we'll
need to setup wikis and documentation regarding the new process and educate
and influence everyone to start using it.


> I'm curious to see how disruptive it will be to our release schedule (if at
> all), should we proceed forward with Gerrit or Phabricator.
>

We can start with master and leave 4.4 and other branches. It should not
hinder our release schedules.

IMO we should allow committers to bypass code reviews for trivial changes
and things that they own or have expertise of, to cut time and to not force
process on people.

Regards.


>
> Thanks!
>
>
> On Sun, Jun 8, 2014 at 2:31 AM, Rohit Yadav  wrote:
>
> > Hi Sheng,
> >
> > On Sun, Jun 8, 2014 at 8:57 AM, Sheng Yang  wrote:
> >
> > > Hi Rohit,
> > >
> > > Well, I don't quite understand why gerrit is "old". Google has a team
> > > actively working on it and the release of new version seems pretty fast
> > to
> > > me(https://code.google.com/p/gerrit/, latest release at June(2.9-rc2)
> > and
> > > May(2.8.5) this year). Since Google, SAP and OpenStack are using it I
> > don't
> > > think quality or functionality would be an issue generally. The most
> > > enticing feature of gerrit for me is itself is the repo, and you cannot
> > go
> > > around the gerrit to check in without proper process in any case.
> > >
> > > I didn't look into deep about Phabricator currently but I don't want to
> > > bring "A is better than B" discussion at this moment. I think that can
> be
> > > up to evaluation after we decided that test and review need to be
> > enforced
> > > through automation process.
> >
> >
> > +1 can we have a PMC member to lead this effort and start
> discussion/voting
> > on having a test/review process?
> >
> >
> > > Which tool is best for that purpose can be up
> > > to discuss.
> > >
> >
> > Sure. This thread started like "Let's start using Gerrit", on the face
> > value I thought it's like we've already considered which tool to use and
> we
> > just want to start with setup/adoption process.
> >
> > By "old", I was implying low commit/development activity and
> > technical/design debt it carries. Since I've used both of them (and
> > Gitlab/Github) for writing real software, I'll list couple of specific
> pain
> > points wrt code reviewing, but before that I would like everyone to try
> > both of them before making mind;
> >
> > Try Gerrit2 with your github repo: http://gerrithub.io
> > Explore Phabricator: https://secure.phabricator.com
> >
> > You may google to find reviews on both, I was going to write a
> comparative
> > summary but this quora answer summarizes my pain points:
> > http://qr.ae/sudCG
> >
> > Phabricator is more like a swiss knife but has three great tools inside
> it
> > IMO useful for ACS like Differential (code reviews, pre-commit), Audit
> > (review, post-commit), Arcanist (command line tool),  Herald (alarms on
> > certain parts of code, such as db files etc.). Unnecessary features can
> be
> > turned off.
> >
> > Arcanist is awesome, it speeds up the workflow of sending patch, testing
> > it, merging it etc. The whole patch can be viewed in one tab, in-line
> > comments work, the UI is much better, works better with JIRA/Confluence,
> > they are opensource too and have a more active development community.
> >
> > Companies using Phabricator: http://leanstack.io/phabricator
> > Code reviewing compared: http://leanstack.io/code-review
> >
> > I'm sharing my opinion just to help us consider best tool for the job and
> > adopt it in future.
> >
> > Regards.
> >
> >
> > > --Sheng
> > >
> > >
> > > On Fri, Jun 6, 2014 at 10:48 PM, Rohit Yadav 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Sat, Jun 7, 2014 at 4:56 AM, Sheng Yang  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Seems it's a good timing to bring back the discussion about the
> > gerrit.
> > > > >
> > > > > We want to do CI, and improve our code quality. One obvious way of
> > > doing
> > > > > and reduce the workload of devs is introduce a tool to enforce the
> > > > process.
> > > > >
> > > > > I've checked out quite a few projects using gerrit, which would
> force
> > > you
> > > > > to ask for review, and validation before the code can be committed
> to
> > > the
> > > > > repo. Looks it's really a easier way for devs according what I've
> > > heard.
> > > > >
> > > > > Even our competi

Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...

[Mike Tutkowski]

I think it would be nice, as well, if committers could bypass the process
for trivial changes and - as you say - areas they own or have expertise in,
but we should also have a somewhat clear divide between what qualifies to
bypass the process and what doesn't.

Let's see how much debate this thread generates and then we can talk about
voting on it a bit later - if it sounds like something people are
interested in.


On Sun, Jun 8, 2014 at 11:31 PM, Rohit Yadav  wrote:

> Hi,
>
> On Sun, Jun 8, 2014 at 11:19 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > I agree that we should be using a process tool like Gerrit or Phabricator
> > with CloudStack.
> >
> > Do you guys have a feel for how much work is involved if we decide to
> move
> > forward with using one of these tools?
> >
>
> IMO -- We should first have voting/decisions regarding this (heya PMC
> folks!), the tools and timelines. Next, the ASF infra team can be requested
> provision servers to setup Gerrit or Phabricator or anything else for that
> matter (with a CI if we want unit testing automation for each commit or
> periodically), and have CloudStack repos linked to it. After that we'll
> need to setup wikis and documentation regarding the new process and educate
> and influence everyone to start using it.
>
>
> > I'm curious to see how disruptive it will be to our release schedule (if
> at
> > all), should we proceed forward with Gerrit or Phabricator.
> >
>
> We can start with master and leave 4.4 and other branches. It should not
> hinder our release schedules.
>
> IMO we should allow committers to bypass code reviews for trivial changes
> and things that they own or have expertise of, to cut time and to not force
> process on people.
>
> Regards.
>
>
> >
> > Thanks!
> >
> >
> > On Sun, Jun 8, 2014 at 2:31 AM, Rohit Yadav  wrote:
> >
> > > Hi Sheng,
> > >
> > > On Sun, Jun 8, 2014 at 8:57 AM, Sheng Yang  wrote:
> > >
> > > > Hi Rohit,
> > > >
> > > > Well, I don't quite understand why gerrit is "old". Google has a team
> > > > actively working on it and the release of new version seems pretty
> fast
> > > to
> > > > me(https://code.google.com/p/gerrit/, latest release at
> June(2.9-rc2)
> > > and
> > > > May(2.8.5) this year). Since Google, SAP and OpenStack are using it I
> > > don't
> > > > think quality or functionality would be an issue generally. The most
> > > > enticing feature of gerrit for me is itself is the repo, and you
> cannot
> > > go
> > > > around the gerrit to check in without proper process in any case.
> > > >
> > > > I didn't look into deep about Phabricator currently but I don't want
> to
> > > > bring "A is better than B" discussion at this moment. I think that
> can
> > be
> > > > up to evaluation after we decided that test and review need to be
> > > enforced
> > > > through automation process.
> > >
> > >
> > > +1 can we have a PMC member to lead this effort and start
> > discussion/voting
> > > on having a test/review process?
> > >
> > >
> > > > Which tool is best for that purpose can be up
> > > > to discuss.
> > > >
> > >
> > > Sure. This thread started like "Let's start using Gerrit", on the face
> > > value I thought it's like we've already considered which tool to use
> and
> > we
> > > just want to start with setup/adoption process.
> > >
> > > By "old", I was implying low commit/development activity and
> > > technical/design debt it carries. Since I've used both of them (and
> > > Gitlab/Github) for writing real software, I'll list couple of specific
> > pain
> > > points wrt code reviewing, but before that I would like everyone to try
> > > both of them before making mind;
> > >
> > > Try Gerrit2 with your github repo: http://gerrithub.io
> > > Explore Phabricator: https://secure.phabricator.com
> > >
> > > You may google to find reviews on both, I was going to write a
> > comparative
> > > summary but this quora answer summarizes my pain points:
> > > http://qr.ae/sudCG
> > >
> > > Phabricator is more like a swiss knife but has three great tools inside
> > it
> > > IMO useful for ACS like Differential (code reviews, pre-commit), Audit
> > > (review, post-commit), Arcanist (command line tool),  Herald (alarms on
> > > certain parts of code, such as db files etc.). Unnecessary features can
> > be
> > > turned off.
> > >
> > > Arcanist is awesome, it speeds up the workflow of sending patch,
> testing
> > > it, merging it etc. The whole patch can be viewed in one tab, in-line
> > > comments work, the UI is much better, works better with
> JIRA/Confluence,
> > > they are opensource too and have a more active development community.
> > >
> > > Companies using Phabricator: http://leanstack.io/phabricator
> > > Code reviewing compared: http://leanstack.io/code-review
> > >
> > > I'm sharing my opinion just to help us consider best tool for the job
> and
> > > adopt it in future.
> > >
> > > Regards.
> > >
> > >
> > > > --Sheng
> > > >
> > > >
> > > > On Fri, Jun 6, 2014 at 10:48 PM, Rohit Yadav 

Re: [DISCUSS] extending the libvirt/KVM plugin to also support libvirt/Xen

[Wido den Hollander]

On 06/08/2014 11:14 PM, Dave Scott wrote:

Hi Wido,

Thanks for your mail!

On 8 Jun 2014, at 19:02, Wido den Hollander  wrote:


On 06/08/2014 06:23 PM, Dave Scott wrote:

Hi,

Following on from the earlier "[PROPOSAL] Support pure Xen as a hypervisor”, 
I’ve added a design doc to the wiki:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Allow+hosts+running+the+Xen+hypervisor+to+be+managed+via+libvirt

This design would allow people who want to manage their hypervisors purely 
through the libvirt tools to choose the Xen hypervisor.

 From the code point of view, I want to maximise sharing between the KVM and 
Xen code paths, partly to make QA easier and partly to maximise the chance that 
adding a feature for “Xen” causes it to work for “KVM” and vice-versa. In 
particular this means that, if a genuinely-useful capability is currently 
missing from the libvirt libxl driver, I want to implement it rather than work 
around it.



Seems like a great route to me! You also want to support Xen+Qemu with this way?


Yes, it should be possible to run fully virtualised VMs with Xen + Qemu. I 
think we’ll be able to choose whether to run VMs as PV or HVM.


Ok, but those will be different code paths at some level.




We have to be aware that there might be some storage differences between KVM 
and Xen like Ceph which is not fully supported yet by Xen.


Ceph is an interesting one. Xen itself doesn’t know anything about storage— 
instead the dom0 takes care of it either via a kernel driver (blkback) or 
userspace program (qemu or tapdisk). When I tried to make Ceph work about a 
year ago[1] I hit a bug in libxl (the Xen control library). The good news is 
the fix made it into Xen 4.4, so with luck we can get it to work.



When Xen runs with Qemu as full HVM it's Qemu which takes care of the 
Ceph storage, so in that case it's fixed.


I haven't got a lot of experience with PV Xen. I heard stories of Ceph 
being integrated in blktap(2), but never tested it.





If anything is missing in libvirt or the Java bindings we have to fix that 
indeed instead of hacking around it.


Great :)

Cheers,
Dave

[1] 
http://xenserver.org/discuss-virtualization/virtualization-blog/entry/tech-preview-of-xenserver-libvirt-ceph.html



Wido


Comments appreciated!

Cheers,
Dave

[1] 
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201403.mbox/%3ccajgxtbnbmqtq81ralgh2kma7v5wjyzkr3xnyasmkc_br+uk...@mail.gmail.com%3e

Review Request 22364: Fixed 26 issues reported by coverity

[Rajani Karuturi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22364/
---

Review request for cloudstack and Kelven Yang.


Repository: cloudstack-git


Description
---

NPEs, unused code or dead code, unwritten field access and self assignment


Diffs
-

  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 8ca7d1e 

Diff: https://reviews.apache.org/r/22364/diff/


Testing
---


Thanks,

Rajani Karuturi