Re: Unable to upload SSL certificate

[Amogh Vasekar]

Hi,

The commit below actually ensures parity between API and UI calls, in
absence of which API calls will fail. Additionally, without it POST calls
will fail.
Please do send a note in case reverting part of the commit.

I believe Saksham has removed the double decoding for the API, which seems
the right fix.

Thanks,
Amogh


On 6/5/14 8:44 AM, "Wei ZHOU"  wrote:

>To make it works on UI, I suggest to revert part of source code in this
>commit
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=b8
>a1cbe;hp=beb26237bceabfc3ebeae57431f9affb21d041e5
>
>-Wei
>
>
>2014-06-05 16:23 GMT+02:00 Saksham Srivastava
>>:
>
>> Syed,
>>
>> The certificate in the mentioned call is already UTF-8 encoded of the
>>raw
>> plain-text certificate.
>> To make the api work I had to doubly encode the cert and key .
>>
>> I guess it will be good to have this mentioned in the FS/docs as there
>>is
>> no UI for this and also a sample api call can help a lot.
>>
>> Thanks,
>> Saksham
>>
>> -Original Message-
>> From: Syed Ahmed [mailto:sah...@cloudops.com]
>> Sent: Thursday, June 5, 2014 6:23 AM
>> To: Saksham Srivastava
>> Cc: Vijay Venkatachalam; dev@cloudstack.apache.org
>> Subject: Re: Unable to upload SSL certificate
>>
>> Can you try to encode the certificate before passing it as the param?
>>
>> -Syed
>>
>> On Wed 04 Jun 2014 09:01:19 AM EDT, Saksham Srivastava wrote:
>> > Adding Syed,
>> >
>> > I debugged the issue and here are my findings:
>> >
>> > The api is failing at CertServiceimpl: parseCertificate()
>> >
>> > return (Certificate) certPem.readObject();
>> >
>> > readObject method is failing.
>> >
>> > I tried to use the certificate used in the test
>> > runUploadSslCertSelfSignedWithPassword and other tests in
>> CertServiceTest.java The following is the api call:
>> >
>> > http://10.x.x.x:8096/client/api?command=uploadSslCert&certificate=
>> > -BEGIN+CERTIFICATE-%0AMIIDBjCCAe4CCQD5Q6qF5dVV0jANBgkqhkiG9w0BAQUF
>> > ADBFMQswCQYDVQQGEwJB%0AVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW5
>> > 0ZXJuZXQgV2lkZ2l0%0AcyBQdHkgTHRkMB4XDTEzMTAyMTEzNTgwNFoXDTE0MTAyMTEzNT
>> > gwNFowRTELMAkG%0AA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMG
>> > EludGVybmV0%0AIFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
>> > AQoCggEB%0AAN%2F7lJtiEs68IC1ZPxY9NA34z9T4AU4LPS%2FkbQtuxx4X72XOBy%2By0
>> > cB%2FqdMD7JNV%0Ah8Mq4URDljhSDyVPdH%2F%2BjQr%2B7kWx2gNe2R%2FDCnd%2FmeVw
>> > wU30JJvpGVZXt%2BMTef5N%0AQAbSfDMsuT4FaUY80InbDd24HelrjwunPdY9wwKXO6zL2
>> > fLjyDRediiydxcx18Vb%0ADq1cm7DRi4mNkmA3RwBQMhxGp3VsfXJ4Hy2WTRCCCxWHZphA
>> > h3EUJGK3idum6%2F7j%0AHbAwpM%2Ft1kNWN8PZiYDZ1HbccgjmqB7Cub10BfB9g1RByiQ
>> > %2FC87o5cKtQha3uuXR%0AiBcHISoDydQrgxKgUpiqEF0CAwEAATANBgkqhkiG9w0BAQUF
>> > AAOCAQEASvulIaVb%0Azh8z2TysE6RFoYTAYIRXghFrmqCUyyQmUVTvs6vN8iaSXr%2BWM
>> > QJcpgXewWcFrDhr%0AmIcyRCvF91ZYb7q6lMZFSpE6u%2FSUGIEtxGUDAfbkbQdKYmrMcb
>> > ggUUIvSzgUFisO%0A
>>
>> 
>>Kr0H9PEO4AWtCCrtOJFc7jgu03Sv06wDxn9ghkyiBRnVkbAhoKfKnI179yKruJWR%0AA3ieEj
>>0eFoUbeSH8hDkToj4ynpkAvEGoHjHG9j%2B8FJxy%2FPTjkyVPl1ykTs%2B2Jc1B%0ASnx8f2
>>afdTenPWyyBm3wFuRZjEAJJLUO0kxM7E8hAwhGsr%2BXYanwcr1oA1dz6M3f%0Acq26lpjTH5
>>ITwQ%3D%3D%0A-END+CERTIFICATE-%0A&privatekey=-BEGIN+RSA+PRIVA
>>TE+KEY-%0AProc-Type%3A+4%2CENCRYPTED%0ADEK-Info%3A+DES-EDE3-CBC%2CCCA
>>6E4CB4C4039DD%0A%0ATaVCJtB0dE9xTZbX7GOaGJwwGHVAMjU1GbRIHf0jODdP%2BquZvbjk
>>lNqsw8Ozlia9%0Aq%2FG%2BUqtRJGlIPPLpce0YCrTo0P3eixZdMs0%2BhioAEJ4OLtL0SAC6
>>b8q%2FgB6HRfAx%0ABvNg%2BumTqeF9YB68Tcuv%2F2g4VGKiaePQACyOzMdf7lGY7ojxoJCY
>>Za1mfKb7jWrg%0AFLwmTtLLhNjb6CnOKo3klIef3A6zdutpgxF1gARzdRyXg4qCA3boYnwEpt
>>TOlJFu%0AovxbhDG9iuYYr4gXYSs1pLYptEC8J6iWpG%2Fqzkwfr4l5Cfg5uF00bbxQE5%2BW
>>eRaj%0AYFicvXjB%2FkcoFZuCL7M%2FYRXYxkJ%2FEZ19xI9HZNBQ4L738StkSBKL4OhpF%2F
>>qgYZ2y%0AZLRV6XT4AijUA0Ef7YTuUsTL7Qt9drj09gCtAzXTA7gpZBn5SqT9kWhuwSzY302l
>>%0AKF8DIC6A52igk2QKPLbleM%2FV8eCu6n%2BJ4uF%2B0GwVRROuG7ThxAQiUlJKhoEYrndL
>>%0AnzT7jHVLftjilhVWFu2On62bRf5t1QZuob%2B1AdK0ukvEI
>>
>> 
>>VsYnN4bnlAkc99Wi6C0%0AZJd9qW5L4A9XAC2gcjr3m0Rzw3RO%2Bk17faR8YfmTuJvGyBf5f
>>nrSFoNkrninXQXp%0Ask0ajRi4PJ4XTswLyxjWRSt3egNsZBSKnVCibca%2FQoDEdZHSKXo2F
>>lYiUYx8JHQX%0ASPUsLl9OQKC1W8%2F%2BReryqBLHCkiGEsvT8gVaXga0uhVaqe%2BPaVur2
>>tbOHl4yCysC%0A%2BZlnKwsC84LQsUvpENdCh%2BD7E1I1Rao9IJMR6q9azKq8Ck63cOJ1fA9
>>xSnxJGoCA%0AIlGLttlXrR32EtzYwEnlqf1nI%2FIqNQrAXQKrP5VPzHsgMFu5uD4OEZa92Q5
>>cVTsz%0Aap%2F1UEqiJVYUt6nuA%2BaqOUlyjC0oNtYL%2FVO4DbHTFcHa8SI2cPSS6ebPMWP
>>GHjUm%0Al9bWa6Q9iyplCYS6hinAVsAaLVjPi1Eu9Pc8rxFCmoiJYJju5NZuGI5UBK64dqcX%
>>0AT6trWl0kB8QY63JtnrZaoStoSPImV5KVseUKDV8TM3Y76h1nLV3MSmAD1ivk9oKs%0AVKeV
>>rDhZBWUq9Dqre%2F%2BlVGO0a2wo5VTR8hfpf8QkODPLeyNZNdfGKzkkFLuXa8V5%0AELhLQJ
>>3FnbEU3NEvMwikV9MhP%2FELPTkZwJr%2FNKv%2B9JLs9eXtwz29I%2FQ8byQVrCCs%0AhAuD
>>l0zHGRnqdpdSImeS2EXGx631zGMwSe8fhKelni5h6hXrXz52asr0k30BxWjf%0AWUn1uTInwV
>>jWGy9B5j3mZlVDotFbvVAZgtR0IoFwihPl4VZd9oS13l%2BhMfrTy1YZ%0A8xFNg8ZqUQ0lSm
>>KfOVqSBT0lP8tM8LuGxgY4cWluhsAQxR5Nl7wkundnqjcwEDDu%0AJz2rD54St1EZYGLDJZSf
>>C7mpG2PgodsdeopQCTyFhHWa8s3caZ40GFOwaR%2B%2F5%2BYF

Re: Review Request 22452: CLOUDSTACK-6872 : removed the redundant connectToRemote method

[Anshul Gangwar]

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

(Updated June 11, 2014, 7:31 a.m.)


Review request for cloudstack, Devdeep Singh and Rajesh Battala.


Changes
---

Removed other redundant method DisconnectRemote


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


Repository: cloudstack-git


Description
---

Removed the redundant connectTORemote method in Hyper-v Agent. We dont't need 
this method as share is domain joined so it has all the required permissions. 
Removal of this method fixes this bug also.


Diffs (updated)
-

  
plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs
 0ad95b8 
  plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs 
c8e951e 
  plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 
372f848 

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


Testing
---

tested that volume operations are working fine after removal of this method


Thanks,

Anshul Gangwar

irc meeting on rvr4vpc

[Daan Hoogland]

H,

We had a little meeting on the state of this feature and the way to go. I have 
no karma for ASFBot meetings so here is my excerpt from the transcript:

Attendance:
K3KH Karl Harris
Yasker Sheng Yang
Spark404 Hugo Trippaers
echaz Eric Chazas
LeoSimons Leo Simons
dahn Daan Hoogland

others where present in the room but not active in the meeting

Agenda:
-  Feasibility experiment plans by Schuberg Philis
-  Reusable work by Karl
-  Problems Citrix encountered with the regular redundant router (and 
how to avoid them)
-  Work division
-  (next meeting needed?)

We tried to follow the agenda but were not very strict on it. I'll summarize 
outcome per agenda bullet:

Schuberg Philis wants to implement a feasibility redundant router on a 
simulated vpc environment using the operational expertise it has in house. The 
outcome would then be back ported to the device, it's agent and the management 
server.

The implementation tactics is to create a json like configuration description 
and to let the device do its own configuration. The idea is to have a single 
device for normal and vpc routers and to let the redundancy be a mere property 
of it. This should lead to the ultimate objective which is to have a single 
relatively simple maintainable device.

Karl will describe his endeavors in adapting the existing device on list.

Sheng described the QA problems Citrix had with the existing redundant 
capabilities of the VR and assured us that only one real problem persists. The 
failover time of 3 seconds occasionally leads to a split brain which leads to 
two VR's assuming the role of master. As the management server in a busy 
environment can take up to 30 seconds the to detect a failover this can lead to 
unacceptable outage. One possible solution, to have the management server serve 
as negotiator on such occasions, will be hard to implement due to this latency. 
Noticeably both routers use the same mac address on the interface to the load 
balancer.

The resources available by Citrix are uncertain. Plan and design needs to be 
done. It is agreed that we will work in parallel (Schuberg Philis and Citrix) 
but keep in close contact. The amount of resources Sungard has for this is not 
discussed. Karl will keep involved.

We agreed to have a next meeting at 20:00 UTC on June the 17th

Can someone give me Karma to use ASFBot for this one, please?

\DaanH

Re: unused private methods in VirtualMachinManagerImpl

[Daan Hoogland]

is there one availible or are we implementing @usedPrivate ?

On Wed, Jun 11, 2014 at 2:54 AM, Mike Tutkowski
 wrote:
> Good idea
>
> On Tuesday, June 10, 2014, Kelven Yang  wrote:
>
>> Maybe utilizing special java annotation would get developer heads-up?
>> Content in comments text is easily skipped as it is not usually considered
>> as mandatory language constructs
>>
>> Kelven
>>
>> On 6/10/14, 4:25 PM, "Mike Tutkowski" 
>> wrote:
>>
>> >I haven't looked, but perhaps we should provide sufficient comments in
>> >each
>> >of these cases so no one removes the fields thinking that they are old and
>> >no longer in use.
>> >
>> >
>> >On Tue, Jun 10, 2014 at 5:13 PM, Kelven Yang 
>> >wrote:
>> >
>> >> The usage of these private methods are through reflection, making it
>> >> private is to avoid exposing unnecessary internal structures to outside.
>> >>
>> >> Kelven
>> >>
>> >> On 6/10/14, 2:46 AM, "Rajani Karuturi" 
>> >>wrote:
>> >>
>> >> >Hi Kelven,
>> >> >while fixing some of the issues reported by coverity I encountered some
>> >> >unused private methods in VirtualMachineManagerImpl.java
>> >> >(https://reviews.apache.org/r/22364 ) and removed them. Koushik
>> pointed
>> >> >that they are getting used by the job framework.
>> >> >Looks like these are used by the job framework by making them public
>> >> >through reflection and following some convention for the function
>> >>names.
>> >> >
>> >> >Its very difficult to find the usages or refactor which can have some
>> >> >unforeseen consequences.
>> >> >
>> >> >Can you share some details about them? probably some javadoc?
>> >> >
>> >> >
>> >> >~Rajani
>> >> >
>> >> >
>> >> >
>> >> >On 10-Jun-2014, at 12:37 pm, Koushik Das 
>> >>wrote:
>> >> >
>> >> >>
>> >> >> ---
>> >> >> This is an automatically generated e-mail. To reply, visit:
>> >> >> https://reviews.apache.org/r/22364/#review45200
>> >> >> ---
>> >> >>
>> >> >>
>> >> >>
>> >> >> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
>> >> >> 
>> >> >>
>> >> >>These methods are getting used by the job framework. Check
>> >> >>handleVmWorkJob() method in the same java file.
>> >> >>
>> >> >>
>> >> >> - Koushik Das
>> >> >>
>> >> >>
>> >> >> On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
>> >> >>>
>> >> >>> ---
>> >> >>> This is an automatically generated e-mail. To reply, visit:
>> >> >>> https://reviews.apache.org/r/22364/
>> >> >>> ---
>> >> >>>
>> >> >>> (Updated June 10, 2014, 4:06 a.m.)
>> >> >>>
>> >> >>>
>> >> >>> Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik
>> >> >>>Das, and Santhosh Edukulla.
>> >> >>>
>> >> >>>
>> >> >>> 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
>> >> >>>25c67db
>> >> >>>
>> >> >>> Diff: https://reviews.apache.org/r/22364/diff/
>> >>*Mike Tutkowski*
>> >*Senior CloudStack Developer, SolidFire Inc.*
>> >e: mike.tutkow...@solidfire.com 
>> >o: 303.746.7302
>> >Advancing the way the world uses the cloud
>> >* *
>>
>>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*



-- 
Daan

Re: [ACS4.4]Cherry-pick 09a357fb90b48ed6e2725ea60e632a2ad5529f79

[Daan Hoogland]

On Wed, Jun 11, 2014 at 3:00 AM, Min Chen  wrote:
> 09a357fb90b48ed6e2725ea60e632a2ad5529f79


is in

-- 
Daan

Re: Anybody addressing this bug ? Overlaping IP subnets across different vlans

[Andrija Panic]

It was not there pre 4.3, and it's just causing me problems, I had to
manually add database entries to vlan and user_ip_address tables, not very
convinient...
Thanks,
Andrija


On 11 June 2014 02:45, Chiradeep Vittal  wrote:

> Not sure what this has to do with Portable IP. But I agree that the check
> should be removed.
>
> From: ilya musayev  ilya.mailing.li...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Date: Friday, June 6, 2014 at 10:38 AM
> To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Subject: Re: Anybody addressing this bug ? Overlaping IP subnets across
> different vlans
>
> Andrija
>
> I dont know if we can qualify this as a bug, this check was placed with
> some purpose in mind - yet its not clear what it is and why would
> someone think its bad.
>
>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=a3b1a49c303a929c754561ca07fd8a9ed84e0382
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-3911
>
> Chime in on the discussion in thread above,
>
> Regards,
> ilya
>
>
> On 6/6/14, 5:48 AM, Andrija Panic wrote:
> Hi,
> aftger upgrade to 4.3, I reported a bug where CS will not let me add
> additional IP ranges when there are 2 vlans using same IP range - I
> don't see point comparing IP ranges across two separate broadcast
> domains...
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-6814
>
> Thanks,
>
>
>


-- 

Andrija Panić
--
  http://admintweets.com
--

Re: [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins

[Wido den Hollander]

On 06/11/2014 12:26 AM, Mike Tutkowski wrote:

Hi,

Please feel free to review the following proposal for 4.5:

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111



Is this what we discussed at CCC13 in Amsterdam? Seems like it!

I'm in favor, since this could add a lot of potentials to the Ceph 
storage as well.


Wido


Here is the summary:

Today the way you associate a Compute Offering (CO) or a Disk Offering (DO)
with a Primary Storage (PS) is via storage tagging.

This has some benefits and drawbacks.

One benefit is being able to have some level of vendor independence from
the point of view of the CO or DO. For example, if the storage tag of a DO
is "Fast", then this can be satisfied by PS that describes itself as
"Fast", regardless of vendor.

A major drawback with the storage-tagging approach, however, is that you
are not easily able to leverage vendor-specific features, which is often
why you bought storage from the vendor in question to begin with.

Ideally we do not want to add each vendor's features into the system as
properties that can be seen by the admin regardless of whether or not the
underlying storage he's actually using supports the feature in question.
Traditionally, however, this has been business as usual in the CloudStack
codebase.

Going forward, we want to implement a more fine-grain and generic approach.

For example, in the GUI we would like to have a storage provider field for
the CO and DO windows (this equates to the name of one and only one storage
provider). If the admin inputs a specific storage provider, he can enter in
an arbitrary number of key/value pairs in another text field (perhaps we
would provide a nice entry dialog to make this easier in the GUI). These
key value pairs can be passed into the storage driver when it's asked to
create (or update) a volume and the storage driver can decide what each and
every key/value pair means, if anything.

Thanks!

Review Request 22454: Fixed few coverity reported issues

[Rajani Karuturi]

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

Review request for cloudstack, daan Hoogland, Koushik Das, and Santhosh 
Edukulla.


Repository: cloudstack-git


Description
---

unused assignments, boxing and unboxing of values etc.


Diffs
-

  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 55736f9 

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


Testing
---


Thanks,

Rajani Karuturi

Re: Anybody addressing this bug ? Overlaping IP subnets across different vlans

[Murali Reddy]

This is not related to portable IP. This enforcement was added as part of
commit 657d9e4789d73c7c8ed460e59f088b8cb9aa7697.

Anothony might have context for this check.

On 11/06/14 2:18 PM, "Andrija Panic"  wrote:

>It was not there pre 4.3, and it's just causing me problems, I had to
>manually add database entries to vlan and user_ip_address tables, not very
>convinient...
>Thanks,
>Andrija
>
>
>On 11 June 2014 02:45, Chiradeep Vittal 
>wrote:
>
>> Not sure what this has to do with Portable IP. But I agree that the
>>check
>> should be removed.
>>
>> From: ilya musayev > ilya.mailing.li...@gmail.com>>
>> Reply-To: "dev@cloudstack.apache.org"
>><
>> dev@cloudstack.apache.org>
>> Date: Friday, June 6, 2014 at 10:38 AM
>> To: "dev@cloudstack.apache.org" <
>> dev@cloudstack.apache.org>
>> Subject: Re: Anybody addressing this bug ? Overlaping IP subnets across
>> different vlans
>>
>> Andrija
>>
>> I dont know if we can qualify this as a bug, this check was placed with
>> some purpose in mind - yet its not clear what it is and why would
>> someone think its bad.
>>
>>
>> 
>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=a3b1a
>>49c303a929c754561ca07fd8a9ed84e0382
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-3911
>>
>> Chime in on the discussion in thread above,
>>
>> Regards,
>> ilya
>>
>>
>> On 6/6/14, 5:48 AM, Andrija Panic wrote:
>> Hi,
>> aftger upgrade to 4.3, I reported a bug where CS will not let me add
>> additional IP ranges when there are 2 vlans using same IP range - I
>> don't see point comparing IP ranges across two separate broadcast
>> domains...
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6814
>>
>> Thanks,
>>
>>
>>
>
>
>-- 
>
>Andrija Panić
>--
>  http://admintweets.com
>--
>

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

[Hugo Trippaers]

Sheng,

In the end we both want the same thing, which is a higher quality codebase. 
However i find the technology first approach the wrong approach in this case. 
Of course supporting tools are needed to make the process more efficient. My 
main worry here is that the “experts” are not reviewing commits now, why should 
they start when we have a system like Gerrit in place. As long as all our 
committers don’t take the time to review commits coming into CloudStack, no 
amount of tooling is going to help improve the code base. It is my opinion that 
such tooling will not be beneficial to our community unless there is a great 
willingness to review commits, which there isn’t at the moment. Most of the 
bugs are currently found during the QA phase, which means that they were not 
found by our committers who have the responsibility to review every incoming 
commit. (Don’t get me wrong, i’m blaming myself as much as anybody else)

The next point is the concept of experts. We ask people to become committers 
because we trust them to act responsibly with regards to the code base. That 
means they know what they should or shouldn’t commit. We should not introduce 
another level of committers without very carefully thinking about what the 
criteria are for that particular level and what the responsibilities are. 

In short, lets show the community that our “experts” are actively reviewing 
incoming commits and start improving the code base today so we can support them 
with additional tooling tomorrow. These are some things that we can do without 
having gerrit and/or PR.
 * Discus commits on the dev list openly so other people can learn from 
commonly made mistakes.
 * Review changes and branches proactively and engage with the contributors
 * Document intricacies in the codebase that will likely stump new committers.
 * Refactor code that is not easily maintainable.

If we get there, i’m all for setting up whatever tooling we need to facilitate 
this, but don’t let the absence of such tooling be an excuse for not doing what 
we should be doing.

Cheers,

Hugo


P.S. This is an entirely different discussion than replacing RB with another 
tool for contributors. Completely +1 to using github PRs or Gerrit for new 
contributions.

On 11 jun. 2014, at 00:56, Sheng Yang  wrote:

> Hi Hugo,
> 
> The main point I want to bring up an automation tool here is, enforce
> mandatory review process and test(regression test probably) to happen
> before commit. That would slow down the process of course, but it should
> greatly help on code quality.
> 
> Even committers would make mistakes from time to time. By adding and
> enforce the review process, we would able to a. reduce the obvious bugs or
> potential impact on issues author didn't know about, b. transfer the
> knowledge for the project. I really think CloudStack would going to be a
> more mature project in the future, but our current develop process is too
> random and fail to take the whole control of the quality. By specifying
> people in the area to review we should able to spot error better in the
> early stage.
> 
> I know integrating the tool would change how people working on project,
> since review and testing would be a necessary part of it. The problem now
> is a. committers can still push bad commits without reviewing by experts in
> the subsystem, b. current reviewboard is too primitive and overhead for
> uploading, updating and applying the patch is too big, and c. reviewboard
> is not mandatory. I would like to have devs spend more time on reviewing,
> by this way at least we can gain a kind of control over the code base we're
> working on.
> 
> And correct tool would be important to cut the overhead of our development
> process, which can make people more focus on real work.
> 
> In conclusion, I'd like to advocate the enforced(by tool) mandatory
> review(and testing integration of course) for every commits, and I think
> the correct tool is important in this case.
> 
> --Sheng
> 
> 
> On Mon, Jun 9, 2014 at 11:22 PM, Hugo Trippaers  wrote:
> 
>> Hey,
>> 
>> I’m all for automated solutions. I’m a happy gerrit user on some other
>> projects and quite fond of working with Github pull requests as well.
>> However there is one important point that makes working with those tools
>> work and that is a willingness by the committers to review requests. Both
>> systems rely on either a well functioning and fast CI system or committers
>> that consistently and rapidly review requests. Where the latter is actually
>> the most important one.
>> 
>> Both gerrit and pull requests do not improve quality. They are just tools
>> to facilitate a certain way of working. If we want to improve quality we
>> have to do it ourselves, no amount of automated tooling is going to solve
>> it for us. As committers it is our job to review commits and make sure that
>> quality is maintained. It is also our job to make sure that automated tests
>> exist that will catch problems.
>> 
>

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

[Stephen Turner]

I think I agree with both of you! In the end, it's a social problem, of 
actually getting round to doing the reviews: but better tools can help to 
encourage that.  For example, on github, the code review is integrated into the 
source control: every change is a pull request, and someone has to press the 
big green button, which acts as a sign-off. Whereas, Review Board may be 
slightly klunky and adding friction into the process, thus deterring people 
from doing code review. But even given the best tools in the world, someone 
still has to do the work...

-- 
Stephen Turner


-Original Message-
From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: 11 June 2014 10:52
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using 
continuous integration to maintain our code quality...

Sheng,

In the end we both want the same thing, which is a higher quality codebase. 
However i find the technology first approach the wrong approach in this case. 
Of course supporting tools are needed to make the process more efficient. My 
main worry here is that the "experts" are not reviewing commits now, why should 
they start when we have a system like Gerrit in place. As long as all our 
committers don't take the time to review commits coming into CloudStack, no 
amount of tooling is going to help improve the code base. It is my opinion that 
such tooling will not be beneficial to our community unless there is a great 
willingness to review commits, which there isn't at the moment. Most of the 
bugs are currently found during the QA phase, which means that they were not 
found by our committers who have the responsibility to review every incoming 
commit. (Don't get me wrong, i'm blaming myself as much as anybody else)

The next point is the concept of experts. We ask people to become committers 
because we trust them to act responsibly with regards to the code base. That 
means they know what they should or shouldn't commit. We should not introduce 
another level of committers without very carefully thinking about what the 
criteria are for that particular level and what the responsibilities are. 

In short, lets show the community that our "experts" are actively reviewing 
incoming commits and start improving the code base today so we can support them 
with additional tooling tomorrow. These are some things that we can do without 
having gerrit and/or PR.
 * Discus commits on the dev list openly so other people can learn from 
commonly made mistakes.
 * Review changes and branches proactively and engage with the contributors
 * Document intricacies in the codebase that will likely stump new committers.
 * Refactor code that is not easily maintainable.

If we get there, i'm all for setting up whatever tooling we need to facilitate 
this, but don't let the absence of such tooling be an excuse for not doing what 
we should be doing.

Cheers,

Hugo


P.S. This is an entirely different discussion than replacing RB with another 
tool for contributors. Completely +1 to using github PRs or Gerrit for new 
contributions.

On 11 jun. 2014, at 00:56, Sheng Yang  wrote:

> Hi Hugo,
> 
> The main point I want to bring up an automation tool here is, enforce 
> mandatory review process and test(regression test probably) to happen 
> before commit. That would slow down the process of course, but it 
> should greatly help on code quality.
> 
> Even committers would make mistakes from time to time. By adding and 
> enforce the review process, we would able to a. reduce the obvious 
> bugs or potential impact on issues author didn't know about, b. 
> transfer the knowledge for the project. I really think CloudStack 
> would going to be a more mature project in the future, but our current 
> develop process is too random and fail to take the whole control of 
> the quality. By specifying people in the area to review we should able 
> to spot error better in the early stage.
> 
> I know integrating the tool would change how people working on 
> project, since review and testing would be a necessary part of it. The 
> problem now is a. committers can still push bad commits without 
> reviewing by experts in the subsystem, b. current reviewboard is too 
> primitive and overhead for uploading, updating and applying the patch 
> is too big, and c. reviewboard is not mandatory. I would like to have 
> devs spend more time on reviewing, by this way at least we can gain a 
> kind of control over the code base we're working on.
> 
> And correct tool would be important to cut the overhead of our 
> development process, which can make people more focus on real work.
> 
> In conclusion, I'd like to advocate the enforced(by tool) mandatory 
> review(and testing integration of course) for every commits, and I 
> think the correct tool is important in this case.
> 
> --Sheng
> 
> 
> On Mon, Jun 9, 2014 at 11:22 PM, Hugo Trippaers  wrote:
> 
>> Hey,
>> 
>> I'm all for automated s

Re: Review Request 22232: Fix for test_01_create_volume to use the correct volume name for KVM

[SrikanteswaraRao Talluri]

> On June 10, 2014, 10:21 a.m., SrikanteswaraRao Talluri wrote:
> > for future review requests, please create a bug in issues.apache.org and 
> > add it to the review request.

master cdfa2650602fd03df266b3edb5591e5d96eb248b
4.4-forward 280d167316d92a8d24d0917f8945b408b87677a8


- SrikanteswaraRao


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


On June 10, 2014, 10:09 a.m., Alex Brett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22232/
> ---
> 
> (Updated June 10, 2014, 10:09 a.m.)
> 
> 
> Review request for cloudstack and SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> test_01_create_volume was expecting the new volume to appears as /dev/sda 
> when running on KVM (as this is the default volume used in 
> util.checkVolumeSize), whereas it actually appears as /dev/vdb.
> 
> This patch determines the appropriate volume name in the same way as we do 
> for XenServer, and uses that instead.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_volumes.py 73c2722 
> 
> Diff: https://reviews.apache.org/r/22232/diff/
> 
> 
> Testing
> ---
> 
> Verified the test now passes when running against a KVM host.
> 
> 
> Thanks,
> 
> Alex Brett
> 
>

Review Request 22355: Fixed vm ha cases failing in master

[Santhosh Edukulla]

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

Review request for cloudstack and SrikanteswaraRao Talluri.


Repository: cloudstack-git


Description
---

vm ha cases were failing in master. Fixed it.


Diffs
-

  test/integration/smoke/test_vm_ha.py f549243 
  tools/marvin/marvin/config/test_data.py 0a5762d 

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


Testing
---


Thanks,

Santhosh Edukulla

Re: Review Request 22355: Fixed vm ha cases failing in master

[Santhosh Edukulla]

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

(Updated June 11, 2014, 10:57 a.m.)


Review request for cloudstack and SrikanteswaraRao Talluri.


Repository: cloudstack-git


Description
---

vm ha cases were failing in master. Fixed it.


Diffs (updated)
-

  test/integration/smoke/test_vm_ha.py f549243 
  tools/marvin/marvin/config/test_data.py 0a5762d 

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


Testing
---


Thanks,

Santhosh Edukulla

Review Request 22456: CLOUDSTACK-6869: Public key content is overridden by template's meta data when you create a instance

[Harikrishna Patnala]

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

Review request for cloudstack and Kishan Kavala.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-6869: Public key content is overridden by template's meta data when 
you create a instance


Diffs
-

  server/src/com/cloud/template/TemplateManagerImpl.java 3ebb43a 
  server/src/com/cloud/vm/UserVmManagerImpl.java 14d2eef 

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


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request 22355: Fixed vm ha cases failing in master

[SrikanteswaraRao Talluri]

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

Ship it!


master 31d870933dcc39a5886ea0f6c93b9718c33ac9aa

- SrikanteswaraRao Talluri


On June 11, 2014, 10:57 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22355/
> ---
> 
> (Updated June 11, 2014, 10:57 a.m.)
> 
> 
> Review request for cloudstack and SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> vm ha cases were failing in master. Fixed it.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_vm_ha.py f549243 
>   tools/marvin/marvin/config/test_data.py 0a5762d 
> 
> Diff: https://reviews.apache.org/r/22355/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Santhosh Edukulla
> 
>

Re: Review Request 22356: Fixed few coverity issues reported

[daan Hoogland]

> On June 10, 2014, 12:20 p.m., daan Hoogland wrote:
> > engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java, line 136
> > 
> >
> > a commit in a finally when try-with-resource used seems not what you 
> > want. What do you expect to be committed here?
> 
> Santhosh Edukulla wrote:
> Mentioned transaction logic mentioned seems to be our own implementation. 
> I have seen changing these commits\close at places leads to issues. Though 
> connection is getting auto closed, "assuming" a transaction can have multiple 
> connections and especially shared with scope across process, transaction 
> commit  seems ok. So, earlier i didn't delved in too much details, 
> transaction start and commit seems reasonable,  went to keep it like that.  
> 
> There are few places where this piece of code was used. With this fix, I 
> touched to see where leaks are there, and fixed. Went conservative at places, 
> cautious not to introduce regression issues. If we agree, i will still keep 
> it like this. Changing these at all places, may be like like additional 
> refactoring, making sure our own implementation of transaction works\breaks 
> and require thorough testing. Let me know your thoughts.

I certainly don't agree. A transaction that does an unconditional commit in a 
finally makes no sense. If the problem is that our Transaction doesn't 
implement Closable we should make it implement that interface. It already 
implements close() so this is no big change. At the end of regular execution 
the commit should be done, not in the finally. The exception handlers should do 
a rollback().

I realize that this is not entirely new in your code but it is a big bug and as 
you do touch the contents of the finally clause, please fix. (A little fix I 
think)


- daan


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


On June 11, 2014, 6:43 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22356/
> ---
> 
> (Updated June 11, 2014, 6:43 a.m.)
> 
> 
> 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: Review Request 22456: CLOUDSTACK-6869: Public key content is overridden by template's meta data when you create a instance

[Kishan Kavala]

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

Ship it!


Ship It!

- Kishan Kavala


On June 11, 2014, 4:35 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22456/
> ---
> 
> (Updated June 11, 2014, 4:35 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6869
> https://issues.apache.org/jira/browse/CLOUDSTACK-6869
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6869: Public key content is overridden by template's meta data 
> when you create a instance
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/template/TemplateManagerImpl.java 3ebb43a 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 14d2eef 
> 
> Diff: https://reviews.apache.org/r/22456/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 22456: CLOUDSTACK-6869: Public key content is overridden by template's meta data when you create a instance

[ASF Subversion and Git Services]

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


Commit aa75b4388554a502b1073dd78050cd4b364a803e in cloudstack's branch 
refs/heads/4.4-forward from Harikrishna Patnala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa75b43 ]

CLOUDSTACK-6869: SSH Public key content is overridden by template's meta data 
when you create a instance


- ASF Subversion and Git Services


On June 11, 2014, 11:05 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22456/
> ---
> 
> (Updated June 11, 2014, 11:05 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6869
> https://issues.apache.org/jira/browse/CLOUDSTACK-6869
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6869: Public key content is overridden by template's meta data 
> when you create a instance
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/template/TemplateManagerImpl.java 3ebb43a 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 14d2eef 
> 
> Diff: https://reviews.apache.org/r/22456/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 22456: CLOUDSTACK-6869: Public key content is overridden by template's meta data when you create a instance

[ASF Subversion and Git Services]

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


Commit 522208dec2f81997c8b14d820c4f3f1be958ee44 in cloudstack's branch 
refs/heads/master from Harikrishna Patnala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=522208d ]

CLOUDSTACK-6869: SSH Public key content is overridden by template's meta data 
when you create a instance


- ASF Subversion and Git Services


On June 11, 2014, 11:05 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22456/
> ---
> 
> (Updated June 11, 2014, 11:05 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6869
> https://issues.apache.org/jira/browse/CLOUDSTACK-6869
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6869: Public key content is overridden by template's meta data 
> when you create a instance
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/template/TemplateManagerImpl.java 3ebb43a 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 14d2eef 
> 
> Diff: https://reviews.apache.org/r/22456/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

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

[Daan Hoogland]

Stephen, github would be nice if it was running under the apache
umbrella. We still need to download a patch and apply and push it to
wip...

But most importantly and as you pointed out, we still need to look at
the code before pushing anything of any color.

On Wed, Jun 11, 2014 at 12:04 PM, Stephen Turner
 wrote:
> I think I agree with both of you! In the end, it's a social problem, of 
> actually getting round to doing the reviews: but better tools can help to 
> encourage that.  For example, on github, the code review is integrated into 
> the source control: every change is a pull request, and someone has to press 
> the big green button, which acts as a sign-off. Whereas, Review Board may be 
> slightly klunky and adding friction into the process, thus deterring people 
> from doing code review. But even given the best tools in the world, someone 
> still has to do the work...
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: 11 June 2014 10:52
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using 
> continuous integration to maintain our code quality...
>
> Sheng,
>
> In the end we both want the same thing, which is a higher quality codebase. 
> However i find the technology first approach the wrong approach in this case. 
> Of course supporting tools are needed to make the process more efficient. My 
> main worry here is that the "experts" are not reviewing commits now, why 
> should they start when we have a system like Gerrit in place. As long as all 
> our committers don't take the time to review commits coming into CloudStack, 
> no amount of tooling is going to help improve the code base. It is my opinion 
> that such tooling will not be beneficial to our community unless there is a 
> great willingness to review commits, which there isn't at the moment. Most of 
> the bugs are currently found during the QA phase, which means that they were 
> not found by our committers who have the responsibility to review every 
> incoming commit. (Don't get me wrong, i'm blaming myself as much as anybody 
> else)
>
> The next point is the concept of experts. We ask people to become committers 
> because we trust them to act responsibly with regards to the code base. That 
> means they know what they should or shouldn't commit. We should not introduce 
> another level of committers without very carefully thinking about what the 
> criteria are for that particular level and what the responsibilities are.
>
> In short, lets show the community that our "experts" are actively reviewing 
> incoming commits and start improving the code base today so we can support 
> them with additional tooling tomorrow. These are some things that we can do 
> without having gerrit and/or PR.
>  * Discus commits on the dev list openly so other people can learn from 
> commonly made mistakes.
>  * Review changes and branches proactively and engage with the contributors
>  * Document intricacies in the codebase that will likely stump new committers.
>  * Refactor code that is not easily maintainable.
>
> If we get there, i'm all for setting up whatever tooling we need to 
> facilitate this, but don't let the absence of such tooling be an excuse for 
> not doing what we should be doing.
>
> Cheers,
>
> Hugo
>
>
> P.S. This is an entirely different discussion than replacing RB with another 
> tool for contributors. Completely +1 to using github PRs or Gerrit for new 
> contributions.
>
> On 11 jun. 2014, at 00:56, Sheng Yang  wrote:
>
>> Hi Hugo,
>>
>> The main point I want to bring up an automation tool here is, enforce
>> mandatory review process and test(regression test probably) to happen
>> before commit. That would slow down the process of course, but it
>> should greatly help on code quality.
>>
>> Even committers would make mistakes from time to time. By adding and
>> enforce the review process, we would able to a. reduce the obvious
>> bugs or potential impact on issues author didn't know about, b.
>> transfer the knowledge for the project. I really think CloudStack
>> would going to be a more mature project in the future, but our current
>> develop process is too random and fail to take the whole control of
>> the quality. By specifying people in the area to review we should able
>> to spot error better in the early stage.
>>
>> I know integrating the tool would change how people working on
>> project, since review and testing would be a necessary part of it. The
>> problem now is a. committers can still push bad commits without
>> reviewing by experts in the subsystem, b. current reviewboard is too
>> primitive and overhead for uploading, updating and applying the patch
>> is too big, and c. reviewboard is not mandatory. I would like to have
>> devs spend more time on reviewing, by this way at least we can gain a
>> kind of control over the code base we're working on.
>>
>> And cor

RE: KVM + LXC on the same host

[Kishan Kavala]

KVM system vms on the same host as LXC containers is already supported.
Below proposal was to support userVms in a similar way.

> -Original Message-
> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> Sent: Wednesday, 11 June 2014 5:57 AM
> To: dev@cloudstack.apache.org
> Subject: Re: KVM + LXC on the same host
> 
> I thought the LXC 2.0 project uses KVM system vms on the same host as LXC
> containers?
> https://cwiki.apache.org/confluence/x/oJNMAg
> 
> From: Kishan Kavala
> mailto:kishan.kav...@citrix.com>>
> Reply-To: "dev@cloudstack.apache.org"
> mailto:dev@cloudstack.apache.org>>
> Date: Sunday, June 8, 2014 at 11:59 PM
> To: "dev@cloudstack.apache.org"
> mailto:dev@cloudstack.apache.org>>
> Subject: RE: KVM + LXC on the same host
> 
> 
> 
> -Original Message-
> From: ilya musayev [mailto:ilya.mailing.li...@gmail.com]
> Sent: Saturday, 7 June 2014 1:50 AM
> To: dev@cloudstack.apache.org
> Subject: Re: KVM + LXC on the same host
> Tuna
> Thanks for the feedback, conceptually, i was not trying to address the issue 
> of
> sysvms not running on LXC.
> Here is the use case as i see it.
> Assume you roll out a farm of  10 KVM servers and your density with KVM is
> 200 virtual machines. Most of these VMs dont require independent kernel
> and additional layers of virtualization abstraction. As the result, you can 
> place
> 400 LXC machines and 20 fully virtualized Linux or even Windows Servers. If
> you do chargeback, you can offer the LXC machines for much lower price point
> since we can place more LXC containers.
> Your density becomes much greater with LXC and yet you still cover the
> corner case when end-user needs KVM instance.
> Pierre-Luc
> If I will get to try this scenario - i may have to alter the KVM/LXC agent
> somewhat to make it work with CloudStack, i will let you know.
> Ilya,
> Some minor changes to KVM/LXC agent will be required to make this work.
> Below piece of code in createVMFromSpec (LibvirtComputingResource),
> deploys systems Vms in KVM and user Vms in LXC.
> If we include some flag in VirtualMachineTO, it should be possible to specify
> which userVm has to be deployed (KVM/LXC).
> 
> if (HypervisorType.LXC == _hypervisorType && VirtualMachine.Type.User
> == vmTO.getType()) {
> // LXC domain is only valid for user VMs. Use KVM for system VMs.
> guest.setGuestType(GuestDef.guestType.LXC);
> vm.setHvsType(HypervisorType.LXC.toString().toLowerCase());
> } else {
> guest.setGuestType(GuestDef.guestType.KVM);
> vm.setHvsType(HypervisorType.KVM.toString().toLowerCase());
> vm.setLibvirtVersion(_hypervisorLibvirtVersion);
> vm.setQemuVersion(_hypervisorQemuVersion);
> }
> 
> 
> 
> Alternative solution would be to run separate LXC and KVM clusters, which is
> also a possibility - but usage and distribution will be uneven.
> Regards
> ilya
> The concept of combining both technologies under one hypervisor On 6/6/14,
> 8:42 AM, Pierre-Luc Dion wrote:
> > ilya,
> >
> > Let us know how it goes your hybrid of LXC+KVM. I'm interested to know
> > how it's going,  I might try that too on the side.
> >
> >
> >
> >
> > Pierre-Luc Dion
> > Architecte de Solution Cloud | Cloud Solutions Architect 855-OK-CLOUD
> > (855-652-5683) x1101
> > - - -
> >
> > *CloudOps*420 rue Guy
> > Montréal QC  H3J 1S6
> > www.cloudops.com
> > @CloudOps_
> >
> >
> > On Fri, Jun 6, 2014 at 10:53 AM, Nguyen Anh Tu
> mailto:t...@apache.org>> wrote:
> >
> >> That should be a good idea, Ilya. At that moment, i'm working on
> >> Docker support. When it's done, we can run only Docker hosts, no need
> >> to use KVM for hosting system vms.
> >>
> >> Cheers,
> >> --Tuna
> >>
> >> Sent from my GT-N7000
> >> On Jun 5, 2014 7:58 AM, "ilya musayev"
> >> mailto:ilya.mailing.li...@gmail.com>>
> >> wrote:
> >>
> >>> We are considering running KVM and LXC on the same host and
> >>> hopefully control both through cloudstack.
> >>>
> >>> I know there are agents involved for each component, i dont know if
> >>> we
> >> can
> >>> have a hybrid of LXC+KVM.
> >>>
> >>> The use case is simple, we would like the end user to pick
> >>> LXC/Docker for performance, or KVM instance if he really needed all
> >>> bells and whistles
> >> of
> >>> dedicated kernel in fully virtualized environment.
> >>>
> >>> Is anyone aware why we should not mix 2 workloads on the same host?
> >>> Is it possible at this point in time to mix LXC, KVM and CloudStack,
> >>> i assume
> >> the
> >>> answer is no, but perhaps there is a hack i can try.
> >>>
> >>> Thanks
> >>> ilya
> >>>
> 

Re: Review Request 22356: Fixed few coverity issues reported

[Santhosh Edukulla]

> On June 10, 2014, 12:20 p.m., daan Hoogland wrote:
> > engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java, line 136
> > 
> >
> > a commit in a finally when try-with-resource used seems not what you 
> > want. What do you expect to be committed here?
> 
> Santhosh Edukulla wrote:
> Mentioned transaction logic mentioned seems to be our own implementation. 
> I have seen changing these commits\close at places leads to issues. Though 
> connection is getting auto closed, "assuming" a transaction can have multiple 
> connections and especially shared with scope across process, transaction 
> commit  seems ok. So, earlier i didn't delved in too much details, 
> transaction start and commit seems reasonable,  went to keep it like that.  
> 
> There are few places where this piece of code was used. With this fix, I 
> touched to see where leaks are there, and fixed. Went conservative at places, 
> cautious not to introduce regression issues. If we agree, i will still keep 
> it like this. Changing these at all places, may be like like additional 
> refactoring, making sure our own implementation of transaction works\breaks 
> and require thorough testing. Let me know your thoughts.
> 
> daan Hoogland wrote:
> I certainly don't agree. A transaction that does an unconditional commit 
> in a finally makes no sense. If the problem is that our Transaction doesn't 
> implement Closable we should make it implement that interface. It already 
> implements close() so this is no big change. At the end of regular execution 
> the commit should be done, not in the finally. The exception handlers should 
> do a rollback().
> 
> I realize that this is not entirely new in your code but it is a big bug 
> and as you do touch the contents of the finally clause, please fix. (A little 
> fix I think)

Ok,  in general this is what this behavior should be. Anyways,below are what we 
wanted.

1. So, move txn commit to end of try block and retain txn close in finally? 
2. Regarding rollback, do we need rollback in outer catch? Again, rollback can 
lead to exception, so try\catch again? once it is in outer catch, the required 
resources to rollback are anyways autoclosed or not available for rolling back 
anything? so, rollback is not required in catch?yes\no? 


- Santhosh


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


On June 11, 2014, 6:43 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22356/
> ---
> 
> (Updated June 11, 2014, 6:43 a.m.)
> 
> 
> 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
> 
>

CLOUDSTACK-6825 changed to critical

[Daan Hoogland]

LS,

I have changed a issue marked blocker to critical. It had no developer
assigned. Until it has backing of a committed developer I can not let
the release be stopped by such an issue.

-- 
Daan

CLOUDSTACK-6842 blocker to critical

[Daan Hoogland]

Another issue entered at the 4th that had no backing of a dev. I
changed the prio to critical. Until it is discussed on this list and
developers agree that it is a blocker, it is not.

-- 
Daan

Re: Review Request 22356: Fixed few coverity issues reported

[daan Hoogland]

> On June 10, 2014, 12:20 p.m., daan Hoogland wrote:
> > engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java, line 136
> > 
> >
> > a commit in a finally when try-with-resource used seems not what you 
> > want. What do you expect to be committed here?
> 
> Santhosh Edukulla wrote:
> Mentioned transaction logic mentioned seems to be our own implementation. 
> I have seen changing these commits\close at places leads to issues. Though 
> connection is getting auto closed, "assuming" a transaction can have multiple 
> connections and especially shared with scope across process, transaction 
> commit  seems ok. So, earlier i didn't delved in too much details, 
> transaction start and commit seems reasonable,  went to keep it like that.  
> 
> There are few places where this piece of code was used. With this fix, I 
> touched to see where leaks are there, and fixed. Went conservative at places, 
> cautious not to introduce regression issues. If we agree, i will still keep 
> it like this. Changing these at all places, may be like like additional 
> refactoring, making sure our own implementation of transaction works\breaks 
> and require thorough testing. Let me know your thoughts.
> 
> daan Hoogland wrote:
> I certainly don't agree. A transaction that does an unconditional commit 
> in a finally makes no sense. If the problem is that our Transaction doesn't 
> implement Closable we should make it implement that interface. It already 
> implements close() so this is no big change. At the end of regular execution 
> the commit should be done, not in the finally. The exception handlers should 
> do a rollback().
> 
> I realize that this is not entirely new in your code but it is a big bug 
> and as you do touch the contents of the finally clause, please fix. (A little 
> fix I think)
> 
> Santhosh Edukulla wrote:
> Ok,  in general this is what this behavior should be. Anyways,below are 
> what we wanted.
> 
> 1. So, move txn commit to end of try block and retain txn close in 
> finally? 
> 2. Regarding rollback, do we need rollback in outer catch? Again, 
> rollback can lead to exception, so try\catch again? once it is in outer 
> catch, the required resources to rollback are anyways autoclosed or not 
> available for rolling back anything? so, rollback is not required in 
> catch?yes\no?

ad 1. agree
ad 2. rollback yes, but rollback should be automatic when no commit is done, if 
rollback fails nothing else can be done. Our Transaction class must implement 
Closable so the close call is implicit and the opening can go in a 
try-with-resource clause


- daan


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


On June 11, 2014, 6:43 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22356/
> ---
> 
> (Updated June 11, 2014, 6:43 a.m.)
> 
> 
> 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: Review Request 22356: Fixed few coverity issues reported

[daan Hoogland]

> On June 10, 2014, 12:20 p.m., daan Hoogland wrote:
> > engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java, line 136
> > 
> >
> > a commit in a finally when try-with-resource used seems not what you 
> > want. What do you expect to be committed here?
> 
> Santhosh Edukulla wrote:
> Mentioned transaction logic mentioned seems to be our own implementation. 
> I have seen changing these commits\close at places leads to issues. Though 
> connection is getting auto closed, "assuming" a transaction can have multiple 
> connections and especially shared with scope across process, transaction 
> commit  seems ok. So, earlier i didn't delved in too much details, 
> transaction start and commit seems reasonable,  went to keep it like that.  
> 
> There are few places where this piece of code was used. With this fix, I 
> touched to see where leaks are there, and fixed. Went conservative at places, 
> cautious not to introduce regression issues. If we agree, i will still keep 
> it like this. Changing these at all places, may be like like additional 
> refactoring, making sure our own implementation of transaction works\breaks 
> and require thorough testing. Let me know your thoughts.
> 
> daan Hoogland wrote:
> I certainly don't agree. A transaction that does an unconditional commit 
> in a finally makes no sense. If the problem is that our Transaction doesn't 
> implement Closable we should make it implement that interface. It already 
> implements close() so this is no big change. At the end of regular execution 
> the commit should be done, not in the finally. The exception handlers should 
> do a rollback().
> 
> I realize that this is not entirely new in your code but it is a big bug 
> and as you do touch the contents of the finally clause, please fix. (A little 
> fix I think)
> 
> Santhosh Edukulla wrote:
> Ok,  in general this is what this behavior should be. Anyways,below are 
> what we wanted.
> 
> 1. So, move txn commit to end of try block and retain txn close in 
> finally? 
> 2. Regarding rollback, do we need rollback in outer catch? Again, 
> rollback can lead to exception, so try\catch again? once it is in outer 
> catch, the required resources to rollback are anyways autoclosed or not 
> available for rolling back anything? so, rollback is not required in 
> catch?yes\no?
> 
> daan Hoogland wrote:
> ad 1. agree
> ad 2. rollback yes, but rollback should be automatic when no commit is 
> done, if rollback fails nothing else can be done. Our Transaction class must 
> implement Closable so the close call is implicit and the opening can go in a 
> try-with-resource clause

so actually ad 1. should be [partially agree


- daan


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


On June 11, 2014, 6:43 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22356/
> ---
> 
> (Updated June 11, 2014, 6:43 a.m.)
> 
> 
> 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
> 
>

[ACS-4.4] Cherry-pick request

[Harikrishna Patnala]

Hi Daan,

Can you please cherry-pick the following commit to 4.4 branch

Commit aa75b4388554a502b1073dd78050cd4b364a803e in cloudstack's branch 
refs/heads/4.4-forward from Harikrishna Patnala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa75b43 ]

CLOUDSTACK-6869: SSH Public key content is overridden by template's meta data 
when you create a instance



Thanks,
Harikrishna

RE: CLOUDSTACK-6825 changed to critical

[Rayees Namathponnan]

Template from snapshot is basic functionality, I think we should not reduce 
priority. 

Someone with dev background,  possible to help on this.

Regards,
Rayees 

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: Wednesday, June 11, 2014 5:10 AM
To: dev
Subject: CLOUDSTACK-6825 changed to critical

LS,

I have changed a issue marked blocker to critical. It had no developer 
assigned. Until it has backing of a committed developer I can not let the 
release be stopped by such an issue.

--
Daan

Re: [DISCUSS] continuous integration for plugins requiring proprietary / hardware infra

[David Nalley]

On Tue, Jun 10, 2014 at 8:32 PM, Chiradeep Vittal
 wrote:
> Hi,
>
> Since the Nuage VSP and Brocade plugins have been proposed recently, I was
> wondering what is the mechanism to ensure that CI will test their plugins?
>
> Thanks

There is none at the moment. What would you like to propose?

Re: Review Request 22456: CLOUDSTACK-6869: Public key content is overridden by template's meta data when you create a instance

[ASF Subversion and Git Services]

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


Commit 0667f678b81eb45e7b64cb22bee37f16882250e5 in cloudstack's branch 
refs/heads/4.4 from Harikrishna Patnala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0667f67 ]

CLOUDSTACK-6869: SSH Public key content is overridden by template's meta data 
when you create a instance

(cherry picked from commit aa75b4388554a502b1073dd78050cd4b364a803e)


- ASF Subversion and Git Services


On June 11, 2014, 11:05 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22456/
> ---
> 
> (Updated June 11, 2014, 11:05 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6869
> https://issues.apache.org/jira/browse/CLOUDSTACK-6869
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6869: Public key content is overridden by template's meta data 
> when you create a instance
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/template/TemplateManagerImpl.java 3ebb43a 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 14d2eef 
> 
> Diff: https://reviews.apache.org/r/22456/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: [ACS-4.4] Cherry-pick request

[Daan Hoogland]

On Wed, Jun 11, 2014 at 2:39 PM, Harikrishna Patnala
 wrote:
> aa75b4388554a502b1073dd78050cd4b364a803e


is in

-- 
Daan

Re: [jira] [Commented] (CLOUDSTACK-6825) [Automation] Create template from snapshot fails with NPE in KVM

[Daan Hoogland]

No blockers if no work is done on them. If it is a blocker it is
important enough so it would be easy to find developers willing to
work on it. An automation test failure might be due to the test in
which case it is not a blocker at all. Discuss this on the dev list to
find support for the bocker status of the issue.

On Wed, Jun 11, 2014 at 3:19 PM, Rayees Namathponnan (JIRA)
 wrote:
>
> [ 
> https://issues.apache.org/jira/browse/CLOUDSTACK-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027723#comment-14027723
>  ]
>
> Rayees Namathponnan commented on CLOUDSTACK-6825:
> -
>
> This is automation blocker , there are test cases failing due to this,  we 
> should keep as blocker
>
>> [Automation] Create template from snapshot fails with NPE in KVM
>> 
>>
>> Key: CLOUDSTACK-6825
>> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6825
>> Project: CloudStack
>>  Issue Type: Bug
>>  Security Level: Public(Anyone can view this level - this is the 
>> default.)
>>  Components: KVM, Template
>>Affects Versions: 4.4.0
>> Environment: KVM RHEL 6.4
>> 4.4-forward branch
>>Reporter: Rayees Namathponnan
>>Priority: Critical
>> Fix For: 4.4.0
>>
>> Attachments: management-server.rar
>>
>>
>> Steps to reproduce this issue
>> Step 1 : Deploy VM
>> Step 2 : Create snapshot of ROOT disk
>> Step 3 : Create template from snapshot
>> Result
>> Creating template from snapshot fails with NPE
>> hosts for clusters not owned by any management server
>> 2014-06-02 12:03:34,564 DEBUG [c.c.a.ApiServlet] 
>> (catalina-exec-8:ctx-45977b95) ===START===  10.216.50.29 -- GET  
>> command=createTemplate&response=json&sessionkey=yTvMoOgQNxo03BBHtLaCrlOUYXE%3D&snapshotid=df67cca3-c88e-42dc-9e40-7798e6ddd601&name=Rayees&displayText=Rayees&osTypeId=5f981174-e891-11e3-b2ef-1a6f7bb0d0a8&isPublic=true&passwordEnabled=false&isdynamicallyscalable=false&_=1401735816975
>> 2014-06-02 12:03:34,573 ERROR [c.c.a.ApiServer] 
>> (catalina-exec-8:ctx-45977b95 ctx-eeca4b45) unhandled exception executing 
>> api command: [Ljava.lang.String;@4f901948
>> java.lang.NullPointerException
>> at 
>> com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:498)
>> at 
>> com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:486)
>> at sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at 
>> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>> at 
>> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>> at 
>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>> at 
>> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>> at 
>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>> at 
>> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>> at com.sun.proxy.$Proxy100.checkAccess(Unknown Source)
>> at 
>> com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:226)
>> at 
>> com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:216)
>> at 
>> com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:88)
>> at 
>> com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37)
>> at 
>> com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:79)
>> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614)
>> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506)
>> at 
>> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330)
>> at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54)
>> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
>> at 
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>> at 
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>> at 
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115)
>> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
>> at javax.servlet.http.HttpServlet.service(HttpSer

Re: feature : changing volume properties dynamically in 4.5

[Punith S]

yes it sounds good, thanks for the proposal mike,

yeah right now i have implemented prototype of my proposal, since its not
generic we shall implement your proposal for 4.5.
on the other hand, for 4.5 i'm supporting nfs protocol and resize feature
for managed storage in xenserver, now trying to implement snapshot and
support root disk for vm's.
and yes if we can club together, i can start working on this proposal for
data disk and get the prototype ready.
what do you think ?

thanks.


On Wed, Jun 11, 2014 at 3:53 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I'll send out a [PROPOSAL] e-mail so others who may not be following this
> e-mail thread have a better chance to comment on the feature.
>
>
> On Tue, Jun 10, 2014 at 2:58 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Here is that design document I was referring to, Punith:
>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111
>>
>> I've been working with a student in Tunisia who is participating in
>> Google Summer of Code (GSoC) (I'm his mentor).
>>
>> He'll be working on part of this as will I. (He is also working on
>> another related task not listed here.)
>>
>> Feel free to join us, if you have time available, as we can divide out
>> coding and testing among the three of us.
>>
>> Talk to you later!
>> Mike
>>
>>
>> On Tue, Jun 10, 2014 at 10:18 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> I plan to draw up a design document surrounding generic key/value pairs
>>> today.
>>>
>>> Perhaps you can take a look at it when you have time, Punith?
>>>
>>>
>>> On Tue, Jun 10, 2014 at 10:06 AM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
 Hi Punith,

 Yeah, I hear you about the number of permutations involved.

 Traditionally Compute and Disk Offerings have been immutable. It makes
 it easier from an accounting point of view for chargeback and billing.

 You should definitely feel free to extend the CloudStack API. I think
 NetApp did this for one of their storage features in the recent past. This
 way vendor-specific capabilities can be more easily offered without making
 it look like all vendors support those particular features.

 I do not yet have any code in master related to generic keys/values.
 I'm still designing this.

 How does your schedule look for the 4.5 release? Do you think you might
 have available cycles to help out with this generic key/value
 implementation?

 Talk to you later!
 Mike


 On Tue, Jun 10, 2014 at 7:09 AM, Punith S 
 wrote:

> hi mike,
>
> thanks for the reply, i like your approach which is a very generic way
> and also we only need to do a few changes to the current cloudstack,
>
> but on the other hand we are tying every property of the vendor to a
> disk offering through key/value pairs, since we offer lot of properties
> like i mentioned, this can create a lot of permutation combinations of 
> disk
> offerings, for say if i need to turn deduplication On for a specific 
> volume
> , should i have to create a new disk offering having current properties
> with deduplication On?
>
> is this approach already implemented in the current master ?
>
> and also like you mentioned about exposing a new api, is it okay if i
> expose our own api in my util by extending the PlugableService like in
> network plugins ?
>
> thanks.
>
>
> On Tue, Jun 10, 2014 at 1:17 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Allow me to follow this up with more detail (with regards to what
>> Chris and I talked about):
>>
>> As you are aware, today the way you associate a Compute Offering (CO)
>> or a Disk Offering (DO) with a Primary Storage (PS) is via storage 
>> tagging.
>>
>> This has some benefits and drawbacks.
>>
>> One benefit is being able to have some level of vendor independence
>> from the point of view of the CO or DO. For example, if the storage tag 
>> of
>> a DO is "Fast", then this can be satisfied by PS that describes itself as
>> "Fast", regardless of vendor.
>>
>> A major drawback with the storage-tagging approach, however, is that
>> you are not easily able to leverage vendor-specific features, which is
>> often why you bought storage from the vendor in question to begin with.
>>
>> Ideally we do not want to add each vendor's features into the system
>> as properties that can be seen by the admin regardless of whether or not
>> the underlying storage he's actually using supports the feature in 
>> question.
>>
>> This coarse approach, however, was sort of business as usual when I
>> started in with CloudStack 1.5 years ago.
>>
>> That being the case, when I added QoS options to CS, I did so in

Re: [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins

[Mike Tutkowski]

Yep :) This is what we talked about at CCCEU13.

On Wednesday, June 11, 2014, Wido den Hollander  wrote:

> On 06/11/2014 12:26 AM, Mike Tutkowski wrote:
>
>> Hi,
>>
>> Please feel free to review the following proposal for 4.5:
>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111
>>
>>
> Is this what we discussed at CCC13 in Amsterdam? Seems like it!
>
> I'm in favor, since this could add a lot of potentials to the Ceph storage
> as well.
>
> Wido
>
>  Here is the summary:
>>
>> Today the way you associate a Compute Offering (CO) or a Disk Offering
>> (DO)
>> with a Primary Storage (PS) is via storage tagging.
>>
>> This has some benefits and drawbacks.
>>
>> One benefit is being able to have some level of vendor independence from
>> the point of view of the CO or DO. For example, if the storage tag of a DO
>> is "Fast", then this can be satisfied by PS that describes itself as
>> "Fast", regardless of vendor.
>>
>> A major drawback with the storage-tagging approach, however, is that you
>> are not easily able to leverage vendor-specific features, which is often
>> why you bought storage from the vendor in question to begin with.
>>
>> Ideally we do not want to add each vendor's features into the system as
>> properties that can be seen by the admin regardless of whether or not the
>> underlying storage he's actually using supports the feature in question.
>> Traditionally, however, this has been business as usual in the CloudStack
>> codebase.
>>
>> Going forward, we want to implement a more fine-grain and generic
>> approach.
>>
>> For example, in the GUI we would like to have a storage provider field for
>> the CO and DO windows (this equates to the name of one and only one
>> storage
>> provider). If the admin inputs a specific storage provider, he can enter
>> in
>> an arbitrary number of key/value pairs in another text field (perhaps we
>> would provide a nice entry dialog to make this easier in the GUI). These
>> key value pairs can be passed into the storage driver when it's asked to
>> create (or update) a volume and the storage driver can decide what each
>> and
>> every key/value pair means, if anything.
>>
>> Thanks!
>>
>>
>

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

[DISCUSS] Release 4.4

[Hugo Trippaers]

Hey all,

I’m getting somewhat concerned about the 4.4 release. We don’t seems to be able 
to get the 4.4 branch in shape for a release candidate and meanwhile master is 
diverging further and further. We also know that once we hit the RC phase we 
will probably need a sizable number of iterations to eventually ship the 
release. Based on past experience, if we keep up like this we will have another 
release that will actually be released way after the feature freeze for the 
next release (July 18). Probably leaving us in the same bad spot for the next 
release.

I tried to come up with a number of solutions that could rectify the situation 
and help the release move forward, but i can’t think of any. Save for some 
options that might be considered extreme ideas. One the the more prominent 
ideas in my mind at the moment is skipping the 4.4 release all together and 
combine it with the next planned release (whether its 5.0 or 4.5). This would 
require a community effort to focus on quality in the next month and basically 
freeze the master for features and have a community wide push for quality to 
get the next release out on schedule. 

But before i go on and shout out even more drastic ideas, what do you think 
about the current 4.4 release. How close do you feel that we are to having a 
releasable product? 

Cheers,

Hugo

Re: [DISCUSS] Release 4.4

[David Nalley]

On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers  wrote:
> Hey all,
>
> I’m getting somewhat concerned about the 4.4 release. We don’t seems to be 
> able to get the 4.4 branch in shape for a release candidate and meanwhile 
> master is diverging further and further. We also know that once we hit the RC 
> phase we will probably need a sizable number of iterations to eventually ship 
> the release. Based on past experience, if we keep up like this we will have 
> another release that will actually be released way after the feature freeze 
> for the next release (July 18). Probably leaving us in the same bad spot for 
> the next release.
>
> I tried to come up with a number of solutions that could rectify the 
> situation and help the release move forward, but i can’t think of any. Save 
> for some options that might be considered extreme ideas. One the the more 
> prominent ideas in my mind at the moment is skipping the 4.4 release all 
> together and combine it with the next planned release (whether its 5.0 or 
> 4.5). This would require a community effort to focus on quality in the next 
> month and basically freeze the master for features and have a community wide 
> push for quality to get the next release out on schedule.
>
> But before i go on and shout out even more drastic ideas, what do you think 
> about the current 4.4 release. How close do you feel that we are to having a 
> releasable product?
>

So this sounds very familiar to a discussion we had in 4.1 or 4.2
timeframes. (I may have even been one of the folks proposing similar
ideas, I don't recall)

To save you some reading I am -1 on the idea of canceling 4.4. (though
really - anyone can propose a release and ask for votes, we have
adopted a bit more rigor, but that structure isn't demanded.)

Here's the issues I see:
1. We set the expectation that 4.4 is coming; people worked hard to
get features in, and our users are waiting on it.
2. We may not be perfect from a schedule perspective, but giving up on
a release is a pretty negative thing to do - whats the reaction going
to be?
3. Do you think we are in a position to make 4.5 any better? Speaking
very frankly, I worry that we are not. I don't think that we have
either the tooling or the social desire at present to make significant
strides here. We don't dictate the priorities for individual
developers. It might be a different story if we were in a corporate
shop and could control what folks work on, it might be a different
story.

--David

Code Documentation

[Santhosh Edukulla]

Hi All,

Many of code areas under CS, currently don't have enough documentation i 
believe, we have few one liner comments at places. But, largely, was missing at 
various code areas. 

We in one of our earlier project, used to enforce strictly a template for 
comments\documentation for every new function added. These comments were later 
retrieved automatically to build code documentation easily. This gets enforced 
during review itself, or otherwise review wont be accepted.  It will make the 
flow lot easier to understand some times i believe.

Please add atleast basic description for every  major interface\class\function, 
description for input\output arguments for individual entities.

EX: Currently, for below we dont have any comments in general.

public boolean shutdownNetwork(final long networkId, ReservationContext 
context, boolean cleanupElements)


Regards,
Santhosh

Re: unused private methods in VirtualMachinManagerImpl

[Mike Tutkowski]

I am not aware of any existing annotation for that purpose (not that that
means it doesn't necessary exist).

Kelven - Do you know of one? If not, would you be willing to create one?

Thanks!


On Wed, Jun 11, 2014 at 2:06 AM, Daan Hoogland 
wrote:

> is there one availible or are we implementing @usedPrivate ?
>
> On Wed, Jun 11, 2014 at 2:54 AM, Mike Tutkowski
>  wrote:
> > Good idea
> >
> > On Tuesday, June 10, 2014, Kelven Yang  wrote:
> >
> >> Maybe utilizing special java annotation would get developer heads-up?
> >> Content in comments text is easily skipped as it is not usually
> considered
> >> as mandatory language constructs
> >>
> >> Kelven
> >>
> >> On 6/10/14, 4:25 PM, "Mike Tutkowski" 
> >> wrote:
> >>
> >> >I haven't looked, but perhaps we should provide sufficient comments in
> >> >each
> >> >of these cases so no one removes the fields thinking that they are old
> and
> >> >no longer in use.
> >> >
> >> >
> >> >On Tue, Jun 10, 2014 at 5:13 PM, Kelven Yang 
> >> >wrote:
> >> >
> >> >> The usage of these private methods are through reflection, making it
> >> >> private is to avoid exposing unnecessary internal structures to
> outside.
> >> >>
> >> >> Kelven
> >> >>
> >> >> On 6/10/14, 2:46 AM, "Rajani Karuturi" 
> >> >>wrote:
> >> >>
> >> >> >Hi Kelven,
> >> >> >while fixing some of the issues reported by coverity I encountered
> some
> >> >> >unused private methods in VirtualMachineManagerImpl.java
> >> >> >(https://reviews.apache.org/r/22364 ) and removed them. Koushik
> >> pointed
> >> >> >that they are getting used by the job framework.
> >> >> >Looks like these are used by the job framework by making them public
> >> >> >through reflection and following some convention for the function
> >> >>names.
> >> >> >
> >> >> >Its very difficult to find the usages or refactor which can have
> some
> >> >> >unforeseen consequences.
> >> >> >
> >> >> >Can you share some details about them? probably some javadoc?
> >> >> >
> >> >> >
> >> >> >~Rajani
> >> >> >
> >> >> >
> >> >> >
> >> >> >On 10-Jun-2014, at 12:37 pm, Koushik Das 
> >> >>wrote:
> >> >> >
> >> >> >>
> >> >> >> ---
> >> >> >> This is an automatically generated e-mail. To reply, visit:
> >> >> >> https://reviews.apache.org/r/22364/#review45200
> >> >> >> ---
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> >> >> >> 
> >> >> >>
> >> >> >>These methods are getting used by the job framework. Check
> >> >> >>handleVmWorkJob() method in the same java file.
> >> >> >>
> >> >> >>
> >> >> >> - Koushik Das
> >> >> >>
> >> >> >>
> >> >> >> On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
> >> >> >>>
> >> >> >>> ---
> >> >> >>> This is an automatically generated e-mail. To reply, visit:
> >> >> >>> https://reviews.apache.org/r/22364/
> >> >> >>> ---
> >> >> >>>
> >> >> >>> (Updated June 10, 2014, 4:06 a.m.)
> >> >> >>>
> >> >> >>>
> >> >> >>> Review request for cloudstack, daan Hoogland, Kelven Yang,
> Koushik
> >> >> >>>Das, and Santhosh Edukulla.
> >> >> >>>
> >> >> >>>
> >> >> >>> 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
> >> >> >>>25c67db
> >> >> >>>
> >> >> >>> Diff: https://reviews.apache.org/r/22364/diff/
> >> >>*Mike Tutkowski*
> >> >*Senior CloudStack Developer, SolidFire Inc.*
> >> >e: mike.tutkow...@solidfire.com 
> >> >o: 303.746.7302
> >> >Advancing the way the world uses the cloud
> >> >* *
> >>
> >>
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
>
>
>
> --
> Daan
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

Re: [DISCUSS] Release 4.4

[Mike Tutkowski]

Yeah, I am concerned about 4.4 getting farther behind schedule, as well,
but I agree with David that we should not cancel it.

I know it might be a pain, but I wonder if the RM would be willing to "nag"
people every few days (just an e-mail to dev@) about the current list of
blockers and their progress and to see if people need help and others might
be willing and able to do so.


On Wed, Jun 11, 2014 at 10:08 AM, David Nalley  wrote:

> On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers  wrote:
> > Hey all,
> >
> > I’m getting somewhat concerned about the 4.4 release. We don’t seems to
> be able to get the 4.4 branch in shape for a release candidate and
> meanwhile master is diverging further and further. We also know that once
> we hit the RC phase we will probably need a sizable number of iterations to
> eventually ship the release. Based on past experience, if we keep up like
> this we will have another release that will actually be released way after
> the feature freeze for the next release (July 18). Probably leaving us in
> the same bad spot for the next release.
> >
> > I tried to come up with a number of solutions that could rectify the
> situation and help the release move forward, but i can’t think of any. Save
> for some options that might be considered extreme ideas. One the the more
> prominent ideas in my mind at the moment is skipping the 4.4 release all
> together and combine it with the next planned release (whether its 5.0 or
> 4.5). This would require a community effort to focus on quality in the next
> month and basically freeze the master for features and have a community
> wide push for quality to get the next release out on schedule.
> >
> > But before i go on and shout out even more drastic ideas, what do you
> think about the current 4.4 release. How close do you feel that we are to
> having a releasable product?
> >
>
> So this sounds very familiar to a discussion we had in 4.1 or 4.2
> timeframes. (I may have even been one of the folks proposing similar
> ideas, I don't recall)
>
> To save you some reading I am -1 on the idea of canceling 4.4. (though
> really - anyone can propose a release and ask for votes, we have
> adopted a bit more rigor, but that structure isn't demanded.)
>
> Here's the issues I see:
> 1. We set the expectation that 4.4 is coming; people worked hard to
> get features in, and our users are waiting on it.
> 2. We may not be perfect from a schedule perspective, but giving up on
> a release is a pretty negative thing to do - whats the reaction going
> to be?
> 3. Do you think we are in a position to make 4.5 any better? Speaking
> very frankly, I worry that we are not. I don't think that we have
> either the tooling or the social desire at present to make significant
> strides here. We don't dictate the priorities for individual
> developers. It might be a different story if we were in a corporate
> shop and could control what folks work on, it might be a different
> story.
>
> --David
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

Re: [DISCUSS] Release 4.4

[Erik Weber]

On Wed, Jun 11, 2014 at 5:30 PM, Hugo Trippaers  wrote:

> Hey all,
>
> I’m getting somewhat concerned about the 4.4 release. We don’t seems to be
> able to get the 4.4 branch in shape for a release candidate and meanwhile
> master is diverging further and further. We also know that once we hit the
> RC phase we will probably need a sizable number of iterations to eventually
> ship the release. Based on past experience, if we keep up like this we will
> have another release that will actually be released way after the feature
> freeze for the next release (July 18). Probably leaving us in the same bad
> spot for the next release.
>
> I tried to come up with a number of solutions that could rectify the
> situation and help the release move forward, but i can’t think of any. Save
> for some options that might be considered extreme ideas. One the the more
> prominent ideas in my mind at the moment is skipping the 4.4 release all
> together and combine it with the next planned release (whether its 5.0 or
> 4.5). This would require a community effort to focus on quality in the next
> month and basically freeze the master for features and have a community
> wide push for quality to get the next release out on schedule.
>
>

What happens if that release doesn't make its desired time frame? Skip that
too and wait for 4.6 / 5.1 / 6.0?
If any drastic choices were to be made, I'd prefer that the next release
(4.5 / 5.0) either gets postponed, or skipped.
A major version bump with API changes could possibly warrant such drastic
change in my opinion.



> But before i go on and shout out even more drastic ideas, what do you
> think about the current 4.4 release. How close do you feel that we are to
> having a releasable product?
>
>
As a non developer I can only comment based on what I experience on the
mailing list, but this seems to be a repeating problem..
And something should probably be done to prevent this from being a / the
problem every release.


-- 
Erik Weber

Re: unused private methods in VirtualMachinManagerImpl

[Kelven Yang]

I guess we can create one. Currently available annotations that are to be
applied to java code are as following

* @Override
* @Deprecated 
* @SuppressWarnings
* @SafeVarargs(since Java 7)
* @FunctionalInterface(since Java 8)

Calling functions through reflection is not a common way for static typing
language like Java.

Kelven




On 6/11/14, 9:32 AM, "Mike Tutkowski"  wrote:

>I am not aware of any existing annotation for that purpose (not that that
>means it doesn't necessary exist).
>
>Kelven - Do you know of one? If not, would you be willing to create one?
>
>Thanks!
>
>
>On Wed, Jun 11, 2014 at 2:06 AM, Daan Hoogland 
>wrote:
>
>> is there one availible or are we implementing @usedPrivate ?
>>
>> On Wed, Jun 11, 2014 at 2:54 AM, Mike Tutkowski
>>  wrote:
>> > Good idea
>> >
>> > On Tuesday, June 10, 2014, Kelven Yang  wrote:
>> >
>> >> Maybe utilizing special java annotation would get developer heads-up?
>> >> Content in comments text is easily skipped as it is not usually
>> considered
>> >> as mandatory language constructs
>> >>
>> >> Kelven
>> >>
>> >> On 6/10/14, 4:25 PM, "Mike Tutkowski" 
>> >> wrote:
>> >>
>> >> >I haven't looked, but perhaps we should provide sufficient comments
>>in
>> >> >each
>> >> >of these cases so no one removes the fields thinking that they are
>>old
>> and
>> >> >no longer in use.
>> >> >
>> >> >
>> >> >On Tue, Jun 10, 2014 at 5:13 PM, Kelven Yang
>>
>> >> >wrote:
>> >> >
>> >> >> The usage of these private methods are through reflection, making
>>it
>> >> >> private is to avoid exposing unnecessary internal structures to
>> outside.
>> >> >>
>> >> >> Kelven
>> >> >>
>> >> >> On 6/10/14, 2:46 AM, "Rajani Karuturi"
>>
>> >> >>wrote:
>> >> >>
>> >> >> >Hi Kelven,
>> >> >> >while fixing some of the issues reported by coverity I
>>encountered
>> some
>> >> >> >unused private methods in VirtualMachineManagerImpl.java
>> >> >> >(https://reviews.apache.org/r/22364 ) and removed them. Koushik
>> >> pointed
>> >> >> >that they are getting used by the job framework.
>> >> >> >Looks like these are used by the job framework by making them
>>public
>> >> >> >through reflection and following some convention for the function
>> >> >>names.
>> >> >> >
>> >> >> >Its very difficult to find the usages or refactor which can have
>> some
>> >> >> >unforeseen consequences.
>> >> >> >
>> >> >> >Can you share some details about them? probably some javadoc?
>> >> >> >
>> >> >> >
>> >> >> >~Rajani
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >On 10-Jun-2014, at 12:37 pm, Koushik Das 
>> >> >>wrote:
>> >> >> >
>> >> >> >>
>> >> >> >> ---
>> >> >> >> This is an automatically generated e-mail. To reply, visit:
>> >> >> >> https://reviews.apache.org/r/22364/#review45200
>> >> >> >> ---
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
>> >> >> >> 
>> >> >> >>
>> >> >> >>These methods are getting used by the job framework. Check
>> >> >> >>handleVmWorkJob() method in the same java file.
>> >> >> >>
>> >> >> >>
>> >> >> >> - Koushik Das
>> >> >> >>
>> >> >> >>
>> >> >> >> On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
>> >> >> >>>
>> >> >> >>> ---
>> >> >> >>> This is an automatically generated e-mail. To reply, visit:
>> >> >> >>> https://reviews.apache.org/r/22364/
>> >> >> >>> ---
>> >> >> >>>
>> >> >> >>> (Updated June 10, 2014, 4:06 a.m.)
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> Review request for cloudstack, daan Hoogland, Kelven Yang,
>> Koushik
>> >> >> >>>Das, and Santhosh Edukulla.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> 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
>> >> >> >>>25c67db
>> >> >> >>>
>> >> >> >>> Diff: https://reviews.apache.org/r/22364/diff/
>> >> >>*Mike Tutkowski*
>> >> >*Senior CloudStack Developer, SolidFire Inc.*
>> >> >e: mike.tutkow...@solidfire.com 
>> >> >o: 303.746.7302
>> >> >Advancing the way the world uses the cloud
>> >> >* *
>> >>
>> >>
>> >
>> > --
>> > *Mike Tutkowski*
>> > *Senior CloudStack Developer, SolidFire Inc.*
>> > e: mike.tutkow...@solidfire.com
>> > o: 303.746.7302
>> > Advancing the way the world uses the cloud
>> > **
>>
>>
>>
>> --
>> Daan
>>
>
>
>
>-- 
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com
>o: 303.746.7302
>Ad

Re: unused private methods in VirtualMachinManagerImpl

[Mike Tutkowski]

Yeah, and when a tool like Eclipse says a private variable is not in use, I
can easily see someone removing it.

So, does that mean you will create such an annotation, Kelven? :)


On Wed, Jun 11, 2014 at 10:52 AM, Kelven Yang 
wrote:

> I guess we can create one. Currently available annotations that are to be
> applied to java code are as following
>
> * @Override
> * @Deprecated
> * @SuppressWarnings
> * @SafeVarargs(since Java 7)
> * @FunctionalInterface(since Java 8)
>
> Calling functions through reflection is not a common way for static typing
> language like Java.
>
> Kelven
>
>
>
>
> On 6/11/14, 9:32 AM, "Mike Tutkowski" 
> wrote:
>
> >I am not aware of any existing annotation for that purpose (not that that
> >means it doesn't necessary exist).
> >
> >Kelven - Do you know of one? If not, would you be willing to create one?
> >
> >Thanks!
> >
> >
> >On Wed, Jun 11, 2014 at 2:06 AM, Daan Hoogland 
> >wrote:
> >
> >> is there one availible or are we implementing @usedPrivate ?
> >>
> >> On Wed, Jun 11, 2014 at 2:54 AM, Mike Tutkowski
> >>  wrote:
> >> > Good idea
> >> >
> >> > On Tuesday, June 10, 2014, Kelven Yang 
> wrote:
> >> >
> >> >> Maybe utilizing special java annotation would get developer heads-up?
> >> >> Content in comments text is easily skipped as it is not usually
> >> considered
> >> >> as mandatory language constructs
> >> >>
> >> >> Kelven
> >> >>
> >> >> On 6/10/14, 4:25 PM, "Mike Tutkowski" 
> >> >> wrote:
> >> >>
> >> >> >I haven't looked, but perhaps we should provide sufficient comments
> >>in
> >> >> >each
> >> >> >of these cases so no one removes the fields thinking that they are
> >>old
> >> and
> >> >> >no longer in use.
> >> >> >
> >> >> >
> >> >> >On Tue, Jun 10, 2014 at 5:13 PM, Kelven Yang
> >>
> >> >> >wrote:
> >> >> >
> >> >> >> The usage of these private methods are through reflection, making
> >>it
> >> >> >> private is to avoid exposing unnecessary internal structures to
> >> outside.
> >> >> >>
> >> >> >> Kelven
> >> >> >>
> >> >> >> On 6/10/14, 2:46 AM, "Rajani Karuturi"
> >>
> >> >> >>wrote:
> >> >> >>
> >> >> >> >Hi Kelven,
> >> >> >> >while fixing some of the issues reported by coverity I
> >>encountered
> >> some
> >> >> >> >unused private methods in VirtualMachineManagerImpl.java
> >> >> >> >(https://reviews.apache.org/r/22364 ) and removed them. Koushik
> >> >> pointed
> >> >> >> >that they are getting used by the job framework.
> >> >> >> >Looks like these are used by the job framework by making them
> >>public
> >> >> >> >through reflection and following some convention for the function
> >> >> >>names.
> >> >> >> >
> >> >> >> >Its very difficult to find the usages or refactor which can have
> >> some
> >> >> >> >unforeseen consequences.
> >> >> >> >
> >> >> >> >Can you share some details about them? probably some javadoc?
> >> >> >> >
> >> >> >> >
> >> >> >> >~Rajani
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >On 10-Jun-2014, at 12:37 pm, Koushik Das  >
> >> >> >>wrote:
> >> >> >> >
> >> >> >> >>
> >> >> >> >> ---
> >> >> >> >> This is an automatically generated e-mail. To reply, visit:
> >> >> >> >> https://reviews.apache.org/r/22364/#review45200
> >> >> >> >> ---
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> >> >> >> >> 
> >> >> >> >>
> >> >> >> >>These methods are getting used by the job framework. Check
> >> >> >> >>handleVmWorkJob() method in the same java file.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> - Koushik Das
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
> >> >> >> >>>
> >> >> >> >>> ---
> >> >> >> >>> This is an automatically generated e-mail. To reply, visit:
> >> >> >> >>> https://reviews.apache.org/r/22364/
> >> >> >> >>> ---
> >> >> >> >>>
> >> >> >> >>> (Updated June 10, 2014, 4:06 a.m.)
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> Review request for cloudstack, daan Hoogland, Kelven Yang,
> >> Koushik
> >> >> >> >>>Das, and Santhosh Edukulla.
> >> >> >> >>>
> >> >> >> >>>
> >> >> >> >>> 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
> >> >> >> >>>25c67db
> >> >> >> >>>
> >> >> >> >>> Diff: https://reviews.apache.org/r/22364/diff/
> >> >> >>*Mike Tutkowski*
> >> >> >*Senior CloudStack Developer, SolidFire Inc.*
> >> >> >e: mike.tutkow...@solidfire.com 
> >> >> >o: 

Re: [DISCUSS] Release 4.4

[Alena Prokharchyk]

On 6/11/14, 9:36 AM, "Mike Tutkowski"  wrote:

>Yeah, I am concerned about 4.4 getting farther behind schedule, as well,
>but I agree with David that we should not cancel it.
>
>I know it might be a pain, but I wonder if the RM would be willing to
>"nag"
>people every few days (just an e-mail to dev@) about the current list of
>blockers and their progress and to see if people need help and others
>might
>be willing and able to do so.


Good idea. Should we do the same for Critical bugs? What would be the RC
criteria - no blockers, no criticals?
We should also triage these bugs as sometimes even though they are filed
as blockers, they are not really blockers (As Daan already pointed out in
one of his previous emails)


>
>
>On Wed, Jun 11, 2014 at 10:08 AM, David Nalley  wrote:
>
>> On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers 
>>wrote:
>> > Hey all,
>> >
>> > I¹m getting somewhat concerned about the 4.4 release. We don¹t seems
>>to
>> be able to get the 4.4 branch in shape for a release candidate and
>> meanwhile master is diverging further and further. We also know that
>>once
>> we hit the RC phase we will probably need a sizable number of
>>iterations to
>> eventually ship the release. Based on past experience, if we keep up
>>like
>> this we will have another release that will actually be released way
>>after
>> the feature freeze for the next release (July 18). Probably leaving us
>>in
>> the same bad spot for the next release.
>> >
>> > I tried to come up with a number of solutions that could rectify the
>> situation and help the release move forward, but i can¹t think of any.
>>Save
>> for some options that might be considered extreme ideas. One the the
>>more
>> prominent ideas in my mind at the moment is skipping the 4.4 release all
>> together and combine it with the next planned release (whether its 5.0
>>or
>> 4.5). This would require a community effort to focus on quality in the
>>next
>> month and basically freeze the master for features and have a community
>> wide push for quality to get the next release out on schedule.
>> >
>> > But before i go on and shout out even more drastic ideas, what do you
>> think about the current 4.4 release. How close do you feel that we are
>>to
>> having a releasable product?
>> >
>>
>> So this sounds very familiar to a discussion we had in 4.1 or 4.2
>> timeframes. (I may have even been one of the folks proposing similar
>> ideas, I don't recall)
>>
>> To save you some reading I am -1 on the idea of canceling 4.4. (though
>> really - anyone can propose a release and ask for votes, we have
>> adopted a bit more rigor, but that structure isn't demanded.)
>>
>> Here's the issues I see:
>> 1. We set the expectation that 4.4 is coming; people worked hard to
>> get features in, and our users are waiting on it.
>> 2. We may not be perfect from a schedule perspective, but giving up on
>> a release is a pretty negative thing to do - whats the reaction going
>> to be?
>> 3. Do you think we are in a position to make 4.5 any better? Speaking
>> very frankly, I worry that we are not. I don't think that we have
>> either the tooling or the social desire at present to make significant
>> strides here. We don't dictate the priorities for individual
>> developers. It might be a different story if we were in a corporate
>> shop and could control what folks work on, it might be a different
>> story.
>>
>> --David
>>
>
>
>
>-- 
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the cloud
>**

Re: [DISCUSS] Release 4.4

[Pierre-Luc Dion]

Is there a list of issues, blockers, or todo items to be done in order to
have 4.4 out ?  The only things I saw is the list of blocker currently
having 4 blocker (
https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112)

Does this mean that even if all blockers are fixed getting the branch 4.4.0
able to build and be a workable CloudStack is a release manager nightmare?


Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
855-OK-CLOUD (855-652-5683) x1101
- - -

*CloudOps*420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_


On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Yeah, I am concerned about 4.4 getting farther behind schedule, as well,
> but I agree with David that we should not cancel it.
>
> I know it might be a pain, but I wonder if the RM would be willing to "nag"
> people every few days (just an e-mail to dev@) about the current list of
> blockers and their progress and to see if people need help and others might
> be willing and able to do so.
>
>
> On Wed, Jun 11, 2014 at 10:08 AM, David Nalley  wrote:
>
> > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers 
> wrote:
> > > Hey all,
> > >
> > > I’m getting somewhat concerned about the 4.4 release. We don’t seems to
> > be able to get the 4.4 branch in shape for a release candidate and
> > meanwhile master is diverging further and further. We also know that once
> > we hit the RC phase we will probably need a sizable number of iterations
> to
> > eventually ship the release. Based on past experience, if we keep up like
> > this we will have another release that will actually be released way
> after
> > the feature freeze for the next release (July 18). Probably leaving us in
> > the same bad spot for the next release.
> > >
> > > I tried to come up with a number of solutions that could rectify the
> > situation and help the release move forward, but i can’t think of any.
> Save
> > for some options that might be considered extreme ideas. One the the more
> > prominent ideas in my mind at the moment is skipping the 4.4 release all
> > together and combine it with the next planned release (whether its 5.0 or
> > 4.5). This would require a community effort to focus on quality in the
> next
> > month and basically freeze the master for features and have a community
> > wide push for quality to get the next release out on schedule.
> > >
> > > But before i go on and shout out even more drastic ideas, what do you
> > think about the current 4.4 release. How close do you feel that we are to
> > having a releasable product?
> > >
> >
> > So this sounds very familiar to a discussion we had in 4.1 or 4.2
> > timeframes. (I may have even been one of the folks proposing similar
> > ideas, I don't recall)
> >
> > To save you some reading I am -1 on the idea of canceling 4.4. (though
> > really - anyone can propose a release and ask for votes, we have
> > adopted a bit more rigor, but that structure isn't demanded.)
> >
> > Here's the issues I see:
> > 1. We set the expectation that 4.4 is coming; people worked hard to
> > get features in, and our users are waiting on it.
> > 2. We may not be perfect from a schedule perspective, but giving up on
> > a release is a pretty negative thing to do - whats the reaction going
> > to be?
> > 3. Do you think we are in a position to make 4.5 any better? Speaking
> > very frankly, I worry that we are not. I don't think that we have
> > either the tooling or the social desire at present to make significant
> > strides here. We don't dictate the priorities for individual
> > developers. It might be a different story if we were in a corporate
> > shop and could control what folks work on, it might be a different
> > story.
> >
> > --David
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

Re: [DISCUSS] Release 4.4

[Mike Tutkowski]

Good point - what is the release criteria? Is it just no blockers or is it
no blockers and no criticals?

Triaging the bugs is a good idea, too. We should make sure they still are
what we have them listed as.


On Wed, Jun 11, 2014 at 11:23 AM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> On 6/11/14, 9:36 AM, "Mike Tutkowski" 
> wrote:
>
> >Yeah, I am concerned about 4.4 getting farther behind schedule, as well,
> >but I agree with David that we should not cancel it.
> >
> >I know it might be a pain, but I wonder if the RM would be willing to
> >"nag"
> >people every few days (just an e-mail to dev@) about the current list of
> >blockers and their progress and to see if people need help and others
> >might
> >be willing and able to do so.
>
>
> Good idea. Should we do the same for Critical bugs? What would be the RC
> criteria - no blockers, no criticals?
> We should also triage these bugs as sometimes even though they are filed
> as blockers, they are not really blockers (As Daan already pointed out in
> one of his previous emails)
>
>
> >
> >
> >On Wed, Jun 11, 2014 at 10:08 AM, David Nalley  wrote:
> >
> >> On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers 
> >>wrote:
> >> > Hey all,
> >> >
> >> > I¹m getting somewhat concerned about the 4.4 release. We don¹t seems
> >>to
> >> be able to get the 4.4 branch in shape for a release candidate and
> >> meanwhile master is diverging further and further. We also know that
> >>once
> >> we hit the RC phase we will probably need a sizable number of
> >>iterations to
> >> eventually ship the release. Based on past experience, if we keep up
> >>like
> >> this we will have another release that will actually be released way
> >>after
> >> the feature freeze for the next release (July 18). Probably leaving us
> >>in
> >> the same bad spot for the next release.
> >> >
> >> > I tried to come up with a number of solutions that could rectify the
> >> situation and help the release move forward, but i can¹t think of any.
> >>Save
> >> for some options that might be considered extreme ideas. One the the
> >>more
> >> prominent ideas in my mind at the moment is skipping the 4.4 release all
> >> together and combine it with the next planned release (whether its 5.0
> >>or
> >> 4.5). This would require a community effort to focus on quality in the
> >>next
> >> month and basically freeze the master for features and have a community
> >> wide push for quality to get the next release out on schedule.
> >> >
> >> > But before i go on and shout out even more drastic ideas, what do you
> >> think about the current 4.4 release. How close do you feel that we are
> >>to
> >> having a releasable product?
> >> >
> >>
> >> So this sounds very familiar to a discussion we had in 4.1 or 4.2
> >> timeframes. (I may have even been one of the folks proposing similar
> >> ideas, I don't recall)
> >>
> >> To save you some reading I am -1 on the idea of canceling 4.4. (though
> >> really - anyone can propose a release and ask for votes, we have
> >> adopted a bit more rigor, but that structure isn't demanded.)
> >>
> >> Here's the issues I see:
> >> 1. We set the expectation that 4.4 is coming; people worked hard to
> >> get features in, and our users are waiting on it.
> >> 2. We may not be perfect from a schedule perspective, but giving up on
> >> a release is a pretty negative thing to do - whats the reaction going
> >> to be?
> >> 3. Do you think we are in a position to make 4.5 any better? Speaking
> >> very frankly, I worry that we are not. I don't think that we have
> >> either the tooling or the social desire at present to make significant
> >> strides here. We don't dictate the priorities for individual
> >> developers. It might be a different story if we were in a corporate
> >> shop and could control what folks work on, it might be a different
> >> story.
> >>
> >> --David
> >>
> >
> >
> >
> >--
> >*Mike Tutkowski*
> >*Senior CloudStack Developer, SolidFire Inc.*
> >e: mike.tutkow...@solidfire.com
> >o: 303.746.7302
> >Advancing the way the world uses the cloud
> >* *
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

Re: [DISCUSS] Release 4.4

[Mike Tutkowski]

According to that list, we have four blockers remaining...all network
oriented.

Murali Reddy has two. All four have an owner and presumably progress is
being made.

I guess it would be a good idea if we triaged critical defects and
determined once the blockers are done if any of those should be fixed
before an RC is built.


On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion 
wrote:

> Is there a list of issues, blockers, or todo items to be done in order to
> have 4.4 out ?  The only things I saw is the list of blocker currently
> having 4 blocker (
> https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112)
>
> Does this mean that even if all blockers are fixed getting the branch 4.4.0
> able to build and be a workable CloudStack is a release manager nightmare?
>
>
> Pierre-Luc Dion
> Architecte de Solution Cloud | Cloud Solutions Architect
> 855-OK-CLOUD (855-652-5683) x1101
> - - -
>
> *CloudOps*420 rue Guy
> Montréal QC  H3J 1S6
> www.cloudops.com
> @CloudOps_
>
>
> On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Yeah, I am concerned about 4.4 getting farther behind schedule, as well,
> > but I agree with David that we should not cancel it.
> >
> > I know it might be a pain, but I wonder if the RM would be willing to
> "nag"
> > people every few days (just an e-mail to dev@) about the current list of
> > blockers and their progress and to see if people need help and others
> might
> > be willing and able to do so.
> >
> >
> > On Wed, Jun 11, 2014 at 10:08 AM, David Nalley  wrote:
> >
> > > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers 
> > wrote:
> > > > Hey all,
> > > >
> > > > I’m getting somewhat concerned about the 4.4 release. We don’t seems
> to
> > > be able to get the 4.4 branch in shape for a release candidate and
> > > meanwhile master is diverging further and further. We also know that
> once
> > > we hit the RC phase we will probably need a sizable number of
> iterations
> > to
> > > eventually ship the release. Based on past experience, if we keep up
> like
> > > this we will have another release that will actually be released way
> > after
> > > the feature freeze for the next release (July 18). Probably leaving us
> in
> > > the same bad spot for the next release.
> > > >
> > > > I tried to come up with a number of solutions that could rectify the
> > > situation and help the release move forward, but i can’t think of any.
> > Save
> > > for some options that might be considered extreme ideas. One the the
> more
> > > prominent ideas in my mind at the moment is skipping the 4.4 release
> all
> > > together and combine it with the next planned release (whether its 5.0
> or
> > > 4.5). This would require a community effort to focus on quality in the
> > next
> > > month and basically freeze the master for features and have a community
> > > wide push for quality to get the next release out on schedule.
> > > >
> > > > But before i go on and shout out even more drastic ideas, what do you
> > > think about the current 4.4 release. How close do you feel that we are
> to
> > > having a releasable product?
> > > >
> > >
> > > So this sounds very familiar to a discussion we had in 4.1 or 4.2
> > > timeframes. (I may have even been one of the folks proposing similar
> > > ideas, I don't recall)
> > >
> > > To save you some reading I am -1 on the idea of canceling 4.4. (though
> > > really - anyone can propose a release and ask for votes, we have
> > > adopted a bit more rigor, but that structure isn't demanded.)
> > >
> > > Here's the issues I see:
> > > 1. We set the expectation that 4.4 is coming; people worked hard to
> > > get features in, and our users are waiting on it.
> > > 2. We may not be perfect from a schedule perspective, but giving up on
> > > a release is a pretty negative thing to do - whats the reaction going
> > > to be?
> > > 3. Do you think we are in a position to make 4.5 any better? Speaking
> > > very frankly, I worry that we are not. I don't think that we have
> > > either the tooling or the social desire at present to make significant
> > > strides here. We don't dictate the priorities for individual
> > > developers. It might be a different story if we were in a corporate
> > > shop and could control what folks work on, it might be a different
> > > story.
> > >
> > > --David
> > >
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
> >
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

Re: [DISCUSS] Release 4.4

[Amogh Vasekar]

Hi,

AFAIK a couple of Automation blockers [1] [2], which had no owner
assigned, were moved to critical.

[1] CLOUDSTACK-6842
[2] CLOUDSTACK-6825

Thanks,
Amogh



On 6/11/14 10:33 AM, "Mike Tutkowski"  wrote:

>we have four blockers remaining...all network
>oriented.
>
>Murali Reddy has two. All four have an owner and presumably progress is
>being made.

Re: [DISCUSS] Release 4.4

[Alena Prokharchyk]

CLOUDSTACK-6825 happens while doing object access check in
ParamProcessWorker. Min/Prachi, can you take a look to see if its related
to RBAC feature?


-Alena.

On 6/11/14, 10:45 AM, "Amogh Vasekar"  wrote:

>Hi,
>
>AFAIK a couple of Automation blockers [1] [2], which had no owner
>assigned, were moved to critical.
>
>[1] CLOUDSTACK-6842
>[2] CLOUDSTACK-6825
>
>Thanks,
>Amogh
>
>
>
>On 6/11/14 10:33 AM, "Mike Tutkowski" 
>wrote:
>
>>we have four blockers remaining...all network
>>oriented.
>>
>>Murali Reddy has two. All four have an owner and presumably progress is
>>being made.
>

Re: [DISCUSS] Release 4.4

[Marcus]

Just need a way to get people to see branches through to release. Freeze
master or something. Releases will go out the door faster if it has to be
done.


On Wed, Jun 11, 2014 at 11:58 AM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> CLOUDSTACK-6825 happens while doing object access check in
> ParamProcessWorker. Min/Prachi, can you take a look to see if its related
> to RBAC feature?
>
>
> -Alena.
>
> On 6/11/14, 10:45 AM, "Amogh Vasekar"  wrote:
>
> >Hi,
> >
> >AFAIK a couple of Automation blockers [1] [2], which had no owner
> >assigned, were moved to critical.
> >
> >[1] CLOUDSTACK-6842
> >[2] CLOUDSTACK-6825
> >
> >Thanks,
> >Amogh
> >
> >
> >
> >On 6/11/14 10:33 AM, "Mike Tutkowski" 
> >wrote:
> >
> >>we have four blockers remaining...all network
> >>oriented.
> >>
> >>Murali Reddy has two. All four have an owner and presumably progress is
> >>being made.
> >
>
>

RE: Anybody addressing this bug ? Overlaping IP subnets across different vlans

[Anthony Xu]

You can add overlapping IP subnets across different vlans if all vlans belong 
to guest network.

CS treats public network differently, CS doesn't want public subnet overlap 
with other guest network.

If different vlans are routable, it is possible that a VM has the same ip as a 
system VM, public ip is accessible from outside, duplicate ip might cause 
system VMs stop working.

It is very hard for us to help users to recover from this scenarios.

Basically you want to use the same subnet for both public network and guest 
network, maybe basic zone is better fit for you.

Anthony

 




-Original Message-
From: Murali Reddy 
Sent: Wednesday, June 11, 2014 2:45 AM
To: dev@cloudstack.apache.org; Anthony Xu
Subject: Re: Anybody addressing this bug ? Overlaping IP subnets across 
different vlans

This is not related to portable IP. This enforcement was added as part of 
commit 657d9e4789d73c7c8ed460e59f088b8cb9aa7697.

Anothony might have context for this check.

On 11/06/14 2:18 PM, "Andrija Panic"  wrote:

>It was not there pre 4.3, and it's just causing me problems, I had to 
>manually add database entries to vlan and user_ip_address tables, not 
>very convinient...
>Thanks,
>Andrija
>
>
>On 11 June 2014 02:45, Chiradeep Vittal 
>wrote:
>
>> Not sure what this has to do with Portable IP. But I agree that the 
>>check  should be removed.
>>
>> From: ilya musayev > ilya.mailing.li...@gmail.com>>
>> Reply-To: "dev@cloudstack.apache.org"
>><
>> dev@cloudstack.apache.org>
>> Date: Friday, June 6, 2014 at 10:38 AM
>> To: "dev@cloudstack.apache.org" <  
>>dev@cloudstack.apache.org>
>> Subject: Re: Anybody addressing this bug ? Overlaping IP subnets 
>>across  different vlans
>>
>> Andrija
>>
>> I dont know if we can qualify this as a bug, this check was placed 
>> with some purpose in mind - yet its not clear what it is and why 
>> would someone think its bad.
>>
>>
>> 
>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=a3
>>b1a
>>49c303a929c754561ca07fd8a9ed84e0382
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-3911
>>
>> Chime in on the discussion in thread above,
>>
>> Regards,
>> ilya
>>
>>
>> On 6/6/14, 5:48 AM, Andrija Panic wrote:
>> Hi,
>> aftger upgrade to 4.3, I reported a bug where CS will not let me add 
>> additional IP ranges when there are 2 vlans using same IP range - 
>> I don't see point comparing IP ranges across two separate broadcast 
>> domains...
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6814
>>
>> Thanks,
>>
>>
>>
>
>
>--
>
>Andrija Panić
>--
>  http://admintweets.com
>--
>

Re: [DISCUSS] Release 4.4

[Nitin Mehta]

But the blockers/criticals would keep coming unless its certified that the
new features have been tested with some confidence and that the basic
functionalities work.

Thanks,
-Nitin

On 11/06/14 10:33 AM, "Mike Tutkowski" 
wrote:

>According to that list, we have four blockers remaining...all network
>oriented.
>
>Murali Reddy has two. All four have an owner and presumably progress is
>being made.
>
>I guess it would be a good idea if we triaged critical defects and
>determined once the blockers are done if any of those should be fixed
>before an RC is built.
>
>
>On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion 
>wrote:
>
>> Is there a list of issues, blockers, or todo items to be done in order
>>to
>> have 4.4 out ?  The only things I saw is the list of blocker currently
>> having 4 blocker (
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112)
>>
>> Does this mean that even if all blockers are fixed getting the branch
>>4.4.0
>> able to build and be a workable CloudStack is a release manager
>>nightmare?
>>
>>
>> Pierre-Luc Dion
>> Architecte de Solution Cloud | Cloud Solutions Architect
>> 855-OK-CLOUD (855-652-5683) x1101
>> - - -
>>
>> *CloudOps*420 rue Guy
>> Montréal QC  H3J 1S6
>> www.cloudops.com
>> @CloudOps_
>>
>>
>> On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>> > Yeah, I am concerned about 4.4 getting farther behind schedule, as
>>well,
>> > but I agree with David that we should not cancel it.
>> >
>> > I know it might be a pain, but I wonder if the RM would be willing to
>> "nag"
>> > people every few days (just an e-mail to dev@) about the current list
>>of
>> > blockers and their progress and to see if people need help and others
>> might
>> > be willing and able to do so.
>> >
>> >
>> > On Wed, Jun 11, 2014 at 10:08 AM, David Nalley  wrote:
>> >
>> > > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers 
>> > wrote:
>> > > > Hey all,
>> > > >
>> > > > I¹m getting somewhat concerned about the 4.4 release. We don¹t
>>seems
>> to
>> > > be able to get the 4.4 branch in shape for a release candidate and
>> > > meanwhile master is diverging further and further. We also know that
>> once
>> > > we hit the RC phase we will probably need a sizable number of
>> iterations
>> > to
>> > > eventually ship the release. Based on past experience, if we keep up
>> like
>> > > this we will have another release that will actually be released way
>> > after
>> > > the feature freeze for the next release (July 18). Probably leaving
>>us
>> in
>> > > the same bad spot for the next release.
>> > > >
>> > > > I tried to come up with a number of solutions that could rectify
>>the
>> > > situation and help the release move forward, but i can¹t think of
>>any.
>> > Save
>> > > for some options that might be considered extreme ideas. One the the
>> more
>> > > prominent ideas in my mind at the moment is skipping the 4.4 release
>> all
>> > > together and combine it with the next planned release (whether its
>>5.0
>> or
>> > > 4.5). This would require a community effort to focus on quality in
>>the
>> > next
>> > > month and basically freeze the master for features and have a
>>community
>> > > wide push for quality to get the next release out on schedule.
>> > > >
>> > > > But before i go on and shout out even more drastic ideas, what do
>>you
>> > > think about the current 4.4 release. How close do you feel that we
>>are
>> to
>> > > having a releasable product?
>> > > >
>> > >
>> > > So this sounds very familiar to a discussion we had in 4.1 or 4.2
>> > > timeframes. (I may have even been one of the folks proposing similar
>> > > ideas, I don't recall)
>> > >
>> > > To save you some reading I am -1 on the idea of canceling 4.4.
>>(though
>> > > really - anyone can propose a release and ask for votes, we have
>> > > adopted a bit more rigor, but that structure isn't demanded.)
>> > >
>> > > Here's the issues I see:
>> > > 1. We set the expectation that 4.4 is coming; people worked hard to
>> > > get features in, and our users are waiting on it.
>> > > 2. We may not be perfect from a schedule perspective, but giving up
>>on
>> > > a release is a pretty negative thing to do - whats the reaction
>>going
>> > > to be?
>> > > 3. Do you think we are in a position to make 4.5 any better?
>>Speaking
>> > > very frankly, I worry that we are not. I don't think that we have
>> > > either the tooling or the social desire at present to make
>>significant
>> > > strides here. We don't dictate the priorities for individual
>> > > developers. It might be a different story if we were in a corporate
>> > > shop and could control what folks work on, it might be a different
>> > > story.
>> > >
>> > > --David
>> > >
>> >
>> >
>> >
>> > --
>> > *Mike Tutkowski*
>> > *Senior CloudStack Developer, SolidFire Inc.*
>> > e: mike.tutkow...@solidfire.com
>> > o: 303.746.7302
>> > Advancing the way the world uses the cloud
>> > 

Re: [DISCUSS] Release 4.4

[Min Chen]

I have assigned CLOUDSTACK-6825 to me. But from the stack trace, it seems
failing in doing check access on the snapshot owner that is not active
anymore, feel like a racing condition happening on automation setup.
Rayees, several points to clarify:
1. Is this still happening on recent automation run on KVM? Based on the
error, it should be hypervisor independent.
2. Is the owner of the snapshot passed in createTemplate call already
deleted?

Thanks
-min



On 6/11/14 10:58 AM, "Alena Prokharchyk" 
wrote:

>CLOUDSTACK-6825 happens while doing object access check in
>ParamProcessWorker. Min/Prachi, can you take a look to see if its related
>to RBAC feature?
>
>
>-Alena.
>
>On 6/11/14, 10:45 AM, "Amogh Vasekar"  wrote:
>
>>Hi,
>>
>>AFAIK a couple of Automation blockers [1] [2], which had no owner
>>assigned, were moved to critical.
>>
>>[1] CLOUDSTACK-6842
>>[2] CLOUDSTACK-6825
>>
>>Thanks,
>>Amogh
>>
>>
>>
>>On 6/11/14 10:33 AM, "Mike Tutkowski" 
>>wrote:
>>
>>>we have four blockers remaining...all network
>>>oriented.
>>>
>>>Murali Reddy has two. All four have an owner and presumably progress is
>>>being made.
>>
>

RE: NetworkOrchestrator selects 2 NetworkGurus at one time....

[Ritu Sabharwal]

Thanks Chiradeep and Murali for the reply!

I am thinking of explicitly telling ExternalNetworkGuru to skip design when 
Brocade plugin is designing the network. I don't want to disable 
ExternalNetworkGuru from default build when Brocade plugin is not present so 
won't exclude it from the spring class loader.

Thanks & Regards,
Ritu S.

-Original Message-
From: Murali Reddy [mailto:murali.re...@citrix.com] 
Sent: Tuesday, June 10, 2014 10:54 PM
To: Chiradeep Vittal; dev@cloudstack.apache.org
Cc: Sheng Yang; Jayapal Reddy Uradi; Alena Prokharchyk
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

This is know design issue. Unlike service orchestration (which has prescriptive 
way to tell which network elements to be called for with network offerings ) 
there is no such logic for network design. Orchestrator just loops through all 
the network guru's asking to design the network which can results in one or 
more networks. Hugo did a cleanup [1] but I believe it was not merged as there 
was no consensus. There is 1-1 mapping between isolation type and Guru but In 
this case both Brocade Guru and ExternalNetworkGuru will attempt to design the 
VLAN isolated networks.

One in-elegent solution is to hard code ExternalGuestNetworu guru to skip 
network deign when Brocade plug-in is supposed to do design the network. Other 
option could be exclude ExternalNetworkGuru bean from spring class loader.

[1] https://www.mail-archive.com/dev@cloudstack.apache.org/msg17344.html

From: Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>
Date: Wednesday, 11 June 2014 6:24 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Cc: Sheng Yang mailto:sheng.y...@citrix.com>>, Murali 
Reddy mailto:murali.re...@citrix.com>>, Jayapal Reddy 
Uradi mailto:jayapalreddy.ur...@citrix.com>>, 
Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

That is strange. Looks like a bug to me. That is because the 
ExternalGuestNetworkGuru returns 'true' for canHandle.

From: Ritu Sabharwal mailto:rsabh...@brocade.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, June 10, 2014 at 11:02 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: NetworkOrchestrator selects 2 NetworkGurus at one time

Hi,

I am writing a Network Guru for automatically orchestrating Brocade VDX 
switches to provide tenant isolation via VLAN. In my NetworkGuru, I have 
implemented the canHandle() method for Guest isolated network in Advanced zone 
using VLAN isolation. When the NetworkOrchestrator selects the NetworkGuru, it 
selects my NetworkGuru and the ExternalGuestNetworkGuru also and I see 2 
networks created. How do I make sure that ExternalGuestNetworkGuru is not 
selected by NetworkOrchestrator.

Thanks & Regards,
Ritu S.

Re: [DISCUSS] Release 4.4

[Ove Ewerlid]

Seems to me there are two issues that comes up frequently when snapshots 
on ACS+KVM are discussed on these lists;


 1) There is an option to enable/disable snapshots on ACS with KVM 
hypervisor, default is not enabled.


 2) The "qemu-img convert" on recent RHEL6 systems lacks support for 
the option to select a specific snapshot (-s) to create the image from, 
without this option, creating a template from a snapshot is not 
possible. (unless a version of qemu-img from a system that do have this 
option is ported over).


CLOUDSTACK-6825 may be about something else.

/Ove

On 06/11/2014 08:38 PM, Min Chen wrote:

I have assigned CLOUDSTACK-6825 to me. But from the stack trace, it seems
failing in doing check access on the snapshot owner that is not active
anymore, feel like a racing condition happening on automation setup.
Rayees, several points to clarify:
1. Is this still happening on recent automation run on KVM? Based on the
error, it should be hypervisor independent.
2. Is the owner of the snapshot passed in createTemplate call already
deleted?

Thanks
-min



On 6/11/14 10:58 AM, "Alena Prokharchyk" 
wrote:


CLOUDSTACK-6825 happens while doing object access check in
ParamProcessWorker. Min/Prachi, can you take a look to see if its related
to RBAC feature?


-Alena.

On 6/11/14, 10:45 AM, "Amogh Vasekar"  wrote:


Hi,

AFAIK a couple of Automation blockers [1] [2], which had no owner
assigned, were moved to critical.

[1] CLOUDSTACK-6842
[2] CLOUDSTACK-6825

Thanks,
Amogh



On 6/11/14 10:33 AM, "Mike Tutkowski" 
wrote:


we have four blockers remaining...all network
oriented.

Murali Reddy has two. All four have an owner and presumably progress is
being made.









--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706668199 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)

RE: [PROPOSAL] Brocade network plugin to orchestrate Brocade VDX Switches for CloudStack 4.5

[Ritu Sabharwal]

Thanks Chiradeep! Please see my answers inlined.

Thanks & Regards,
Ritu S.

-Original Message-
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] 
Sent: Tuesday, June 10, 2014 5:12 PM
To: dev@cloudstack.apache.org
Cc: Prakash Kaligotla; Nagendra Jaladanki
Subject: Re: [PROPOSAL] Brocade network plugin to orchestrate Brocade VDX 
Switches for CloudStack 4.5

Well done.
Question: How do you figure out the VLAN -to- Brocade switch port mapping? By 
using the mac address of the VM nic?

[RS]: The plugin creates a port profile for each network and at the time of VM 
creation, associates the mac address of the VM nic to the respective network's 
port profile. 

Comment: It looks like you are creating a table (BrocadeNetworkHostMapping). 
Could you add details of this table (schema). Make sure this table appears in 
any upgrade scripts from previous releases.

[RS]: I will add the schema for the BrocadeNetworkHostMapping table. I have 
added this table to create-schema.sql script. For 4.5, upgrade is supported  
from what all releases? I will add this to the respective scripts.

From: Ritu Sabharwal mailto:rsabh...@brocade.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, June 10, 2014 at 11:51 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Cc: Prakash Kaligotla mailto:pkali...@brocade.com>>, 
Nagendra Jaladanki mailto:njala...@brocade.com>>
Subject: [PROPOSAL] Brocade network plugin to orchestrate Brocade VDX Switches 
for CloudStack 4.5

Hi CS Developers,

I have added the Design document for the Plugin in the wiki.  Here is the link 
: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Brocade+Network+Plugin+to+Orchestrate+Brocade+VDX+Switches

Please review it and provide your comments.

Thanks & Regards,
Ritu S.

Re: irc meeting on rvr4vpc

[Sheng Yang]

One note:

In fact the split of MASTER is not a big issue, because that would only
happen if network runs bad enough, which already cause packet loss.

The problem is it should recover from that situation fast enough.
Previously due to ARP ping from BACKUP router(which thought it would
replace MASTER), upstream switch would redirect the traffic to original
BACKUP router for a while, then as soon as network recovered, MASTER would
preempt BACKUP once again. But it may take some time for upstream switch to
aware that MAC/Port/IP mapping has been changed. We once tried different
MAC for MASTER and BACKUP but found it would result in upstream switch fail
to recognize the MASTER again. Now we're still using same MAC for MASTER
and BACKUP, and upstream switch can handle the situation better.

--Sheng


On Wed, Jun 11, 2014 at 12:48 AM, Daan Hoogland <
dhoogl...@schubergphilis.com> wrote:

> H,
>
> We had a little meeting on the state of this feature and the way to go. I
> have no karma for ASFBot meetings so here is my excerpt from the transcript:
>
> Attendance:
> K3KH Karl Harris
> Yasker Sheng Yang
> Spark404 Hugo Trippaers
> echaz Eric Chazas
> LeoSimons Leo Simons
> dahn Daan Hoogland
>
> others where present in the room but not active in the meeting
>
> Agenda:
> -  Feasibility experiment plans by Schuberg Philis
> -  Reusable work by Karl
> -  Problems Citrix encountered with the regular redundant router
> (and how to avoid them)
> -  Work division
> -  (next meeting needed?)
>
> We tried to follow the agenda but were not very strict on it. I'll
> summarize outcome per agenda bullet:
>
> Schuberg Philis wants to implement a feasibility redundant router on a
> simulated vpc environment using the operational expertise it has in house.
> The outcome would then be back ported to the device, it's agent and the
> management server.
>
> The implementation tactics is to create a json like configuration
> description and to let the device do its own configuration. The idea is to
> have a single device for normal and vpc routers and to let the redundancy
> be a mere property of it. This should lead to the ultimate objective which
> is to have a single relatively simple maintainable device.
>
> Karl will describe his endeavors in adapting the existing device on list.
>
> Sheng described the QA problems Citrix had with the existing redundant
> capabilities of the VR and assured us that only one real problem persists.
> The failover time of 3 seconds occasionally leads to a split brain which
> leads to two VR's assuming the role of master. As the management server in
> a busy environment can take up to 30 seconds the to detect a failover this
> can lead to unacceptable outage. One possible solution, to have the
> management server serve as negotiator on such occasions, will be hard to
> implement due to this latency. Noticeably both routers use the same mac
> address on the interface to the load balancer.
>
> The resources available by Citrix are uncertain. Plan and design needs to
> be done. It is agreed that we will work in parallel (Schuberg Philis and
> Citrix) but keep in close contact. The amount of resources Sungard has for
> this is not discussed. Karl will keep involved.
>
> We agreed to have a next meeting at 20:00 UTC on June the 17th
>
> Can someone give me Karma to use ASFBot for this one, please?
>
> \DaanH
>
>

Re: [DISCUSS] Release 4.4

[Daan Hoogland]

It is said by evil tongues in this mail thread that me, the RM does
not nag enough about the 4.4 branch status and the bugs marked to
apply to it. Worse; those evil tongues might just be right. In can
hereby say without reservation and with full heart and soul that I
will better my life in this perspect.

With that of my chest I know that Hugo's mail was partially inspired
on my nagging about the following: I don't care if cloudstack explodes
and takes the earth and the moon down with it in its destruction, a
bug is not a blocker unless we on this list decide that it blocks us
from +1'ing a RC to be released. I do not say that critical issues
aren't possible blockers but that should always be discussed. Also all
this does not exempt us from triaging every bug down to trivial ones.
As I discussed with my other colleague, Ian, the chance is real that a
trivial bug is a blocker in someones niche environment with their
niche use-case.

In fact I think that no one should alter the default prio of any issue
without discussing it on list.

more nagging to follow,
Daan

On Wed, Jun 11, 2014 at 8:36 PM, Nitin Mehta  wrote:
> But the blockers/criticals would keep coming unless its certified that the
> new features have been tested with some confidence and that the basic
> functionalities work.
>
> Thanks,
> -Nitin
>
> On 11/06/14 10:33 AM, "Mike Tutkowski" 
> wrote:
>
>>According to that list, we have four blockers remaining...all network
>>oriented.
>>
>>Murali Reddy has two. All four have an owner and presumably progress is
>>being made.
>>
>>I guess it would be a good idea if we triaged critical defects and
>>determined once the blockers are done if any of those should be fixed
>>before an RC is built.
>>
>>
>>On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion 
>>wrote:
>>
>>> Is there a list of issues, blockers, or todo items to be done in order
>>>to
>>> have 4.4 out ?  The only things I saw is the list of blocker currently
>>> having 4 blocker (
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112)
>>>
>>> Does this mean that even if all blockers are fixed getting the branch
>>>4.4.0
>>> able to build and be a workable CloudStack is a release manager
>>>nightmare?
>>>
>>>
>>> Pierre-Luc Dion
>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>> 855-OK-CLOUD (855-652-5683) x1101
>>> - - -
>>>
>>> *CloudOps*420 rue Guy
>>> Montréal QC  H3J 1S6
>>> www.cloudops.com
>>> @CloudOps_
>>>
>>>
>>> On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
>>> > Yeah, I am concerned about 4.4 getting farther behind schedule, as
>>>well,
>>> > but I agree with David that we should not cancel it.
>>> >
>>> > I know it might be a pain, but I wonder if the RM would be willing to
>>> "nag"
>>> > people every few days (just an e-mail to dev@) about the current list
>>>of
>>> > blockers and their progress and to see if people need help and others
>>> might
>>> > be willing and able to do so.
>>> >
>>> >
>>> > On Wed, Jun 11, 2014 at 10:08 AM, David Nalley  wrote:
>>> >
>>> > > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers 
>>> > wrote:
>>> > > > Hey all,
>>> > > >
>>> > > > I¹m getting somewhat concerned about the 4.4 release. We don¹t
>>>seems
>>> to
>>> > > be able to get the 4.4 branch in shape for a release candidate and
>>> > > meanwhile master is diverging further and further. We also know that
>>> once
>>> > > we hit the RC phase we will probably need a sizable number of
>>> iterations
>>> > to
>>> > > eventually ship the release. Based on past experience, if we keep up
>>> like
>>> > > this we will have another release that will actually be released way
>>> > after
>>> > > the feature freeze for the next release (July 18). Probably leaving
>>>us
>>> in
>>> > > the same bad spot for the next release.
>>> > > >
>>> > > > I tried to come up with a number of solutions that could rectify
>>>the
>>> > > situation and help the release move forward, but i can¹t think of
>>>any.
>>> > Save
>>> > > for some options that might be considered extreme ideas. One the the
>>> more
>>> > > prominent ideas in my mind at the moment is skipping the 4.4 release
>>> all
>>> > > together and combine it with the next planned release (whether its
>>>5.0
>>> or
>>> > > 4.5). This would require a community effort to focus on quality in
>>>the
>>> > next
>>> > > month and basically freeze the master for features and have a
>>>community
>>> > > wide push for quality to get the next release out on schedule.
>>> > > >
>>> > > > But before i go on and shout out even more drastic ideas, what do
>>>you
>>> > > think about the current 4.4 release. How close do you feel that we
>>>are
>>> to
>>> > > having a releasable product?
>>> > > >
>>> > >
>>> > > So this sounds very familiar to a discussion we had in 4.1 or 4.2
>>> > > timeframes. (I may have even been one of the folks proposing similar
>>> > > ideas, I don't recall)
>>> > >
>>> > > To save you some reading I am -1 on the idea 

Re: [DISCUSS] Release 4.4

[Alena Prokharchyk]

If we confirm that its a race condition, then the bug should be punted to
4.5

On 6/11/14, 11:38 AM, "Min Chen"  wrote:

>I have assigned CLOUDSTACK-6825 to me. But from the stack trace, it seems
>failing in doing check access on the snapshot owner that is not active
>anymore, feel like a racing condition happening on automation setup.
>Rayees, several points to clarify:
>1. Is this still happening on recent automation run on KVM? Based on the
>error, it should be hypervisor independent.
>2. Is the owner of the snapshot passed in createTemplate call already
>deleted?
>
>Thanks
>-min
>
>
>
>On 6/11/14 10:58 AM, "Alena Prokharchyk" 
>wrote:
>
>>CLOUDSTACK-6825 happens while doing object access check in
>>ParamProcessWorker. Min/Prachi, can you take a look to see if its related
>>to RBAC feature?
>>
>>
>>-Alena.
>>
>>On 6/11/14, 10:45 AM, "Amogh Vasekar"  wrote:
>>
>>>Hi,
>>>
>>>AFAIK a couple of Automation blockers [1] [2], which had no owner
>>>assigned, were moved to critical.
>>>
>>>[1] CLOUDSTACK-6842
>>>[2] CLOUDSTACK-6825
>>>
>>>Thanks,
>>>Amogh
>>>
>>>
>>>
>>>On 6/11/14 10:33 AM, "Mike Tutkowski" 
>>>wrote:
>>>
we have four blockers remaining...all network
oriented.

Murali Reddy has two. All four have an owner and presumably progress is
being made.
>>>
>>
>

Re: [DISCUSS] Release 4.4

[Daan Hoogland]

On Wed, Jun 11, 2014 at 10:31 PM, Alena Prokharchyk
 wrote:
> If we confirm that its a race condition, then the bug should be punted to
> 4.5

or solve it?

-- 
Daan

Re: [DISCUSS] Release 4.4

[Alena Prokharchyk]

I guess its time to define what qualifies to be called a blocker bug. Is
blocker something that:

1) happens on all the setups?
2) blocks core features from executing

Because I think that the bug happening on KVM only (lets say the vms fail
to start = core feature), can be considered as a blocker although it
happens just on a particular hypervisor/storage setup (niche environment?)

-Alena.


On 6/11/14, 12:53 PM, "Daan Hoogland"  wrote:

>It is said by evil tongues in this mail thread that me, the RM does
>not nag enough about the 4.4 branch status and the bugs marked to
>apply to it. Worse; those evil tongues might just be right. In can
>hereby say without reservation and with full heart and soul that I
>will better my life in this perspect.
>
>With that of my chest I know that Hugo's mail was partially inspired
>on my nagging about the following: I don't care if cloudstack explodes
>and takes the earth and the moon down with it in its destruction, a
>bug is not a blocker unless we on this list decide that it blocks us
>from +1'ing a RC to be released. I do not say that critical issues
>aren't possible blockers but that should always be discussed. Also all
>this does not exempt us from triaging every bug down to trivial ones.
>As I discussed with my other colleague, Ian, the chance is real that a
>trivial bug is a blocker in someones niche environment with their
>niche use-case.
>
>In fact I think that no one should alter the default prio of any issue
>without discussing it on list.
>
>more nagging to follow,
>Daan
>
>On Wed, Jun 11, 2014 at 8:36 PM, Nitin Mehta 
>wrote:
>> But the blockers/criticals would keep coming unless its certified that
>>the
>> new features have been tested with some confidence and that the basic
>> functionalities work.
>>
>> Thanks,
>> -Nitin
>>
>> On 11/06/14 10:33 AM, "Mike Tutkowski" 
>> wrote:
>>
>>>According to that list, we have four blockers remaining...all network
>>>oriented.
>>>
>>>Murali Reddy has two. All four have an owner and presumably progress is
>>>being made.
>>>
>>>I guess it would be a good idea if we triaged critical defects and
>>>determined once the blockers are done if any of those should be fixed
>>>before an RC is built.
>>>
>>>
>>>On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion 
>>>wrote:
>>>
 Is there a list of issues, blockers, or todo items to be done in order
to
 have 4.4 out ?  The only things I saw is the list of blocker currently
 having 4 blocker (
 https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112)

 Does this mean that even if all blockers are fixed getting the branch
4.4.0
 able to build and be a workable CloudStack is a release manager
nightmare?


 Pierre-Luc Dion
 Architecte de Solution Cloud | Cloud Solutions Architect
 855-OK-CLOUD (855-652-5683) x1101
 - - -

 *CloudOps*420 rue Guy
 Montréal QC  H3J 1S6
 www.cloudops.com
 @CloudOps_


 On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
 mike.tutkow...@solidfire.com> wrote:

 > Yeah, I am concerned about 4.4 getting farther behind schedule, as
well,
 > but I agree with David that we should not cancel it.
 >
 > I know it might be a pain, but I wonder if the RM would be willing
to
 "nag"
 > people every few days (just an e-mail to dev@) about the current
list
of
 > blockers and their progress and to see if people need help and
others
 might
 > be willing and able to do so.
 >
 >
 > On Wed, Jun 11, 2014 at 10:08 AM, David Nalley 
wrote:
 >
 > > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers 
 > wrote:
 > > > Hey all,
 > > >
 > > > I¹m getting somewhat concerned about the 4.4 release. We don¹t
seems
 to
 > > be able to get the 4.4 branch in shape for a release candidate and
 > > meanwhile master is diverging further and further. We also know
that
 once
 > > we hit the RC phase we will probably need a sizable number of
 iterations
 > to
 > > eventually ship the release. Based on past experience, if we keep
up
 like
 > > this we will have another release that will actually be released
way
 > after
 > > the feature freeze for the next release (July 18). Probably
leaving
us
 in
 > > the same bad spot for the next release.
 > > >
 > > > I tried to come up with a number of solutions that could rectify
the
 > > situation and help the release move forward, but i can¹t think of
any.
 > Save
 > > for some options that might be considered extreme ideas. One the
the
 more
 > > prominent ideas in my mind at the moment is skipping the 4.4
release
 all
 > > together and combine it with the next planned release (whether its
5.0
 or
 > > 4.5). This would require a community effort to focus on quality in
the
 > next
 > > month and ba

Re: [DISCUSS] Release 4.4

[Daan Hoogland]

I agree, but I wouldn't pin 'blocker' by a definition of the nature of
the defect. A blocker is something that blocks the community at large
from releasing. What you define here would be useful for more vague
prio definitions like 'critical', though. Of course a major defect in
any of the hypervisor - or network - or storage types can be
considered a blocker. But also they might not as they might have work
arounds. A blocker is really something that we should decide on on a
case by case basis, in my opinion.

On Wed, Jun 11, 2014 at 10:38 PM, Alena Prokharchyk
 wrote:
> I guess its time to define what qualifies to be called a blocker bug. Is
> blocker something that:
>
> 1) happens on all the setups?
> 2) blocks core features from executing
>
> Because I think that the bug happening on KVM only (lets say the vms fail
> to start = core feature), can be considered as a blocker although it
> happens just on a particular hypervisor/storage setup (niche environment?)
>
> -Alena.
>
>
> On 6/11/14, 12:53 PM, "Daan Hoogland"  wrote:
>
>>It is said by evil tongues in this mail thread that me, the RM does
>>not nag enough about the 4.4 branch status and the bugs marked to
>>apply to it. Worse; those evil tongues might just be right. In can
>>hereby say without reservation and with full heart and soul that I
>>will better my life in this perspect.
>>
>>With that of my chest I know that Hugo's mail was partially inspired
>>on my nagging about the following: I don't care if cloudstack explodes
>>and takes the earth and the moon down with it in its destruction, a
>>bug is not a blocker unless we on this list decide that it blocks us
>>from +1'ing a RC to be released. I do not say that critical issues
>>aren't possible blockers but that should always be discussed. Also all
>>this does not exempt us from triaging every bug down to trivial ones.
>>As I discussed with my other colleague, Ian, the chance is real that a
>>trivial bug is a blocker in someones niche environment with their
>>niche use-case.
>>
>>In fact I think that no one should alter the default prio of any issue
>>without discussing it on list.
>>
>>more nagging to follow,
>>Daan
>>
>>On Wed, Jun 11, 2014 at 8:36 PM, Nitin Mehta 
>>wrote:
>>> But the blockers/criticals would keep coming unless its certified that
>>>the
>>> new features have been tested with some confidence and that the basic
>>> functionalities work.
>>>
>>> Thanks,
>>> -Nitin
>>>
>>> On 11/06/14 10:33 AM, "Mike Tutkowski" 
>>> wrote:
>>>
According to that list, we have four blockers remaining...all network
oriented.

Murali Reddy has two. All four have an owner and presumably progress is
being made.

I guess it would be a good idea if we triaged critical defects and
determined once the blockers are done if any of those should be fixed
before an RC is built.


On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion 
wrote:

> Is there a list of issues, blockers, or todo items to be done in order
>to
> have 4.4 out ?  The only things I saw is the list of blocker currently
> having 4 blocker (
> https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112)
>
> Does this mean that even if all blockers are fixed getting the branch
>4.4.0
> able to build and be a workable CloudStack is a release manager
>nightmare?
>
>
> Pierre-Luc Dion
> Architecte de Solution Cloud | Cloud Solutions Architect
> 855-OK-CLOUD (855-652-5683) x1101
> - - -
>
> *CloudOps*420 rue Guy
> Montréal QC  H3J 1S6
> www.cloudops.com
> @CloudOps_
>
>
> On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Yeah, I am concerned about 4.4 getting farther behind schedule, as
>well,
> > but I agree with David that we should not cancel it.
> >
> > I know it might be a pain, but I wonder if the RM would be willing
>to
> "nag"
> > people every few days (just an e-mail to dev@) about the current
>list
>of
> > blockers and their progress and to see if people need help and
>others
> might
> > be willing and able to do so.
> >
> >
> > On Wed, Jun 11, 2014 at 10:08 AM, David Nalley 
>wrote:
> >
> > > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers 
> > wrote:
> > > > Hey all,
> > > >
> > > > I¹m getting somewhat concerned about the 4.4 release. We don¹t
>seems
> to
> > > be able to get the 4.4 branch in shape for a release candidate and
> > > meanwhile master is diverging further and further. We also know
>that
> once
> > > we hit the RC phase we will probably need a sizable number of
> iterations
> > to
> > > eventually ship the release. Based on past experience, if we keep
>up
> like
> > > this we will have another release that will actually be released
>way
> > after
> > > the 

Re: [DISCUSS] Release 4.4

[Alena Prokharchyk]

On 6/11/14, 1:45 PM, "Daan Hoogland"  wrote:

>I agree, but I wouldn't pin 'blocker' by a definition of the nature of
>the defect. A blocker is something that blocks the community at large
>from releasing. What you define here would be useful for more vague
>prio definitions like 'critical', though. Of course a major defect in
>any of the hypervisor - or network - or storage types can be
>considered a blocker. But also they might not as they might have work
>arounds.


> A blocker is really something that we should decide on on a
>case by case basis, in my opinion.

Agree, especially at this stage of the release.

>
>On Wed, Jun 11, 2014 at 10:38 PM, Alena Prokharchyk
> wrote:
>> I guess its time to define what qualifies to be called a blocker bug. Is
>> blocker something that:
>>
>> 1) happens on all the setups?
>> 2) blocks core features from executing
>>
>> Because I think that the bug happening on KVM only (lets say the vms
>>fail
>> to start = core feature), can be considered as a blocker although it
>> happens just on a particular hypervisor/storage setup (niche
>>environment?)
>>
>> -Alena.
>>
>>
>> On 6/11/14, 12:53 PM, "Daan Hoogland"  wrote:
>>
>>>It is said by evil tongues in this mail thread that me, the RM does
>>>not nag enough about the 4.4 branch status and the bugs marked to
>>>apply to it. Worse; those evil tongues might just be right. In can
>>>hereby say without reservation and with full heart and soul that I
>>>will better my life in this perspect.
>>>
>>>With that of my chest I know that Hugo's mail was partially inspired
>>>on my nagging about the following: I don't care if cloudstack explodes
>>>and takes the earth and the moon down with it in its destruction, a
>>>bug is not a blocker unless we on this list decide that it blocks us
>>>from +1'ing a RC to be released. I do not say that critical issues
>>>aren't possible blockers but that should always be discussed. Also all
>>>this does not exempt us from triaging every bug down to trivial ones.
>>>As I discussed with my other colleague, Ian, the chance is real that a
>>>trivial bug is a blocker in someones niche environment with their
>>>niche use-case.
>>>
>>>In fact I think that no one should alter the default prio of any issue
>>>without discussing it on list.
>>>
>>>more nagging to follow,
>>>Daan
>>>
>>>On Wed, Jun 11, 2014 at 8:36 PM, Nitin Mehta 
>>>wrote:
 But the blockers/criticals would keep coming unless its certified that
the
 new features have been tested with some confidence and that the basic
 functionalities work.

 Thanks,
 -Nitin

 On 11/06/14 10:33 AM, "Mike Tutkowski" 
 wrote:

>According to that list, we have four blockers remaining...all network
>oriented.
>
>Murali Reddy has two. All four have an owner and presumably progress
>is
>being made.
>
>I guess it would be a good idea if we triaged critical defects and
>determined once the blockers are done if any of those should be fixed
>before an RC is built.
>
>
>On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion 
>wrote:
>
>> Is there a list of issues, blockers, or todo items to be done in
>>order
>>to
>> have 4.4 out ?  The only things I saw is the list of blocker
>>currently
>> having 4 blocker (
>> 
>>https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112
>>)
>>
>> Does this mean that even if all blockers are fixed getting the
>>branch
>>4.4.0
>> able to build and be a workable CloudStack is a release manager
>>nightmare?
>>
>>
>> Pierre-Luc Dion
>> Architecte de Solution Cloud | Cloud Solutions Architect
>> 855-OK-CLOUD (855-652-5683) x1101
>> - - -
>>
>> *CloudOps*420 rue Guy
>> Montréal QC  H3J 1S6
>> www.cloudops.com
>> @CloudOps_
>>
>>
>> On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>> > Yeah, I am concerned about 4.4 getting farther behind schedule, as
>>well,
>> > but I agree with David that we should not cancel it.
>> >
>> > I know it might be a pain, but I wonder if the RM would be willing
>>to
>> "nag"
>> > people every few days (just an e-mail to dev@) about the current
>>list
>>of
>> > blockers and their progress and to see if people need help and
>>others
>> might
>> > be willing and able to do so.
>> >
>> >
>> > On Wed, Jun 11, 2014 at 10:08 AM, David Nalley 
>>wrote:
>> >
>> > > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers
>>
>> > wrote:
>> > > > Hey all,
>> > > >
>> > > > I¹m getting somewhat concerned about the 4.4 release. We don¹t
>>seems
>> to
>> > > be able to get the 4.4 branch in shape for a release candidate
>>and
>> > > meanwhile master is diverging further and further. We also know
>>that
>> once
>> > > we hit th

Re: [DISCUSS] Release 4.4

[Mike Tutkowski]

I agree - at this stage in the release, each blocker that remains should be
decided on a case-by-case basis if we still feel it is a blocker.


On Wed, Jun 11, 2014 at 2:54 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

>
>
> On 6/11/14, 1:45 PM, "Daan Hoogland"  wrote:
>
> >I agree, but I wouldn't pin 'blocker' by a definition of the nature of
> >the defect. A blocker is something that blocks the community at large
> >from releasing. What you define here would be useful for more vague
> >prio definitions like 'critical', though. Of course a major defect in
> >any of the hypervisor - or network - or storage types can be
> >considered a blocker. But also they might not as they might have work
> >arounds.
>
>
> > A blocker is really something that we should decide on on a
> >case by case basis, in my opinion.
>
> Agree, especially at this stage of the release.
>
> >
> >On Wed, Jun 11, 2014 at 10:38 PM, Alena Prokharchyk
> > wrote:
> >> I guess its time to define what qualifies to be called a blocker bug. Is
> >> blocker something that:
> >>
> >> 1) happens on all the setups?
> >> 2) blocks core features from executing
> >>
> >> Because I think that the bug happening on KVM only (lets say the vms
> >>fail
> >> to start = core feature), can be considered as a blocker although it
> >> happens just on a particular hypervisor/storage setup (niche
> >>environment?)
> >>
> >> -Alena.
> >>
> >>
> >> On 6/11/14, 12:53 PM, "Daan Hoogland"  wrote:
> >>
> >>>It is said by evil tongues in this mail thread that me, the RM does
> >>>not nag enough about the 4.4 branch status and the bugs marked to
> >>>apply to it. Worse; those evil tongues might just be right. In can
> >>>hereby say without reservation and with full heart and soul that I
> >>>will better my life in this perspect.
> >>>
> >>>With that of my chest I know that Hugo's mail was partially inspired
> >>>on my nagging about the following: I don't care if cloudstack explodes
> >>>and takes the earth and the moon down with it in its destruction, a
> >>>bug is not a blocker unless we on this list decide that it blocks us
> >>>from +1'ing a RC to be released. I do not say that critical issues
> >>>aren't possible blockers but that should always be discussed. Also all
> >>>this does not exempt us from triaging every bug down to trivial ones.
> >>>As I discussed with my other colleague, Ian, the chance is real that a
> >>>trivial bug is a blocker in someones niche environment with their
> >>>niche use-case.
> >>>
> >>>In fact I think that no one should alter the default prio of any issue
> >>>without discussing it on list.
> >>>
> >>>more nagging to follow,
> >>>Daan
> >>>
> >>>On Wed, Jun 11, 2014 at 8:36 PM, Nitin Mehta 
> >>>wrote:
>  But the blockers/criticals would keep coming unless its certified that
> the
>  new features have been tested with some confidence and that the basic
>  functionalities work.
> 
>  Thanks,
>  -Nitin
> 
>  On 11/06/14 10:33 AM, "Mike Tutkowski" 
>  wrote:
> 
> >According to that list, we have four blockers remaining...all network
> >oriented.
> >
> >Murali Reddy has two. All four have an owner and presumably progress
> >is
> >being made.
> >
> >I guess it would be a good idea if we triaged critical defects and
> >determined once the blockers are done if any of those should be fixed
> >before an RC is built.
> >
> >
> >On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion  >
> >wrote:
> >
> >> Is there a list of issues, blockers, or todo items to be done in
> >>order
> >>to
> >> have 4.4 out ?  The only things I saw is the list of blocker
> >>currently
> >> having 4 blocker (
> >>
> >>
> https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112
> >>)
> >>
> >> Does this mean that even if all blockers are fixed getting the
> >>branch
> >>4.4.0
> >> able to build and be a workable CloudStack is a release manager
> >>nightmare?
> >>
> >>
> >> Pierre-Luc Dion
> >> Architecte de Solution Cloud | Cloud Solutions Architect
> >> 855-OK-CLOUD (855-652-5683) x1101
> >> - - -
> >>
> >> *CloudOps*420 rue Guy
> >> Montréal QC  H3J 1S6
> >> www.cloudops.com
> >> @CloudOps_
> >>
> >>
> >> On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
> >> mike.tutkow...@solidfire.com> wrote:
> >>
> >> > Yeah, I am concerned about 4.4 getting farther behind schedule, as
> >>well,
> >> > but I agree with David that we should not cancel it.
> >> >
> >> > I know it might be a pain, but I wonder if the RM would be willing
> >>to
> >> "nag"
> >> > people every few days (just an e-mail to dev@) about the current
> >>list
> >>of
> >> > blockers and their progress and to see if people need help and
> >>others
> >> might
> >> > be willing and able to do so.
> >> >
> >>

Re: [DISCUSS] Release 4.4

[Daan Hoogland]

Well, I think we should always treat the status of blocker that way.
Something is a blocker if we feel it blocks us from releasing. Not
just in this stage but always. (I think I am repeating myself a tad)
In fact I feel we must treat those 90 critical issues the same way and
I dare not start to think about all the other bugs of lower prios.

On Wed, Jun 11, 2014 at 11:11 PM, Mike Tutkowski
 wrote:
> I agree - at this stage in the release, each blocker that remains should be
> decided on a case-by-case basis if we still feel it is a blocker.
>
>
> On Wed, Jun 11, 2014 at 2:54 PM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
>
>>
>>
>> On 6/11/14, 1:45 PM, "Daan Hoogland"  wrote:
>>
>> >I agree, but I wouldn't pin 'blocker' by a definition of the nature of
>> >the defect. A blocker is something that blocks the community at large
>> >from releasing. What you define here would be useful for more vague
>> >prio definitions like 'critical', though. Of course a major defect in
>> >any of the hypervisor - or network - or storage types can be
>> >considered a blocker. But also they might not as they might have work
>> >arounds.
>>
>>
>> > A blocker is really something that we should decide on on a
>> >case by case basis, in my opinion.
>>
>> Agree, especially at this stage of the release.
>>
>> >
>> >On Wed, Jun 11, 2014 at 10:38 PM, Alena Prokharchyk
>> > wrote:
>> >> I guess its time to define what qualifies to be called a blocker bug. Is
>> >> blocker something that:
>> >>
>> >> 1) happens on all the setups?
>> >> 2) blocks core features from executing
>> >>
>> >> Because I think that the bug happening on KVM only (lets say the vms
>> >>fail
>> >> to start = core feature), can be considered as a blocker although it
>> >> happens just on a particular hypervisor/storage setup (niche
>> >>environment?)
>> >>
>> >> -Alena.
>> >>
>> >>
>> >> On 6/11/14, 12:53 PM, "Daan Hoogland"  wrote:
>> >>
>> >>>It is said by evil tongues in this mail thread that me, the RM does
>> >>>not nag enough about the 4.4 branch status and the bugs marked to
>> >>>apply to it. Worse; those evil tongues might just be right. In can
>> >>>hereby say without reservation and with full heart and soul that I
>> >>>will better my life in this perspect.
>> >>>
>> >>>With that of my chest I know that Hugo's mail was partially inspired
>> >>>on my nagging about the following: I don't care if cloudstack explodes
>> >>>and takes the earth and the moon down with it in its destruction, a
>> >>>bug is not a blocker unless we on this list decide that it blocks us
>> >>>from +1'ing a RC to be released. I do not say that critical issues
>> >>>aren't possible blockers but that should always be discussed. Also all
>> >>>this does not exempt us from triaging every bug down to trivial ones.
>> >>>As I discussed with my other colleague, Ian, the chance is real that a
>> >>>trivial bug is a blocker in someones niche environment with their
>> >>>niche use-case.
>> >>>
>> >>>In fact I think that no one should alter the default prio of any issue
>> >>>without discussing it on list.
>> >>>
>> >>>more nagging to follow,
>> >>>Daan
>> >>>
>> >>>On Wed, Jun 11, 2014 at 8:36 PM, Nitin Mehta 
>> >>>wrote:
>>  But the blockers/criticals would keep coming unless its certified that
>> the
>>  new features have been tested with some confidence and that the basic
>>  functionalities work.
>> 
>>  Thanks,
>>  -Nitin
>> 
>>  On 11/06/14 10:33 AM, "Mike Tutkowski" 
>>  wrote:
>> 
>> >According to that list, we have four blockers remaining...all network
>> >oriented.
>> >
>> >Murali Reddy has two. All four have an owner and presumably progress
>> >is
>> >being made.
>> >
>> >I guess it would be a good idea if we triaged critical defects and
>> >determined once the blockers are done if any of those should be fixed
>> >before an RC is built.
>> >
>> >
>> >On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion > >
>> >wrote:
>> >
>> >> Is there a list of issues, blockers, or todo items to be done in
>> >>order
>> >>to
>> >> have 4.4 out ?  The only things I saw is the list of blocker
>> >>currently
>> >> having 4 blocker (
>> >>
>> >>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112
>> >>)
>> >>
>> >> Does this mean that even if all blockers are fixed getting the
>> >>branch
>> >>4.4.0
>> >> able to build and be a workable CloudStack is a release manager
>> >>nightmare?
>> >>
>> >>
>> >> Pierre-Luc Dion
>> >> Architecte de Solution Cloud | Cloud Solutions Architect
>> >> 855-OK-CLOUD (855-652-5683) x1101
>> >> - - -
>> >>
>> >> *CloudOps*420 rue Guy
>> >> Montréal QC  H3J 1S6
>> >> www.cloudops.com
>> >> @CloudOps_
>> >>
>> >>
>> >> On Wed, Jun 11, 2014 at 12:36 PM, Mike Tutkowski <
>> >> mike.tutkow...@solidfire.com> wrote:
>> 

Re: [DISCUSS] Release 4.4

[Mike Tutkowski]

Sounds reasonable

That being the case, do we feel we can build a first RC once our remaining
blockers are completed?


On Wed, Jun 11, 2014 at 3:19 PM, Daan Hoogland 
wrote:

> Well, I think we should always treat the status of blocker that way.
> Something is a blocker if we feel it blocks us from releasing. Not
> just in this stage but always. (I think I am repeating myself a tad)
> In fact I feel we must treat those 90 critical issues the same way and
> I dare not start to think about all the other bugs of lower prios.
>
> On Wed, Jun 11, 2014 at 11:11 PM, Mike Tutkowski
>  wrote:
> > I agree - at this stage in the release, each blocker that remains should
> be
> > decided on a case-by-case basis if we still feel it is a blocker.
> >
> >
> > On Wed, Jun 11, 2014 at 2:54 PM, Alena Prokharchyk <
> > alena.prokharc...@citrix.com> wrote:
> >
> >>
> >>
> >> On 6/11/14, 1:45 PM, "Daan Hoogland"  wrote:
> >>
> >> >I agree, but I wouldn't pin 'blocker' by a definition of the nature of
> >> >the defect. A blocker is something that blocks the community at large
> >> >from releasing. What you define here would be useful for more vague
> >> >prio definitions like 'critical', though. Of course a major defect in
> >> >any of the hypervisor - or network - or storage types can be
> >> >considered a blocker. But also they might not as they might have work
> >> >arounds.
> >>
> >>
> >> > A blocker is really something that we should decide on on a
> >> >case by case basis, in my opinion.
> >>
> >> Agree, especially at this stage of the release.
> >>
> >> >
> >> >On Wed, Jun 11, 2014 at 10:38 PM, Alena Prokharchyk
> >> > wrote:
> >> >> I guess its time to define what qualifies to be called a blocker
> bug. Is
> >> >> blocker something that:
> >> >>
> >> >> 1) happens on all the setups?
> >> >> 2) blocks core features from executing
> >> >>
> >> >> Because I think that the bug happening on KVM only (lets say the vms
> >> >>fail
> >> >> to start = core feature), can be considered as a blocker although it
> >> >> happens just on a particular hypervisor/storage setup (niche
> >> >>environment?)
> >> >>
> >> >> -Alena.
> >> >>
> >> >>
> >> >> On 6/11/14, 12:53 PM, "Daan Hoogland" 
> wrote:
> >> >>
> >> >>>It is said by evil tongues in this mail thread that me, the RM does
> >> >>>not nag enough about the 4.4 branch status and the bugs marked to
> >> >>>apply to it. Worse; those evil tongues might just be right. In can
> >> >>>hereby say without reservation and with full heart and soul that I
> >> >>>will better my life in this perspect.
> >> >>>
> >> >>>With that of my chest I know that Hugo's mail was partially inspired
> >> >>>on my nagging about the following: I don't care if cloudstack
> explodes
> >> >>>and takes the earth and the moon down with it in its destruction, a
> >> >>>bug is not a blocker unless we on this list decide that it blocks us
> >> >>>from +1'ing a RC to be released. I do not say that critical issues
> >> >>>aren't possible blockers but that should always be discussed. Also
> all
> >> >>>this does not exempt us from triaging every bug down to trivial ones.
> >> >>>As I discussed with my other colleague, Ian, the chance is real that
> a
> >> >>>trivial bug is a blocker in someones niche environment with their
> >> >>>niche use-case.
> >> >>>
> >> >>>In fact I think that no one should alter the default prio of any
> issue
> >> >>>without discussing it on list.
> >> >>>
> >> >>>more nagging to follow,
> >> >>>Daan
> >> >>>
> >> >>>On Wed, Jun 11, 2014 at 8:36 PM, Nitin Mehta  >
> >> >>>wrote:
> >>  But the blockers/criticals would keep coming unless its certified
> that
> >> the
> >>  new features have been tested with some confidence and that the
> basic
> >>  functionalities work.
> >> 
> >>  Thanks,
> >>  -Nitin
> >> 
> >>  On 11/06/14 10:33 AM, "Mike Tutkowski" <
> mike.tutkow...@solidfire.com>
> >>  wrote:
> >> 
> >> >According to that list, we have four blockers remaining...all
> network
> >> >oriented.
> >> >
> >> >Murali Reddy has two. All four have an owner and presumably
> progress
> >> >is
> >> >being made.
> >> >
> >> >I guess it would be a good idea if we triaged critical defects and
> >> >determined once the blockers are done if any of those should be
> fixed
> >> >before an RC is built.
> >> >
> >> >
> >> >On Wed, Jun 11, 2014 at 11:28 AM, Pierre-Luc Dion <
> pd...@cloudops.com
> >> >
> >> >wrote:
> >> >
> >> >> Is there a list of issues, blockers, or todo items to be done in
> >> >>order
> >> >>to
> >> >> have 4.4 out ?  The only things I saw is the list of blocker
> >> >>currently
> >> >> having 4 blocker (
> >> >>
> >> >>
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-6602?filter=12327112
> >> >>)
> >> >>
> >> >> Does this mean that even if all blockers are fixed getting the
> >> >>branch
> >> >>4.4.0
> >> >> able to build a

Re: [DISCUSS] Release 4.4

[Leo Simons]

Hey folks,

On 6/11/14, 6:36 PM, "Mike Tutkowski"  wrote:
>Yeah, I am concerned about 4.4 getting farther behind schedule, as well,
>but I agree with David that we should not cancel it.
>
>I know it might be a pain, but I wonder if the RM would be willing to
>"nag"
>people every few days (just an e-mail to dev@) about the current list of
>blockers and their progress and to see if people need help and others
>might
>be willing and able to do so.

Funny you should mention that. I¹m not the RM obviously, but Daan asked me
if I could have a fresh look at the list of blockers and criticals. If you
want, consider me a temporary junior administrative assistant to the
release manager ;-). What¹s a chore for Daan is a good way for me to learn
more cloudstack!

Here¹s this afternoon's blockers against 4.4 ordered by creation date:

* Bug  CLOUDSTACK-6602
  [UI] createNetworkACL API action param value passed incorrectly
  Assignee:Jessica Wang
  Created: 5/8/14 5:55
  Updated: 6/3/14 13:08
  Leo¹s evaluation: seems like a blocker;
   _probably_ simple fix if you know the javascript?
  Leo¹s suggestion: fix for 4.4
 
 

* Bug  CLOUDSTACK-6779
  [OVS]Expunging VM (deleting vif) deletes all the rules from ovs
   bridge flow table
  Assignee:Murali Reddy
  Created: 5/27/14 12:49
  Updated: 6/6/14 12:43
  Leo¹s evaluation: seems like a blocker, work is in progress
  Leo¹s suggestion: fix for 4.4
 
 

* Bug  CLOUDSTACK-6791
  [Automation] DeleteNetworkCmd fails with NullPointerException
  Assignee:Santhosh Kumar Edukulla
  Created: 5/28/14 1:01
  Updated: 6/8/14 21:28
  Leo¹s evaluation: stalled on info from tester
  Leo¹s suggestion: downgrade to major
 
 

* Test CLOUDSTACK-6861
  [Automation] Test case test_01_snapshot_root_disk during mount
  Assignee:**Unassigned**
  Created: 6/9/14 3:50
  Updated: 6/9/14 3:55
  Leo¹s evaluation: looks like it could be a test environment issue
   instead of a code issue?
  Leo¹s suggestion: downgrade to major
 
 

* Test CLOUDSTACK-6863
  [Automation] test_09_delete_detached_volume failing inconsistently with
   during simulator run
  Assignee:**Unassigned**
  Created: 6/9/14 4:03
  Updated: 6/9/14 4:04
  Leo¹s evaluation: seems like a blocker, looks scary
  Leo¹s suggestion: fix for 4.4, mark as bug, not test
 
 

* Test CLOUDSTACK-6862
  [Automation] Test case
   TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
   faling during BVT
  Assignee:**Unassigned**
  Created: 6/9/14 3:55
  Updated: 6/10/14 21:01
  Leo¹s evaluation: test for unfinished new feature is failing
  Leo¹s suggestion: if not easy to fix, defer feature to 4.5

I was going to give my suggestions to Daan to try and make a call on, but I
guess it¹s better if that can be done by y¹all, right here.

Note a lot of these are very recent coming out of ongoing QA, so I imagine
this list is still to grow before it shrinks.

Next, here¹s a bunch of older critical issues against 4.4:

*   CLOUDSTACK-4593
[VMWARE] [Upgrade]Livestorage Migration & VM Snapshot features are not
fully functional after upgrade
Sateesh Chodapuneedi
9/3/13 6:26
12/6/13 10:27
nasty bug since 4.2 was not fixed in 4.3
defer to 4.5

*   CLOUDSTACK-4247
[VMWARE]Network read/write statistics is zero always
Likitha Shetty
8/12/13 10:00
12/10/13 4:04
bug since 4.1, prio went down/up few  times
defer to 4.5

*   CLOUDSTACK-5356
Xenserver - Failed to create snapshot when secondary store was made
  unavaibale for about 1.5 hour leaving behind snapshot in "
  CreatedOnPrimary" state. The subsequent scheduled snapshot also
  failed
edison su
12/4/13 0:48
12/20/13 0:21
nasty bug on 4.3 was bumped to 4.4 (in xenserver?)
defer to 4.5

*   CLOUDSTACK-5357
Xenserver - Failed to create snapshot due to "unable to destroy
task(com.xe nsource.xenapi.Task@67d312d6) on
host(23af93a0-93ff-40cb-ba11-a11d1b884d37)" when secondary store was
unavaiable for 1 and 1/2 hours and then brought up..
edison su
12/4/13 0:57
12/20/13 0:22
similar to 5356
defer to 4.5

*   CLOUDSTACK-5469
Snapshot creation fails with following exception - "Failed to backup
snapshot: qemu-img: Could not delete snapshot
'89eced14-9121-44a7-bb97-26b567795726': -2 (No such file or directory)"
edison su
12/12/13 0:13
12/20/13 0:23
similar to 5356
defer to 4.5

*   CLOUDSTACK-4492
[object_store_ref] Attaching volume to a vm is failing after upgrade
  if the volume was uploaded before upgrade
edison su
8/26/13 7:04
12/31/13 6:54
bug in upgrade from 3 to 4
downgrade to major

*   CLOUDSTACK-5005
issue with stopping vms parallelly
Kelven Yang
10/30/13 12:14
1/9/14 21:55
vmsync, might be fixed?, needs retesting
test if fi

Re: [DISCUSS] Release 4.4

[Mike Tutkowski]

Thanks, Leo!

On Wednesday, June 11, 2014, Leo Simons  wrote:

> Hey folks,
>
> On 6/11/14, 6:36 PM, "Mike Tutkowski"  > wrote:
> >Yeah, I am concerned about 4.4 getting farther behind schedule, as well,
> >but I agree with David that we should not cancel it.
> >
> >I know it might be a pain, but I wonder if the RM would be willing to
> >"nag"
> >people every few days (just an e-mail to dev@) about the current list of
> >blockers and their progress and to see if people need help and others
> >might
> >be willing and able to do so.
>
> Funny you should mention that. I¹m not the RM obviously, but Daan asked me
> if I could have a fresh look at the list of blockers and criticals. If you
> want, consider me a temporary junior administrative assistant to the
> release manager ;-). What¹s a chore for Daan is a good way for me to learn
> more cloudstack!
>
> Here¹s this afternoon's blockers against 4.4 ordered by creation date:
>
> * Bug  CLOUDSTACK-6602
>   [UI] createNetworkACL API action param value passed incorrectly
>   Assignee:Jessica Wang
>   Created: 5/8/14 5:55
>   Updated: 6/3/14 13:08
>   Leo¹s evaluation: seems like a blocker;
>_probably_ simple fix if you know the javascript?
>   Leo¹s suggestion: fix for 4.4
>
>
>
> * Bug  CLOUDSTACK-6779
>   [OVS]Expunging VM (deleting vif) deletes all the rules from ovs
>bridge flow table
>   Assignee:Murali Reddy
>   Created: 5/27/14 12:49
>   Updated: 6/6/14 12:43
>   Leo¹s evaluation: seems like a blocker, work is in progress
>   Leo¹s suggestion: fix for 4.4
>
>
>
> * Bug  CLOUDSTACK-6791
>   [Automation] DeleteNetworkCmd fails with NullPointerException
>   Assignee:Santhosh Kumar Edukulla
>   Created: 5/28/14 1:01
>   Updated: 6/8/14 21:28
>   Leo¹s evaluation: stalled on info from tester
>   Leo¹s suggestion: downgrade to major
>
>
>
> * Test CLOUDSTACK-6861
>   [Automation] Test case test_01_snapshot_root_disk during mount
>   Assignee:**Unassigned**
>   Created: 6/9/14 3:50
>   Updated: 6/9/14 3:55
>   Leo¹s evaluation: looks like it could be a test environment issue
>instead of a code issue?
>   Leo¹s suggestion: downgrade to major
>
>
>
> * Test CLOUDSTACK-6863
>   [Automation] test_09_delete_detached_volume failing inconsistently with
>during simulator run
>   Assignee:**Unassigned**
>   Created: 6/9/14 4:03
>   Updated: 6/9/14 4:04
>   Leo¹s evaluation: seems like a blocker, looks scary
>   Leo¹s suggestion: fix for 4.4, mark as bug, not test
>
>
>
> * Test CLOUDSTACK-6862
>   [Automation] Test case
>TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
>faling during BVT
>   Assignee:**Unassigned**
>   Created: 6/9/14 3:55
>   Updated: 6/10/14 21:01
>   Leo¹s evaluation: test for unfinished new feature is failing
>   Leo¹s suggestion: if not easy to fix, defer feature to 4.5
>
> I was going to give my suggestions to Daan to try and make a call on, but I
> guess it¹s better if that can be done by y¹all, right here.
>
> Note a lot of these are very recent coming out of ongoing QA, so I imagine
> this list is still to grow before it shrinks.
>
> Next, here¹s a bunch of older critical issues against 4.4:
>
> *   CLOUDSTACK-4593
> [VMWARE] [Upgrade]Livestorage Migration & VM Snapshot features are not
> fully functional after upgrade
> Sateesh Chodapuneedi
> 9/3/13 6:26
> 12/6/13 10:27
> nasty bug since 4.2 was not fixed in 4.3
> defer to 4.5
>
> *   CLOUDSTACK-4247
> [VMWARE]Network read/write statistics is zero always
> Likitha Shetty
> 8/12/13 10:00
> 12/10/13 4:04
> bug since 4.1, prio went down/up few  times
> defer to 4.5
>
> *   CLOUDSTACK-5356
> Xenserver - Failed to create snapshot when secondary store was made
>   unavaibale for about 1.5 hour leaving behind snapshot in "
>   CreatedOnPrimary" state. The subsequent scheduled snapshot also
>   failed
> edison su
> 12/4/13 0:48
> 12/20/13 0:21
> nasty bug on 4.3 was bumped to 4.4 (in xenserver?)
> defer to 4.5
>
> *   CLOUDSTACK-5357
> Xenserver - Failed to create snapshot due to "unable to destroy
> task(com.xe nsource.xenapi.Task@67d312d6) on
> host(23af93a0-93ff-40cb-ba11-a11d1b884d37)" when secondary store was
> unavaiable for 1 and 1/2 hours and then brought up..
> edison su
> 12/4/13 0:57
> 12/20/13 0:22
> similar to 5356
> defer to 4.5
>
> *   CLOUDSTACK-5469
> Snapshot creation fails with following exception - "Failed to backup
> snapshot: qemu-img: Could not delete snapshot
> '89eced14-9121-44a7-bb97-26b567795726': -2 (No such file or directory)"
> edison su
> 12/12/13 0:13
> 12/20/13 0:23
> similar to 5356
> defer to 4.5
>
> *   CLOUDSTACK-4492
> [object_store_ref] Attaching volume to a vm is failing after upgrade
>  

Re: [PROPOSAL] Brocade network plugin to orchestrate Brocade VDX Switches for CloudStack 4.5

[Alena Prokharchyk]

Ritu,


Answering your DB upgrade question. Schema upgrade changes should be put
to 44-45 sql upgrade script, not to create-schema.sql. All previous
releases get upgraded to 4.4 before being upgraded to 45.


-Alena.


On 6/11/14, 11:56 AM, "Ritu Sabharwal"  wrote:

>Thanks Chiradeep! Please see my answers inlined.
>
>Thanks & Regards,
>Ritu S.
>
>-Original Message-
>From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>Sent: Tuesday, June 10, 2014 5:12 PM
>To: dev@cloudstack.apache.org
>Cc: Prakash Kaligotla; Nagendra Jaladanki
>Subject: Re: [PROPOSAL] Brocade network plugin to orchestrate Brocade VDX
>Switches for CloudStack 4.5
>
>Well done.
>Question: How do you figure out the VLAN -to- Brocade switch port
>mapping? By using the mac address of the VM nic?
>
>[RS]: The plugin creates a port profile for each network and at the time
>of VM creation, associates the mac address of the VM nic to the
>respective network's port profile.
>
>Comment: It looks like you are creating a table
>(BrocadeNetworkHostMapping). Could you add details of this table
>(schema). Make sure this table appears in any upgrade scripts from
>previous releases.
>
>[RS]: I will add the schema for the BrocadeNetworkHostMapping table. I
>have added this table to create-schema.sql script. For 4.5, upgrade is
>supported  from what all releases? I will add this to the respective
>scripts.
>
>From: Ritu Sabharwal mailto:rsabh...@brocade.com>>
>Reply-To: "dev@cloudstack.apache.org"
>mailto:dev@cloudstack.apache.org>>
>Date: Tuesday, June 10, 2014 at 11:51 AM
>To: "dev@cloudstack.apache.org"
>mailto:dev@cloudstack.apache.org>>
>Cc: Prakash Kaligotla
>mailto:pkali...@brocade.com>>, Nagendra Jaladanki
>mailto:njala...@brocade.com>>
>Subject: [PROPOSAL] Brocade network plugin to orchestrate Brocade VDX
>Switches for CloudStack 4.5
>
>Hi CS Developers,
>
>I have added the Design document for the Plugin in the wiki.  Here is the
>link : 
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Brocade+Network+Plu
>gin+to+Orchestrate+Brocade+VDX+Switches
>
>Please review it and provide your comments.
>
>Thanks & Regards,
>Ritu S.
>

Re: [DISCUSS] Release 4.4

[Min Chen]

Just looked at automation setup with Rayees, CLOUDSTACK-6825 is not really
an issue of createTemplateFromSnapshot, the real issue is that the
snapshot passed to createTemplate command has its owner removed in DB,
thus causing checkAccess failure. As for why the snapshot is still not
removed when the account is removed on automation setup, that should be a
different issue. As for CLOUDSTACK-6825, we should be able to close it as
not an issue.

Thanks
-min

On 6/11/14 1:37 PM, "Daan Hoogland"  wrote:

>On Wed, Jun 11, 2014 at 10:31 PM, Alena Prokharchyk
> wrote:
>> If we confirm that its a race condition, then the bug should be punted
>>to
>> 4.5
>
>or solve it?
>
>-- 
>Daan

RE: [DISCUSS] Release 4.4

[Animesh Chaturvedi]

Yes we cannot cancel the release. IMHO we started the 4.4-forward branch way 
early. I had created the forward branch for 4.2 and 4.3 only after first RC 
because up until RC we have always seen a lot of code churn and I did not think 
RM can scale with all the cherry-picks given that RM has to focus on the big 
picture.

We need a daily list of blockers/critical I can set up a filter and 
subscription that will forward to dev mailing list automatically.  We should 
also cc folks whom we are expecting to respond as we get lots of email on dev 
and follow up may not get noticed. 
One other thing that I used to do was setup a JIRA query for all the open 
Blocker and critical issues that have not been updated in last 7 day and do a 
BULK EDIT  and ask for status or follow up. 



Thanks
Animesh

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, June 11, 2014 9:37 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Release 4.4
> 
> Yeah, I am concerned about 4.4 getting farther behind schedule, as well, but
> I agree with David that we should not cancel it.
> 
> I know it might be a pain, but I wonder if the RM would be willing to "nag"
> people every few days (just an e-mail to dev@) about the current list of
> blockers and their progress and to see if people need help and others might
> be willing and able to do so.
> 
> 
> On Wed, Jun 11, 2014 at 10:08 AM, David Nalley  wrote:
> 
> > On Wed, Jun 11, 2014 at 11:30 AM, Hugo Trippaers 
> wrote:
> > > Hey all,
> > >
> > > I’m getting somewhat concerned about the 4.4 release. We don’t seems
> > > to
> > be able to get the 4.4 branch in shape for a release candidate and
> > meanwhile master is diverging further and further. We also know that
> > once we hit the RC phase we will probably need a sizable number of
> > iterations to eventually ship the release. Based on past experience,
> > if we keep up like this we will have another release that will
> > actually be released way after the feature freeze for the next release
> > (July 18). Probably leaving us in the same bad spot for the next release.
> > >
> > > I tried to come up with a number of solutions that could rectify the
> > situation and help the release move forward, but i can’t think of any.
> > Save for some options that might be considered extreme ideas. One the
> > the more prominent ideas in my mind at the moment is skipping the 4.4
> > release all together and combine it with the next planned release
> > (whether its 5.0 or 4.5). This would require a community effort to
> > focus on quality in the next month and basically freeze the master for
> > features and have a community wide push for quality to get the next
> release out on schedule.
> > >
> > > But before i go on and shout out even more drastic ideas, what do
> > > you
> > think about the current 4.4 release. How close do you feel that we are
> > to having a releasable product?
> > >
> >
> > So this sounds very familiar to a discussion we had in 4.1 or 4.2
> > timeframes. (I may have even been one of the folks proposing similar
> > ideas, I don't recall)
> >
> > To save you some reading I am -1 on the idea of canceling 4.4. (though
> > really - anyone can propose a release and ask for votes, we have
> > adopted a bit more rigor, but that structure isn't demanded.)
> >
> > Here's the issues I see:
> > 1. We set the expectation that 4.4 is coming; people worked hard to
> > get features in, and our users are waiting on it.
> > 2. We may not be perfect from a schedule perspective, but giving up on
> > a release is a pretty negative thing to do - whats the reaction going
> > to be?
> > 3. Do you think we are in a position to make 4.5 any better? Speaking
> > very frankly, I worry that we are not. I don't think that we have
> > either the tooling or the social desire at present to make significant
> > strides here. We don't dictate the priorities for individual
> > developers. It might be a different story if we were in a corporate
> > shop and could control what folks work on, it might be a different
> > story.
> >
> > --David
> >
> 
> 
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*

[ACS-4.4] Cherry-pick 8a9092c3cd4e3c034f9f4d0a7491875dc080e9dc

[Nitin Mehta]

Daan – Can you please cherry-pick 8a9092c3cd4e3c034f9f4d0a7491875dc080e9dc into 
4.4 ?
This is for CLOUDSTACK-6895

Thanks,
-Nitin

Re: [DISCUSS] Release 4.4

[Alena Prokharchyk]

I any case, even the new bug that Rayees will file, is not a blocker and
shouldn¹t hold cutting the RC.

-alena.

On 6/11/14, 3:27 PM, "Min Chen"  wrote:

>Just looked at automation setup with Rayees, CLOUDSTACK-6825 is not really
>an issue of createTemplateFromSnapshot, the real issue is that the
>snapshot passed to createTemplate command has its owner removed in DB,
>thus causing checkAccess failure. As for why the snapshot is still not
>removed when the account is removed on automation setup, that should be a
>different issue. As for CLOUDSTACK-6825, we should be able to close it as
>not an issue.
>
>Thanks
>-min
>
>On 6/11/14 1:37 PM, "Daan Hoogland"  wrote:
>
>>On Wed, Jun 11, 2014 at 10:31 PM, Alena Prokharchyk
>> wrote:
>>> If we confirm that its a race condition, then the bug should be punted
>>>to
>>> 4.5
>>
>>or solve it?
>>
>>-- 
>>Daan
>

Re: [DISCUSS] Release 4.4

[Pierre-Luc Dion]

Daan created jira public filters so they can be followed for the
release-notes:

Blockers: https://issues.apache.org/jira/issues/?filter=12327112
Criticals: https://issues.apache.org/jira/issues/?filter=12327119


Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
855-OK-CLOUD (855-652-5683) x1101
- - -

*CloudOps*420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_


On Wed, Jun 11, 2014 at 6:57 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> I any case, even the new bug that Rayees will file, is not a blocker and
> shouldn¹t hold cutting the RC.
>
> -alena.
>
> On 6/11/14, 3:27 PM, "Min Chen"  wrote:
>
> >Just looked at automation setup with Rayees, CLOUDSTACK-6825 is not really
> >an issue of createTemplateFromSnapshot, the real issue is that the
> >snapshot passed to createTemplate command has its owner removed in DB,
> >thus causing checkAccess failure. As for why the snapshot is still not
> >removed when the account is removed on automation setup, that should be a
> >different issue. As for CLOUDSTACK-6825, we should be able to close it as
> >not an issue.
> >
> >Thanks
> >-min
> >
> >On 6/11/14 1:37 PM, "Daan Hoogland"  wrote:
> >
> >>On Wed, Jun 11, 2014 at 10:31 PM, Alena Prokharchyk
> >> wrote:
> >>> If we confirm that its a race condition, then the bug should be punted
> >>>to
> >>> 4.5
> >>
> >>or solve it?
> >>
> >>--
> >>Daan
> >
>
>

[ACS44] cherry pick CLOUDSTACK-6602 ([UI] createNetworkACL API action param value passed incorrectly)

[Jessica Wang]

Daan,


Could you please cherry-pick following commit from 4.4-forward to 4.4 branch?



Commit hash:95b7330d5696aa150f1845b76c6021885c919aea



CLOUDSTACK-6602: [UI] createNetworkACL API action param value passed incorrectly





Thank you.



Jessica

Re: [DISCUSS] Release 4.4

[John Burwell]

Hugo,

I would be -1 on the idea of combining 4.4 and 4.5.  If we can’t get the change 
set for 4.4 stabilized then what makes us think we would be successful 
expanding it?  We would be deferring the 4.4 risks to the 4.5 release and 
increasing its overall scope.  For 4.2, we push out the freeze date to 
accommodate the slippage of 4.1.  I propose that we do the same for the 4.5 
freeze date to relieve some schedule pressure and acknowledge the inevitable 
slippage in 4.5 schedule caused by 4.4.

Thanks,
-John

On Jun 11, 2014, at 11:30 AM, Hugo Trippaers  wrote:

> Hey all,
> 
> I’m getting somewhat concerned about the 4.4 release. We don’t seems to be 
> able to get the 4.4 branch in shape for a release candidate and meanwhile 
> master is diverging further and further. We also know that once we hit the RC 
> phase we will probably need a sizable number of iterations to eventually ship 
> the release. Based on past experience, if we keep up like this we will have 
> another release that will actually be released way after the feature freeze 
> for the next release (July 18). Probably leaving us in the same bad spot for 
> the next release.
> 
> I tried to come up with a number of solutions that could rectify the 
> situation and help the release move forward, but i can’t think of any. Save 
> for some options that might be considered extreme ideas. One the the more 
> prominent ideas in my mind at the moment is skipping the 4.4 release all 
> together and combine it with the next planned release (whether its 5.0 or 
> 4.5). This would require a community effort to focus on quality in the next 
> month and basically freeze the master for features and have a community wide 
> push for quality to get the next release out on schedule. 
> 
> But before i go on and shout out even more drastic ideas, what do you think 
> about the current 4.4 release. How close do you feel that we are to having a 
> releasable product? 
> 
> Cheers,
> 
> Hugo

[ACS44] Cherry pick request

[Saksham Srivastava]

Hi Daan,

Request you to cherry-pick the following commits to 4.4:

c5ee5ad5c828d9f0b128e3d7280a30dcf717e045   -   CLOUDSTACK-6864
5bcd017de6f421a6125406120b39fb8602276dc7   -CLOUDSTACK-6654
f14f36170e94c0184ade28a50226b17d25ecf57c-CLOUDSTACK-6812

Thanks,
Saksham

Resize volume API without service offering failing in 4.4

[Rayees Namathponnan]

Hi,

I am trying to resize data volume in KVM and Xen, created new data volume with 
5 GB and trying to resize to 10 GB.

Followed 4.4 API doc , in this service offering id is not a required field; I 
am expecting volume should be resized even if we are not passing service 
offering id, used below API

http://10.xxx.xxx.xxx:8096/?&command=resizeVolume&shrinkok=true 
&size=10&id=f25a958c-48f7-42aa-bb1f-f3749370d064&

resize volume failed with below error, is service offering id mandatory field 
in 4.4 ? is there any change in this area ?


2014-06-11 22:36:01,710 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-51:ctx-eee5edb4 job-5203) Executing AsyncJobVO {id:5203, 
userId: 1, accountId: 1, instanceType: Volume, instanceId: null, cmd: 
org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin, cmdInfo: 
{"id":"f25a958c-48f7-42aa-bb1f-f3749370d064","ctxDetails":"{\"com.cloud.storage.Volume\":710,\"Volume\":\"f25a958c-48f7-42aa-bb1f-f3749370d064\"}","shrinkok":"true","cmdEventType":"VOLUME.RESIZE","ctxUserId":"1","httpmethod":"GET","uuid":"f25a958c-48f7-42aa-bb1f-f3749370d064","ctxAccountId":"1","ctxStartEventId":"15109","size":"10"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 29066118877352, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-06-11 22:36:01,718 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(ApiServer-6:ctx-b68d99d4 ctx-5a82aa93) submit async job-5203, details: 
AsyncJobVO {id:5203, userId: 1, accountId: 1, instanceType: Volume, instanceId: 
null, cmd: 
org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin, cmdInfo: 
{"id":"f25a958c-48f7-42aa-bb1f-f3749370d064","ctxDetails":"{\"com.cloud.storage.Volume\":710,\"Volume\":\"f25a958c-48f7-42aa-bb1f-f3749370d064\"}","shrinkok":"true","cmdEventType":"VOLUME.RESIZE","ctxUserId":"1","httpmethod":"GET","uuid":"f25a958c-48f7-42aa-bb1f-f3749370d064","ctxAccountId":"1","ctxStartEventId":"15109","size":"10"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 29066118877352, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-06-11 22:36:01,721 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(API-Job-Executor-51:ctx-eee5edb4 job-5203 ctx-2e64d0b5) Received unknown 
parameters for command resizeVolume. Unknown parameters : ctxdetails
2014-06-11 22:36:01,756 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-51:ctx-eee5edb4 job-5203) Unexpected exception while 
executing org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin
com.cloud.exception.InvalidParameterValueException: current offering4 cannot be 
resized, need to specify a disk offering
at 
com.cloud.storage.VolumeApiServiceImpl.resizeVolume(VolumeApiServiceImpl.java:724)
at 
com.cloud.storage.VolumeApiServiceImpl.resizeVolume(VolumeApiServiceImpl.java:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)

User below API doc

http://cloudstack.apache.org/docs/api/apidocs-4.3/root_admin/resizeVolume.html


Regards,
Rayees

Re: Review Request 22454: Fixed few coverity reported issues

[Koushik Das]

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



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


Based on the method checkIpRange(), startIp is mandatory but endIp is 
optional. Is all callers of checkPodAttributes enforcing that?



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


Method signature is listByPodIdDcId(long, long). Parameter podId is of type 
Long, so it needs to be passed correctly.


- Koushik Das


On June 11, 2014, 9:18 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22454/
> ---
> 
> (Updated June 11, 2014, 9:18 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Koushik Das, and Santhosh 
> Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> unused assignments, boxing and unboxing of values etc.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 55736f9 
> 
> Diff: https://reviews.apache.org/r/22454/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: Resize volume API without service offering failing in 4.4

[Marcus]

Service offering is required if current offering is not a 'custom' sized
offering. That is, if the volume is a locked into a fixed size because of
the current service offering, the offering needs to be changed to a custom,
or to a service offering of the desired size.


On Wed, Jun 11, 2014 at 11:39 PM, Rayees Namathponnan <
rayees.namathpon...@citrix.com> wrote:

> Hi,
>
> I am trying to resize data volume in KVM and Xen, created new data volume
> with 5 GB and trying to resize to 10 GB.
>
> Followed 4.4 API doc , in this service offering id is not a required
> field; I am expecting volume should be resized even if we are not passing
> service offering id, used below API
>
> http://10.xxx.xxx.xxx:8096/?&command=resizeVolume&shrinkok=true
> &size=10&id=f25a958c-48f7-42aa-bb1f-f3749370d064&<
> http://10.xx.xxx.xxx:8096/?&command=resizeVolume&shrinkok=true%20&size=10&id=f25a958c-48f7-42aa-bb1f-f3749370d064&;
> >
>
> resize volume failed with below error, is service offering id mandatory
> field in 4.4 ? is there any change in this area ?
>
>
> 2014-06-11 22:36:01,710 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-51:ctx-eee5edb4 job-5203) Executing AsyncJobVO {id:5203,
> userId: 1, accountId: 1, instanceType: Volume, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin,
> cmdInfo:
> {"id":"f25a958c-48f7-42aa-bb1f-f3749370d064","ctxDetails":"{\"com.cloud.storage.Volume\":710,\"Volume\":\"f25a958c-48f7-42aa-bb1f-f3749370d064\"}","shrinkok":"true","cmdEventType":"VOLUME.RESIZE","ctxUserId":"1","httpmethod":"GET","uuid":"f25a958c-48f7-42aa-bb1f-f3749370d064","ctxAccountId":"1","ctxStartEventId":"15109","size":"10"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> result: null, initMsid: 29066118877352, completeMsid: null, lastUpdated:
> null, lastPolled: null, created: null}
> 2014-06-11 22:36:01,718 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (ApiServer-6:ctx-b68d99d4 ctx-5a82aa93) submit async job-5203, details:
> AsyncJobVO {id:5203, userId: 1, accountId: 1, instanceType: Volume,
> instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin,
> cmdInfo:
> {"id":"f25a958c-48f7-42aa-bb1f-f3749370d064","ctxDetails":"{\"com.cloud.storage.Volume\":710,\"Volume\":\"f25a958c-48f7-42aa-bb1f-f3749370d064\"}","shrinkok":"true","cmdEventType":"VOLUME.RESIZE","ctxUserId":"1","httpmethod":"GET","uuid":"f25a958c-48f7-42aa-bb1f-f3749370d064","ctxAccountId":"1","ctxStartEventId":"15109","size":"10"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> result: null, initMsid: 29066118877352, completeMsid: null, lastUpdated:
> null, lastPolled: null, created: null}
> 2014-06-11 22:36:01,721 WARN  [c.c.a.d.ParamGenericValidationWorker]
> (API-Job-Executor-51:ctx-eee5edb4 job-5203 ctx-2e64d0b5) Received unknown
> parameters for command resizeVolume. Unknown parameters : ctxdetails
> 2014-06-11 22:36:01,756 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (API-Job-Executor-51:ctx-eee5edb4 job-5203) Unexpected exception while
> executing
> org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin
> com.cloud.exception.InvalidParameterValueException: current offering4
> cannot be resized, need to specify a disk offering
> at
> com.cloud.storage.VolumeApiServiceImpl.resizeVolume(VolumeApiServiceImpl.java:724)
> at
> com.cloud.storage.VolumeApiServiceImpl.resizeVolume(VolumeApiServiceImpl.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
>
> User below API doc
>
>
> http://cloudstack.apache.org/docs/api/apidocs-4.3/root_admin/resizeVolume.html
>
>
> Regards,
> Rayees
>

Re: Review Request 21375: CLOUDSTACK-6654: Configkey parameters are not validated

[ASF Subversion and Git Services]

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


Commit 41030e4e3e39de694837d1a6dc2f4905da228d98 in cloudstack's branch 
refs/heads/master from Saksham Srivastava
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=41030e4 ]

CLOUDSTACK-6654: Configkey parameters are not validated


- ASF Subversion and Git Services


On May 13, 2014, 1:01 p.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21375/
> ---
> 
> (Updated May 13, 2014, 1:01 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Devdeep Singh.
> 
> 
> Bugs: CLOUDSTACK-6654
> https://issues.apache.org/jira/browse/CLOUDSTACK-6654
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> ConfigKey variables values are not validated. So anything  like -5.6 or “abc” 
>  as the value of cpu/memory/storage overprovision factors can be set. 
> Similarly for all of the variables in ConfigKey.
> We have a verification mechanism but it is never executed. The code is 
> unreachable in the preset 4.4
> 
> In ConfigurationManagerImpl.java: validateConfigurationValue()
>  
> Config c = Config.getConfig(name);
>  if (c == null) {
> s_logger.warn("Did not find configuration " + name + " in Config.java. 
> Perhaps moved to ConfigDepot?");
> -return null;
> }
> Since for the ConfigKey parameters ‘c’ is always null, we return null and do 
> not further validate.
> 
> Fix is to make sure type is validated by using  _configDepot.get(name)
> 
> Note: Configkey does not have a range flag. Each range param has to be 
> considered as per case basis.
> Added comments for the same.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 231b5e1 
> 
> Diff: https://reviews.apache.org/r/21375/diff/
> 
> 
> Testing
> ---
> 
> Tested both Configkey variables as well as old Config parameters.
> ConfigKey values are now validated before setting them in db.
> 
> The following status message appears when cpu.overprovisioning.factor is set 
> to incorrect value.
> There was an error trying to parse the float value for: 
> cpu.overprovisioning.factor
> 
> Build passes.
> Findbug is clean.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

Sounds good - let me give some thought as to how we should break up the
work.

My GSoC student from Tunisia will be helping us, as well.


On Wed, Jun 11, 2014 at 8:34 AM, Punith S  wrote:

> yes it sounds good, thanks for the proposal mike,
>
> yeah right now i have implemented prototype of my proposal, since its not
> generic we shall implement your proposal for 4.5.
> on the other hand, for 4.5 i'm supporting nfs protocol and resize feature
> for managed storage in xenserver, now trying to implement snapshot and
> support root disk for vm's.
> and yes if we can club together, i can start working on this proposal for
> data disk and get the prototype ready.
> what do you think ?
>
> thanks.
>
>
> On Wed, Jun 11, 2014 at 3:53 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> I'll send out a [PROPOSAL] e-mail so others who may not be following this
>> e-mail thread have a better chance to comment on the feature.
>>
>>
>> On Tue, Jun 10, 2014 at 2:58 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Here is that design document I was referring to, Punith:
>>>
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111
>>>
>>> I've been working with a student in Tunisia who is participating in
>>> Google Summer of Code (GSoC) (I'm his mentor).
>>>
>>> He'll be working on part of this as will I. (He is also working on
>>> another related task not listed here.)
>>>
>>> Feel free to join us, if you have time available, as we can divide out
>>> coding and testing among the three of us.
>>>
>>> Talk to you later!
>>> Mike
>>>
>>>
>>> On Tue, Jun 10, 2014 at 10:18 AM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
 I plan to draw up a design document surrounding generic key/value pairs
 today.

 Perhaps you can take a look at it when you have time, Punith?


 On Tue, Jun 10, 2014 at 10:06 AM, Mike Tutkowski <
 mike.tutkow...@solidfire.com> wrote:

> Hi Punith,
>
> Yeah, I hear you about the number of permutations involved.
>
> Traditionally Compute and Disk Offerings have been immutable. It makes
> it easier from an accounting point of view for chargeback and billing.
>
> You should definitely feel free to extend the CloudStack API. I think
> NetApp did this for one of their storage features in the recent past. This
> way vendor-specific capabilities can be more easily offered without making
> it look like all vendors support those particular features.
>
> I do not yet have any code in master related to generic keys/values.
> I'm still designing this.
>
> How does your schedule look for the 4.5 release? Do you think you
> might have available cycles to help out with this generic key/value
> implementation?
>
> Talk to you later!
> Mike
>
>
> On Tue, Jun 10, 2014 at 7:09 AM, Punith S 
> wrote:
>
>> hi mike,
>>
>> thanks for the reply, i like your approach which is a very generic
>> way and also we only need to do a few changes to the current cloudstack,
>>
>> but on the other hand we are tying every property of the vendor to a
>> disk offering through key/value pairs, since we offer lot of properties
>> like i mentioned, this can create a lot of permutation combinations of 
>> disk
>> offerings, for say if i need to turn deduplication On for a specific 
>> volume
>> , should i have to create a new disk offering having current properties
>> with deduplication On?
>>
>> is this approach already implemented in the current master ?
>>
>> and also like you mentioned about exposing a new api, is it okay if i
>> expose our own api in my util by extending the PlugableService like in
>> network plugins ?
>>
>> thanks.
>>
>>
>> On Tue, Jun 10, 2014 at 1:17 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Allow me to follow this up with more detail (with regards to what
>>> Chris and I talked about):
>>>
>>> As you are aware, today the way you associate a Compute Offering
>>> (CO) or a Disk Offering (DO) with a Primary Storage (PS) is via storage
>>> tagging.
>>>
>>> This has some benefits and drawbacks.
>>>
>>> One benefit is being able to have some level of vendor independence
>>> from the point of view of the CO or DO. For example, if the storage tag 
>>> of
>>> a DO is "Fast", then this can be satisfied by PS that describes itself 
>>> as
>>> "Fast", regardless of vendor.
>>>
>>> A major drawback with the storage-tagging approach, however, is that
>>> you are not easily able to leverage vendor-specific features, which is
>>> often why you bought storage from the vendor in question to begin with.
>>>
>>> Ideally we do not want to add each vendor's features into the system
>>> as properties that can be seen by the 

Re: Review Request 22454: Fixed few coverity reported issues

[Rajani Karuturi]

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



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


startIp is never null. There is a check in the caller to see if startIp is 
null. 
Even if this check exists here, it is of no use as it will fail with NPE in 
checkIpRange on the first line itself if the startip is null.



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


Long.valueOf() gives you another Long. its basically converting Long to 
Long. 
We should do podId.longValue() to pass long.
auto unboxing will take care it.


- Rajani Karuturi


On June 11, 2014, 9:18 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22454/
> ---
> 
> (Updated June 11, 2014, 9:18 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Koushik Das, and Santhosh 
> Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> unused assignments, boxing and unboxing of values etc.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 55736f9 
> 
> Diff: https://reviews.apache.org/r/22454/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: [DISCUSS] continuous integration for plugins requiring proprietary / hardware infra

[ilya musayev]

Chiradeep,

Perhaps we need to provide a little more background information.

We are in process of drafting a request to ASF for lab/dev for Apache 
CloudStack Continuous Integration environment. In order for us to make 
sure that future releases of Apache CloudStack wont break functionality 
with existing plugins vendors like Nuage, Brocade, NetApp, USC, VmWare 
NVP and other provide. It would be ideal if there is sample hardware - 
be it physical, virtual or some other method that can confirm existing 
functionality wont break with new releases.


With that in mind, this is question mostly to developers who are 
representing vendors, is there anything on your end you can help 
facilitate? If there are other alternatives you can propose, we would 
like to hear them.


Thank you for your participation and making Apache CloudStack a better 
cloud platform,


Regards
ilya

On 6/10/14, 5:32 PM, Chiradeep Vittal wrote:

Hi,

Since the Nuage VSP and Brocade plugins have been proposed recently, I was
wondering what is the mechanism to ensure that CI will test their plugins?

Thanks
‹
Chiradeep

Re: Review Request 22258: Test cases for listAccounts, listFirewallRules and listVolumes.

[Meghna Kale]

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

(Updated June 12, 2014, 6:51 a.m.)


Review request for cloudstack, Min Chen and Prachi Damle.


Repository: cloudstack-git


Description
---

Test cases for listAccounts, listFirewallRules and listVolumes.


Diffs
-

  test/integration/smoke/test_accounts_iam.py PRE-CREATION 
  test/integration/smoke/test_fwRule_iam.py PRE-CREATION 
  test/integration/smoke/test_volumes_iam.py PRE-CREATION 

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


Testing
---


Thanks,

Meghna Kale

Re: Review Request 22258: [IAM functionality] Test cases for listAccounts, listFirewallRules and listVolumes

[Meghna Kale]

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

(Updated June 12, 2014, 6:52 a.m.)


Review request for cloudstack, Min Chen and Prachi Damle.


Changes
---

[IAM functionality] Test cases for listAccounts, listFirewallRules and 
listVolumes


Summary (updated)
-

[IAM functionality] Test cases for listAccounts, listFirewallRules and 
listVolumes 


Repository: cloudstack-git


Description
---

Test cases for listAccounts, listFirewallRules and listVolumes.


Diffs
-

  test/integration/smoke/test_accounts_iam.py PRE-CREATION 
  test/integration/smoke/test_fwRule_iam.py PRE-CREATION 
  test/integration/smoke/test_volumes_iam.py PRE-CREATION 

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


Testing
---


Thanks,

Meghna Kale

Re: Review Request 22453: [windows]Adding prot fields to the database creation wizard

[Damodar Reddy Talakanti]

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

(Updated June 12, 2014, 6:58 a.m.)


Review request for cloudstack, Abhinandan Prateek and Koushik Das.


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

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


Repository: cloudstack-git


Description
---

We also need to collect port information from the admin while collecting 
database information from the admin as part of windows installer.Changes are 
done to fix this.


Diffs
-

  scripts/installer/windows/Setup_Databases.wxs 0254c61 
  scripts/installer/windows/acs.wxs 83bac54 
  scripts/installer/windows/en-us.wxl b5a98ec 

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


Testing
---

Tested it on windows 2012 R2 Server as well as Centos server


Thanks,

Damodar Reddy Talakanti