Re: Couple JavaScript Questions

[Punith S]

the first block seems to be fine , but in the second block , (args > 0)
seems to be incorrect because args is an object right ? which inturn
contains the volume properties.
which can be accessed as args.volume.maxiops i guess.

thanks


On Thu, Mar 6, 2014 at 12:52 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> I'm not nearly as well versed in JavaScript as I am in Java. I was
> wondering if someone could answer these questions for me:
>
> If "memory" is stored in the DB as null, I assume args will be equal to
> undefined below. Is that correct?
>
> memory: {
> label: 'label.memory.mb',
> converter: function(args) {
> if (args == undefined)
> return '';
> else
> return cloudStack.converters.convertBytes(args * 1024 * 1024);
> }
> },
>
> If "maxiops" is stored in the DB as null, will we simply return "N/A" or is
> there a problem comparing what is essentially an undefined variable with 0?
>
> maxiops: {
> label: 'label.disk.iops.max',
> converter: function(args) {
> if (args > 0)
> return args;
> else
> return "N/A";
> }
> },
>
> 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
> *(tm)*
>



-- 
regards,

punith s
cloudbyte.com

Re: [DISCUSS] Checking in code that will break others' environments

[Koushik Das]

Before doing a git pull, I generally check the sql schema changes and run the 
delta manually on my existing setup. In most of the cases that works for me 
without having to redeploy the db.

-Koushik

On 06-Mar-2014, at 11:43 AM, Mike Tutkowski  
wrote:

> Yeah, I definitely just meant a "heads up" during development if you are
> going to change something that will break other people's environments who
> update. If these people know in advance, they may choose to postpone an
> update until they are at a better point.
> 
> 
> On Wed, Mar 5, 2014 at 11:01 PM, Rajani Karuturi > wrote:
> 
>> Across versions db migration is taken care. I think this is bound to occur
>> while working on a release, if multiple people work on the same branch with
>> different work-in-progress features.
>> 
>> Could we move to flyway or liquibase which can take care of db versioning
>> and migration?
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 06-Mar-2014, at 2:08 am, Mike Tutkowski 
>> wrote:
>> 
>>> Yeah, in this case, I'm not referring to erroneous code that breaks a
>>> person's environment (since hopefully the person wouldn't have knowingly
>>> checked in such code), but rather, say, DB-type changes that improve the
>>> system, but break current setups.
>>> 
>>> Just a heads-up e-mail with some easily identifiable tag.
>>> 
>>> Can anyone think of a good tag for this? It's not always DB related, so
>> we
>>> might want the tag to be more general.
>>> 
>>> 
>>> On Wed, Mar 5, 2014 at 1:28 PM, Ian Duffy  wrote:
>>> 
 +1 to this.
 
 Having the build suddenly break due to a git pull has been very
>> annoying!
 I usually end up searching through the commit log and doing a resets
 until I find a commit where it works. Then waiting awhile until I do a
 git pull again and hoping the code was fixed.
 
 On 5 March 2014 20:19, Mike Tutkowski 
 wrote:
> Hi,
> 
> I encountered a bit of a problem this morning and thought I would bring
 it
> up for discussion.
> 
> If we already have a policy around this, please let me know.
> 
> So, I fetched the latest and rebased my local 4.4 development branch on
 top
> of master. This all went just fine.
> 
> When I rebuilt and re-started the CS Management Server, I soon
>> realized I
> could no longer log in from the GUI.
> 
> As it turns out, the DB schema had been updated and so my database was
 out
> of date. The code was querying for fields that didn't exist in my DB.
> 
> As far as I know, the easiest way to get around this is to destroy my
> current cloud, run the script to re-build my database, then re-create
>> my
> cloud, which is somewhat time consuming.
> 
> Do we have a process in place currently in which we ask those who make
 such
> changes to send out a notification e-mail to dev@ to give people a
 heads up
> that updating will lead to such issues? On previous projects, we would
 send
> out an e-mail and then people could be aware to only update if they
>> were
> prepared for such re-work.
> 
> To be clear here, I'm not meaning to pick on anyone in
>> particular...this
> has happened several times over the course of my CloudStack development
 and
> I expect that I, too, have checked in such code (without sending out a
> relevant e-mail) that lead people to have to perform such a complete
> re-build action un-expectedly.
> 
> What do people think about this? Maybe we should just add an e-mail tag
 or
> something and point people to the relevant commit?
> 
> 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
> *(tm)*
 
>>> 
>>> 
>>> 
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkow...@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the
>>> cloud
>>> *(tm)*
>> 
>> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*

Couple JavaScript Questions

[Mike Tutkowski]

Hi,

I'm not nearly as well versed in JavaScript as I am in Java. I was
wondering if someone could answer these questions for me:

If "memory" is stored in the DB as null, I assume args will be equal to
undefined below. Is that correct?

memory: {
label: 'label.memory.mb',
converter: function(args) {
if (args == undefined)
return '';
else
return cloudStack.converters.convertBytes(args * 1024 * 1024);
}
},

If "maxiops" is stored in the DB as null, will we simply return "N/A" or is
there a problem comparing what is essentially an undefined variable with 0?

maxiops: {
label: 'label.disk.iops.max',
converter: function(args) {
if (args > 0)
return args;
else
return "N/A";
}
},

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
*(tm)*

Re: The global settings beast...

[Mike Tutkowski]

Ah, interesting - thanks!


On Thu, Mar 6, 2014 at 12:08 AM, Harikrishna Patnala <
harikrishna.patn...@citrix.com> wrote:

> Hi Mike,
>
> As Alex quoted we need to make all the parameters to use ConfigKey.
> Now if you want to check which parameters require reboot or not, there is
> a column 'is_dynamic' in Configuration table.
> If the value is 1 then no need to restart MS for those parameters.
>
> -Harikrishna
>
> On 06-Mar-2014, at 9:16 am, Mike Tutkowski 
> wrote:
>
> > Hi Alex,
> >
> > I typically update system.vm.use.local.storage to true before I create my
> > first zone in a fresh environment. The GUI tells me I need to reboot the
> CS
> > Management Server, but I've noticed I don't really have to.
> >
> > Is there a list somewhere that specifies which parameters really require
> a
> > reboot of the CS MS and which ones don't? Also, I wonder if the GUI just
> > says this for all Global Settings that are changed because it has no
> > knowledge of which ones really require a reboot. Does that sound correct?
> >
> > Thanks
> >
> >
> > On Wed, Mar 5, 2014 at 6:18 PM, Alex Huang 
> wrote:
> >
> >> I added something to address this last year.
> >>
> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration
> >>
> >> It addresses several problems.
> >>
> >> - Parameter values are not stored in member variables so it's possible
> for
> >> changed values to take effect without reboot.
> >> - Breaks up the enum so that plugins can have their own config
> parameters
> >> without changing the Config.java in CloudStack.
> >> - If the default value for a parameter changes, this change
> automatically
> >> updates a default value field and a timestamp so the admin can evaluate
> >> whether they want to change their current value for the parameter.
> >> - Deleted parameters from the code are marked with an update time that's
> >> null so the admin knows the parameter have been removed after an
> upgrade.
> >>
> >> There are several todos left.  They are documented in
> >> ConfigDepotImpl.java.  For the important ones, I filed bugs.  If you
> have
> >> some time, please help work on them.
> >>
> >> - CLOUDSTACK-6206: No UI to reflect these changes.
> >> - CLOUDSTACk-6207: Remove Config.java and move all enums to the new
> >> ConfigKey parameter.
> >> - CLOUDSTACK-6208: Create a per management server properties file that
> >> contains parameters that pertains to each management server node,
> instead
> >> of globally.
> >>
> >> --Alex
> >>
> >>> -Original Message-
> >>> From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
> >>> Sent: Wednesday, March 5, 2014 3:22 AM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: RE: The global settings beast...
> >>>
> >>> The need to restart is, the Managers  have configured with the values
> in
> >>> Global Settings and running.
> >>>
> >>> -Original Message-
> >>> From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
> >>> Sent: Wednesday, March 5, 2014 3:13 PM
> >>> To: dev@cloudstack.apache.org
> >>> Subject: Re: The global settings beast...
> >>>
> >>> The need to restart the management server for any global configuration
> >>> change is a problem.
> >>> I spent at least a few hours trying to debug an issue only to realise
> >> that its not
> >>> an issue but, I have to restart the management server.
> >>>
> >>>
> >>> ~Rajani
> >>>
> >>>
> >>>
> >>> On 05-Mar-2014, at 3:01 pm, Donal Lafferty 
> >>> wrote:
> >>>
>  In fairness, the biggest problem is having to reboot.
> 
>  WRT to b), there is a search option that avoids the need to scroll.
> 
> > -Original Message-
> > From: John Kinsella [mailto:j...@stratosec.co]
> > Sent: 05 March 2014 08:22
> > To: 
> > Subject: The global settings beast...
> >
> > One thing that's been gnawing on me - we keep shoving more and more
> > stuff into the global settings shortcut instead of creating a proper
> >> settings
> >>> UI.
> > Then some new user comes along all shiny-eyed at the awesomeness of
> > ACS, but wonders why something isn't working, only to be told that
> > combination of a) it's in the docs and b) you have to scroll down
> > through 30 items in global settings, then change something, then
> > restart mgmt, then re- login...then it'll work.
> >
> > I know the UI is supposed to be a proof of concept, but I'm thinking
> > we need to shed that label and empty out some closeted skeletons such
> >>> as this.
> >
> > Am I the only one this bothers, or should we maybe set it as a goal
> > for 4.5 (maybe this is on a feature list and I've missed it...)?
> >
> > John
> >>
> >>
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, Soli

Re: The global settings beast...

[Harikrishna Patnala]

Hi Mike,

As Alex quoted we need to make all the parameters to use ConfigKey.
Now if you want to check which parameters require reboot or not, there is a 
column 'is_dynamic' in Configuration table. 
If the value is 1 then no need to restart MS for those parameters.

-Harikrishna
 
On 06-Mar-2014, at 9:16 am, Mike Tutkowski  wrote:

> Hi Alex,
> 
> I typically update system.vm.use.local.storage to true before I create my
> first zone in a fresh environment. The GUI tells me I need to reboot the CS
> Management Server, but I've noticed I don't really have to.
> 
> Is there a list somewhere that specifies which parameters really require a
> reboot of the CS MS and which ones don't? Also, I wonder if the GUI just
> says this for all Global Settings that are changed because it has no
> knowledge of which ones really require a reboot. Does that sound correct?
> 
> Thanks
> 
> 
> On Wed, Mar 5, 2014 at 6:18 PM, Alex Huang  wrote:
> 
>> I added something to address this last year.
>> 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration
>> 
>> It addresses several problems.
>> 
>> - Parameter values are not stored in member variables so it's possible for
>> changed values to take effect without reboot.
>> - Breaks up the enum so that plugins can have their own config parameters
>> without changing the Config.java in CloudStack.
>> - If the default value for a parameter changes, this change automatically
>> updates a default value field and a timestamp so the admin can evaluate
>> whether they want to change their current value for the parameter.
>> - Deleted parameters from the code are marked with an update time that's
>> null so the admin knows the parameter have been removed after an upgrade.
>> 
>> There are several todos left.  They are documented in
>> ConfigDepotImpl.java.  For the important ones, I filed bugs.  If you have
>> some time, please help work on them.
>> 
>> - CLOUDSTACK-6206: No UI to reflect these changes.
>> - CLOUDSTACk-6207: Remove Config.java and move all enums to the new
>> ConfigKey parameter.
>> - CLOUDSTACK-6208: Create a per management server properties file that
>> contains parameters that pertains to each management server node, instead
>> of globally.
>> 
>> --Alex
>> 
>>> -Original Message-
>>> From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
>>> Sent: Wednesday, March 5, 2014 3:22 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: The global settings beast...
>>> 
>>> The need to restart is, the Managers  have configured with the values in
>>> Global Settings and running.
>>> 
>>> -Original Message-
>>> From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
>>> Sent: Wednesday, March 5, 2014 3:13 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: The global settings beast...
>>> 
>>> The need to restart the management server for any global configuration
>>> change is a problem.
>>> I spent at least a few hours trying to debug an issue only to realise
>> that its not
>>> an issue but, I have to restart the management server.
>>> 
>>> 
>>> ~Rajani
>>> 
>>> 
>>> 
>>> On 05-Mar-2014, at 3:01 pm, Donal Lafferty 
>>> wrote:
>>> 
 In fairness, the biggest problem is having to reboot.
 
 WRT to b), there is a search option that avoids the need to scroll.
 
> -Original Message-
> From: John Kinsella [mailto:j...@stratosec.co]
> Sent: 05 March 2014 08:22
> To: 
> Subject: The global settings beast...
> 
> One thing that's been gnawing on me - we keep shoving more and more
> stuff into the global settings shortcut instead of creating a proper
>> settings
>>> UI.
> Then some new user comes along all shiny-eyed at the awesomeness of
> ACS, but wonders why something isn't working, only to be told that
> combination of a) it's in the docs and b) you have to scroll down
> through 30 items in global settings, then change something, then
> restart mgmt, then re- login...then it'll work.
> 
> I know the UI is supposed to be a proof of concept, but I'm thinking
> we need to shed that label and empty out some closeted skeletons such
>>> as this.
> 
> Am I the only one this bothers, or should we maybe set it as a goal
> for 4.5 (maybe this is on a feature list and I've missed it...)?
> 
> John
>> 
>> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*

Re: The global settings beast...

[Mike Tutkowski]

Thanks for the info, Alex.


On Wed, Mar 5, 2014 at 11:14 PM, Alex Huang  wrote:

> I don't think we will be able to get that until all configs are converted
> to using the ConfigKey.  Today, a lot of components just stores the
> parameter value as a member variable so changes can't be reflected without
> a reboot.  Switching to ConfigKey will force all of those to change.
>
> --Alex
>
> > -Original Message-
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Wednesday, March 5, 2014 7:46 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: The global settings beast...
> >
> > Hi Alex,
> >
> > I typically update system.vm.use.local.storage to true before I create
> my first
> > zone in a fresh environment. The GUI tells me I need to reboot the CS
> > Management Server, but I've noticed I don't really have to.
> >
> > Is there a list somewhere that specifies which parameters really require
> a
> > reboot of the CS MS and which ones don't? Also, I wonder if the GUI just
> > says this for all Global Settings that are changed because it has no
> knowledge
> > of which ones really require a reboot. Does that sound correct?
> >
> > Thanks
> >
> >
> > On Wed, Mar 5, 2014 at 6:18 PM, Alex Huang 
> > wrote:
> >
> > > I added something to address this last year.
> > >
> > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration
> > >
> > > It addresses several problems.
> > >
> > > - Parameter values are not stored in member variables so it's possible
> > > for changed values to take effect without reboot.
> > > - Breaks up the enum so that plugins can have their own config
> > > parameters without changing the Config.java in CloudStack.
> > > - If the default value for a parameter changes, this change
> > > automatically updates a default value field and a timestamp so the
> > > admin can evaluate whether they want to change their current value for
> > the parameter.
> > > - Deleted parameters from the code are marked with an update time
> > > that's null so the admin knows the parameter have been removed after an
> > upgrade.
> > >
> > > There are several todos left.  They are documented in
> > > ConfigDepotImpl.java.  For the important ones, I filed bugs.  If you
> > > have some time, please help work on them.
> > >
> > > - CLOUDSTACK-6206: No UI to reflect these changes.
> > > - CLOUDSTACk-6207: Remove Config.java and move all enums to the new
> > > ConfigKey parameter.
> > > - CLOUDSTACK-6208: Create a per management server properties file that
> > > contains parameters that pertains to each management server node,
> > > instead of globally.
> > >
> > > --Alex
> > >
> > > > -Original Message-
> > > > From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
> > > > Sent: Wednesday, March 5, 2014 3:22 AM
> > > > To: dev@cloudstack.apache.org
> > > > Subject: RE: The global settings beast...
> > > >
> > > > The need to restart is, the Managers  have configured with the
> > > > values in Global Settings and running.
> > > >
> > > > -Original Message-
> > > > From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
> > > > Sent: Wednesday, March 5, 2014 3:13 PM
> > > > To: dev@cloudstack.apache.org
> > > > Subject: Re: The global settings beast...
> > > >
> > > > The need to restart the management server for any global
> > > > configuration change is a problem.
> > > > I spent at least a few hours trying to debug an issue only to
> > > > realise
> > > that its not
> > > > an issue but, I have to restart the management server.
> > > >
> > > >
> > > > ~Rajani
> > > >
> > > >
> > > >
> > > > On 05-Mar-2014, at 3:01 pm, Donal Lafferty
> > > > 
> > > > wrote:
> > > >
> > > > > In fairness, the biggest problem is having to reboot.
> > > > >
> > > > > WRT to b), there is a search option that avoids the need to scroll.
> > > > >
> > > > >> -Original Message-
> > > > >> From: John Kinsella [mailto:j...@stratosec.co]
> > > > >> Sent: 05 March 2014 08:22
> > > > >> To: 
> > > > >> Subject: The global settings beast...
> > > > >>
> > > > >> One thing that's been gnawing on me - we keep shoving more and
> > > > >> more stuff into the global settings shortcut instead of creating
> > > > >> a proper
> > > settings
> > > > UI.
> > > > >> Then some new user comes along all shiny-eyed at the awesomeness
> > > > >> of ACS, but wonders why something isn't working, only to be told
> > > > >> that combination of a) it's in the docs and b) you have to scroll
> > > > >> down through 30 items in global settings, then change something,
> > > > >> then restart mgmt, then re- login...then it'll work.
> > > > >>
> > > > >> I know the UI is supposed to be a proof of concept, but I'm
> > > > >> thinking we need to shed that label and empty out some closeted
> > > > >> skeletons such
> > > > as this.
> > > > >>
> > > > >> Am I the only one this bothers, or should we maybe set it as a
> > > > >> goal for 4.5 (maybe this is on a feature list and I've missed
> it...)?
> > > > >>
> > 

Re: New EC2 interface

[Prasanna Santhanam]

On Wed, Mar 05, 2014 at 03:34:06PM +0100, sebgoa wrote:
> Hi,
> 
> I just wrote a short blog about a new EC2 interface that Ian Duffy
> and Darren Brogan have been working on for course work:
> 
> http://buildacloud.org/blog/321-new-ec2-interface-to-cloudstack.html
> 
> Once they get their grade for this project we should all be able to
> send pull requests and if we want merge it in CloudStack code (to be
> discussed)
> 
> I want to bring this to dev@ as this might be a way to offer an
> improved EC2 interface and deprecate the current awsapi.
> 
> Removing awsapi might simplify packaging for 4.5
> 

+1 

Good stuff guys! What was sorely missing from the previous awsapi
interface was tests for compatibility. When I find some time, I'd be
interested to look into putting in a compatibility indicator for this.

-- 
Prasanna.,


Powered by BigRock.com

Re: Change Volume IOPS on fly without detaching the disk feature.

[Mike Tutkowski]

Hi,

Hypervisor rate limiting is only supported on KVM at the time being. You
are correct that it can get confusing if people use both hypervisor rate
limiting and then QoS of some flavor on the storage side, so CloudStack
only supports a user doing one or the other with a given volume.

As far as I know, we are still targeting March 14th for 4.4 Feature Freeze.
There has been some talk about extending this date a couple weeks, but - at
the moment - the 4.4 release manager (among others) are pushing to keep the
March 14th deadline.

I briefly investigated adding support for dynamically changing IOPS, but
that work was preempted by other CloudStack work I'm doing that was deemed
of higher priority. I do not think adding support to dynamically change
IOPS will be doable for CloudStack 4.4, but we should re-visit it in 4.5.
I'd be happy to work with you on that.

Talk to you later


On Wed, Mar 5, 2014 at 11:28 PM, Punith S  wrote:

> yea mike i agree with you , i was talking with respect to changing iops of
> the datadisk on storage side, not with respect to hipervisor level settings,
>
> and like marcus suggested i tried to tie changing the disk iops with
> already available resize command but it has some limitations like i said
> before , that we need to detach the disk in order to do that which implies
> downtime for the user, but for a user who needs only to change the
> performance metric of the datadisk , he can change the iops by directly
> sending calls through the storage driver to the backend storage which
> supports change in Qos metrics like our cloudbyte elastistor and others
> without disturbing the hipervisor settings on fly with the available iops
> of the primary storage pool.
>
> and my doubt is that , how does hypervisor level throttling help in
> controlling the iops of the disk ?  and if so you might be wasting the
> available iops of the volume in backend!
> and thanks for the support mike , i have done some poc on this , we shall
> put this to 4.4 or 4.5,
> and i needed to push our cloudbyte elastistor storage plugin to 4.4 , so
> we should be pushing to master first before 28th of this month right ?
>
> thanks,
> punith
>
>
> On Thu, Mar 6, 2014 at 12:32 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Exactly...and that shouldn't be too much of a problem.
>>
>> The "trick" will come into play when we have to take into consideration
>> "generic" storage properties and that Min and Max IOPS should really be
>> part of this group.
>>
>>
>> On Wed, Mar 5, 2014 at 11:59 AM, Marcus  wrote:
>>
>> > Yes, that's what I mean. When the offering is changed, we need to have
>> > a hook in there that calls the applicable storage driver for the
>> > volume. Then the drivers can be free to implement or not implement.
>> >
>> > On Wed, Mar 5, 2014 at 11:36 AM, Mike Tutkowski
>> >  wrote:
>> > > Hi Marcus,
>> > >
>> > > In 4.4 I'm adding the ability to allow admins to specify Min and Max
>> IOPS
>> > > for Compute Offerings, as well (support only for XenServer in 4.4).
>> > >
>> > > I agree changing of IOPS should be doable through changing a Disk or
>> > Compute
>> > > Offering, but this doesn't work right now as the storage framework
>> > doesn't
>> > > tell the plug-in in question about the change.
>> > >
>> > > This is part of what Punith should investigate as we move forward with
>> > this
>> > > in 4.5.
>> > >
>> > > Talk to you later,
>> > > Mike
>> > >
>> > >
>> > > On Wed, Mar 5, 2014 at 11:12 AM, Marcus  wrote:
>> > >>
>> > >> Wouldn't this be implemented as just changing disk offerings? The
>> > >> resizeVolume API call already allows you to switch disk offerings, we
>> > >> just need to add a hook in there to optionally call the storage
>> driver
>> > >> (If volume is deployed to a primary storage) to make an update to the
>> > >> iops properties on the backend storage. Come to think of it,
>> depending
>> > >> on how storage drivers are implementing the iops/limits feature,
>> > >> resizeVolume might be breaking this, or simply requiring a reboot to
>> > >> apply. That is, if the storage driver is setting the iops just once
>> > >> upon volume creation, it's probably breaking when a user moves a disk
>> > >> between offerings that may have alternate iops limits (this is
>> > >> probably not the case for hypervisor throttling, as that's applied
>> > >> from whatever is current when the VM starts up).
>> > >>
>> > >> On Wed, Mar 5, 2014 at 9:58 AM, Mike Tutkowski
>> > >>  wrote:
>> > >> > Hi,
>> > >> >
>> > >> > Perhaps I'm not following this correctly, but I'm a bit lost on
>> why we
>> > >> > are
>> > >> > talking about changing settings on running VMs.
>> > >> >
>> > >> > From what I understand, you are a representative of a storage
>> vendor
>> > >> > that
>> > >> > has a rate-limiting feature. You want to be able to not only set
>> the
>> > Max
>> > >> > IOPS, but also adjust them. Is this true?
>> > >> >
>> > >> > If so, I totally agree. SolidFire has control over Min 

Re: Change Volume IOPS on fly without detaching the disk feature.

[Punith S]

yea mike i agree with you , i was talking with respect to changing iops of
the datadisk on storage side, not with respect to hipervisor level settings,

and like marcus suggested i tried to tie changing the disk iops with
already available resize command but it has some limitations like i said
before , that we need to detach the disk in order to do that which implies
downtime for the user, but for a user who needs only to change the
performance metric of the datadisk , he can change the iops by directly
sending calls through the storage driver to the backend storage which
supports change in Qos metrics like our cloudbyte elastistor and others
without disturbing the hipervisor settings on fly with the available iops
of the primary storage pool.

and my doubt is that , how does hypervisor level throttling help in
controlling the iops of the disk ?  and if so you might be wasting the
available iops of the volume in backend!
and thanks for the support mike , i have done some poc on this , we shall
put this to 4.4 or 4.5,
and i needed to push our cloudbyte elastistor storage plugin to 4.4 , so we
should be pushing to master first before 28th of this month right ?

thanks,
punith


On Thu, Mar 6, 2014 at 12:32 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Exactly...and that shouldn't be too much of a problem.
>
> The "trick" will come into play when we have to take into consideration
> "generic" storage properties and that Min and Max IOPS should really be
> part of this group.
>
>
> On Wed, Mar 5, 2014 at 11:59 AM, Marcus  wrote:
>
> > Yes, that's what I mean. When the offering is changed, we need to have
> > a hook in there that calls the applicable storage driver for the
> > volume. Then the drivers can be free to implement or not implement.
> >
> > On Wed, Mar 5, 2014 at 11:36 AM, Mike Tutkowski
> >  wrote:
> > > Hi Marcus,
> > >
> > > In 4.4 I'm adding the ability to allow admins to specify Min and Max
> IOPS
> > > for Compute Offerings, as well (support only for XenServer in 4.4).
> > >
> > > I agree changing of IOPS should be doable through changing a Disk or
> > Compute
> > > Offering, but this doesn't work right now as the storage framework
> > doesn't
> > > tell the plug-in in question about the change.
> > >
> > > This is part of what Punith should investigate as we move forward with
> > this
> > > in 4.5.
> > >
> > > Talk to you later,
> > > Mike
> > >
> > >
> > > On Wed, Mar 5, 2014 at 11:12 AM, Marcus  wrote:
> > >>
> > >> Wouldn't this be implemented as just changing disk offerings? The
> > >> resizeVolume API call already allows you to switch disk offerings, we
> > >> just need to add a hook in there to optionally call the storage driver
> > >> (If volume is deployed to a primary storage) to make an update to the
> > >> iops properties on the backend storage. Come to think of it, depending
> > >> on how storage drivers are implementing the iops/limits feature,
> > >> resizeVolume might be breaking this, or simply requiring a reboot to
> > >> apply. That is, if the storage driver is setting the iops just once
> > >> upon volume creation, it's probably breaking when a user moves a disk
> > >> between offerings that may have alternate iops limits (this is
> > >> probably not the case for hypervisor throttling, as that's applied
> > >> from whatever is current when the VM starts up).
> > >>
> > >> On Wed, Mar 5, 2014 at 9:58 AM, Mike Tutkowski
> > >>  wrote:
> > >> > Hi,
> > >> >
> > >> > Perhaps I'm not following this correctly, but I'm a bit lost on why
> we
> > >> > are
> > >> > talking about changing settings on running VMs.
> > >> >
> > >> > From what I understand, you are a representative of a storage vendor
> > >> > that
> > >> > has a rate-limiting feature. You want to be able to not only set the
> > Max
> > >> > IOPS, but also adjust them. Is this true?
> > >> >
> > >> > If so, I totally agree. SolidFire has control over Min and Max IOPS
> > and
> > >> > it
> > >> > is on my to-do list to add support into CloudStack to be able to
> > >> > dynamically change these values (right now customers do this from
> the
> > >> > SolidFire API or its GUI).
> > >> >
> > >> > If you would like to work on this feature, that would be great. I'd
> be
> > >> > happy to review your design and code.
> > >> >
> > >> > One complication is that we are looking at adding support for
> generic
> > >> > key/value pairs for storage plug-ins in 4.5 and this would
> effectively
> > >> > remove the need to have Min and Max IOPS as "special" fields in the
> > >> > CloudStack API and GUI.
> > >> >
> > >> > I'm going to CC Chris Suichll (from NetApp) as he and I have already
> > >> > discussed this generic-properties concept. It would be good to get
> his
> > >> > feedback on how we might go about dynamically updating
> storage-plug-in
> > >> > key/value pairs.
> > >> >
> > >> > Thanks!
> > >> > Mike
> > >> >
> > >> >
> > >> > On Wed, Mar 5, 2014 at 3:12 AM, Wido den Hollander 
> > >> > wrote:
> > >> >
> > >> 

RE: The global settings beast...

[Alex Huang]

I don't think we will be able to get that until all configs are converted to 
using the ConfigKey.  Today, a lot of components just stores the parameter 
value as a member variable so changes can't be reflected without a reboot.  
Switching to ConfigKey will force all of those to change. 

--Alex

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, March 5, 2014 7:46 PM
> To: dev@cloudstack.apache.org
> Subject: Re: The global settings beast...
> 
> Hi Alex,
> 
> I typically update system.vm.use.local.storage to true before I create my 
> first
> zone in a fresh environment. The GUI tells me I need to reboot the CS
> Management Server, but I've noticed I don't really have to.
> 
> Is there a list somewhere that specifies which parameters really require a
> reboot of the CS MS and which ones don't? Also, I wonder if the GUI just
> says this for all Global Settings that are changed because it has no knowledge
> of which ones really require a reboot. Does that sound correct?
> 
> Thanks
> 
> 
> On Wed, Mar 5, 2014 at 6:18 PM, Alex Huang 
> wrote:
> 
> > I added something to address this last year.
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration
> >
> > It addresses several problems.
> >
> > - Parameter values are not stored in member variables so it's possible
> > for changed values to take effect without reboot.
> > - Breaks up the enum so that plugins can have their own config
> > parameters without changing the Config.java in CloudStack.
> > - If the default value for a parameter changes, this change
> > automatically updates a default value field and a timestamp so the
> > admin can evaluate whether they want to change their current value for
> the parameter.
> > - Deleted parameters from the code are marked with an update time
> > that's null so the admin knows the parameter have been removed after an
> upgrade.
> >
> > There are several todos left.  They are documented in
> > ConfigDepotImpl.java.  For the important ones, I filed bugs.  If you
> > have some time, please help work on them.
> >
> > - CLOUDSTACK-6206: No UI to reflect these changes.
> > - CLOUDSTACk-6207: Remove Config.java and move all enums to the new
> > ConfigKey parameter.
> > - CLOUDSTACK-6208: Create a per management server properties file that
> > contains parameters that pertains to each management server node,
> > instead of globally.
> >
> > --Alex
> >
> > > -Original Message-
> > > From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
> > > Sent: Wednesday, March 5, 2014 3:22 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: RE: The global settings beast...
> > >
> > > The need to restart is, the Managers  have configured with the
> > > values in Global Settings and running.
> > >
> > > -Original Message-
> > > From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
> > > Sent: Wednesday, March 5, 2014 3:13 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: The global settings beast...
> > >
> > > The need to restart the management server for any global
> > > configuration change is a problem.
> > > I spent at least a few hours trying to debug an issue only to
> > > realise
> > that its not
> > > an issue but, I have to restart the management server.
> > >
> > >
> > > ~Rajani
> > >
> > >
> > >
> > > On 05-Mar-2014, at 3:01 pm, Donal Lafferty
> > > 
> > > wrote:
> > >
> > > > In fairness, the biggest problem is having to reboot.
> > > >
> > > > WRT to b), there is a search option that avoids the need to scroll.
> > > >
> > > >> -Original Message-
> > > >> From: John Kinsella [mailto:j...@stratosec.co]
> > > >> Sent: 05 March 2014 08:22
> > > >> To: 
> > > >> Subject: The global settings beast...
> > > >>
> > > >> One thing that's been gnawing on me - we keep shoving more and
> > > >> more stuff into the global settings shortcut instead of creating
> > > >> a proper
> > settings
> > > UI.
> > > >> Then some new user comes along all shiny-eyed at the awesomeness
> > > >> of ACS, but wonders why something isn't working, only to be told
> > > >> that combination of a) it's in the docs and b) you have to scroll
> > > >> down through 30 items in global settings, then change something,
> > > >> then restart mgmt, then re- login...then it'll work.
> > > >>
> > > >> I know the UI is supposed to be a proof of concept, but I'm
> > > >> thinking we need to shed that label and empty out some closeted
> > > >> skeletons such
> > > as this.
> > > >>
> > > >> Am I the only one this bothers, or should we maybe set it as a
> > > >> goal for 4.5 (maybe this is on a feature list and I've missed it...)?
> > > >>
> > > >> John
> >
> >
> 
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*

Re: [DISCUSS] Checking in code that will break others' environments

[Mike Tutkowski]

Yeah, I definitely just meant a "heads up" during development if you are
going to change something that will break other people's environments who
update. If these people know in advance, they may choose to postpone an
update until they are at a better point.


On Wed, Mar 5, 2014 at 11:01 PM, Rajani Karuturi  wrote:

> Across versions db migration is taken care. I think this is bound to occur
> while working on a release, if multiple people work on the same branch with
> different work-in-progress features.
>
> Could we move to flyway or liquibase which can take care of db versioning
> and migration?
>
>
> ~Rajani
>
>
>
> On 06-Mar-2014, at 2:08 am, Mike Tutkowski 
> wrote:
>
> > Yeah, in this case, I'm not referring to erroneous code that breaks a
> > person's environment (since hopefully the person wouldn't have knowingly
> > checked in such code), but rather, say, DB-type changes that improve the
> > system, but break current setups.
> >
> > Just a heads-up e-mail with some easily identifiable tag.
> >
> > Can anyone think of a good tag for this? It's not always DB related, so
> we
> > might want the tag to be more general.
> >
> >
> > On Wed, Mar 5, 2014 at 1:28 PM, Ian Duffy  wrote:
> >
> >> +1 to this.
> >>
> >> Having the build suddenly break due to a git pull has been very
> annoying!
> >> I usually end up searching through the commit log and doing a resets
> >> until I find a commit where it works. Then waiting awhile until I do a
> >> git pull again and hoping the code was fixed.
> >>
> >> On 5 March 2014 20:19, Mike Tutkowski 
> >> wrote:
> >>> Hi,
> >>>
> >>> I encountered a bit of a problem this morning and thought I would bring
> >> it
> >>> up for discussion.
> >>>
> >>> If we already have a policy around this, please let me know.
> >>>
> >>> So, I fetched the latest and rebased my local 4.4 development branch on
> >> top
> >>> of master. This all went just fine.
> >>>
> >>> When I rebuilt and re-started the CS Management Server, I soon
> realized I
> >>> could no longer log in from the GUI.
> >>>
> >>> As it turns out, the DB schema had been updated and so my database was
> >> out
> >>> of date. The code was querying for fields that didn't exist in my DB.
> >>>
> >>> As far as I know, the easiest way to get around this is to destroy my
> >>> current cloud, run the script to re-build my database, then re-create
> my
> >>> cloud, which is somewhat time consuming.
> >>>
> >>> Do we have a process in place currently in which we ask those who make
> >> such
> >>> changes to send out a notification e-mail to dev@ to give people a
> >> heads up
> >>> that updating will lead to such issues? On previous projects, we would
> >> send
> >>> out an e-mail and then people could be aware to only update if they
> were
> >>> prepared for such re-work.
> >>>
> >>> To be clear here, I'm not meaning to pick on anyone in
> particular...this
> >>> has happened several times over the course of my CloudStack development
> >> and
> >>> I expect that I, too, have checked in such code (without sending out a
> >>> relevant e-mail) that lead people to have to perform such a complete
> >>> re-build action un-expectedly.
> >>>
> >>> What do people think about this? Maybe we should just add an e-mail tag
> >> or
> >>> something and point people to the relevant commit?
> >>>
> >>> 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
> >>> *(tm)*
> >>
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*
>
>


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

Re: [DISCUSS] Checking in code that will break others' environments

[Rajani Karuturi]

Across versions db migration is taken care. I think this is bound to occur 
while working on a release, if multiple people work on the same branch with 
different work-in-progress features. 

Could we move to flyway or liquibase which can take care of db versioning and 
migration? 


~Rajani



On 06-Mar-2014, at 2:08 am, Mike Tutkowski  wrote:

> Yeah, in this case, I'm not referring to erroneous code that breaks a
> person's environment (since hopefully the person wouldn't have knowingly
> checked in such code), but rather, say, DB-type changes that improve the
> system, but break current setups.
> 
> Just a heads-up e-mail with some easily identifiable tag.
> 
> Can anyone think of a good tag for this? It's not always DB related, so we
> might want the tag to be more general.
> 
> 
> On Wed, Mar 5, 2014 at 1:28 PM, Ian Duffy  wrote:
> 
>> +1 to this.
>> 
>> Having the build suddenly break due to a git pull has been very annoying!
>> I usually end up searching through the commit log and doing a resets
>> until I find a commit where it works. Then waiting awhile until I do a
>> git pull again and hoping the code was fixed.
>> 
>> On 5 March 2014 20:19, Mike Tutkowski 
>> wrote:
>>> Hi,
>>> 
>>> I encountered a bit of a problem this morning and thought I would bring
>> it
>>> up for discussion.
>>> 
>>> If we already have a policy around this, please let me know.
>>> 
>>> So, I fetched the latest and rebased my local 4.4 development branch on
>> top
>>> of master. This all went just fine.
>>> 
>>> When I rebuilt and re-started the CS Management Server, I soon realized I
>>> could no longer log in from the GUI.
>>> 
>>> As it turns out, the DB schema had been updated and so my database was
>> out
>>> of date. The code was querying for fields that didn't exist in my DB.
>>> 
>>> As far as I know, the easiest way to get around this is to destroy my
>>> current cloud, run the script to re-build my database, then re-create my
>>> cloud, which is somewhat time consuming.
>>> 
>>> Do we have a process in place currently in which we ask those who make
>> such
>>> changes to send out a notification e-mail to dev@ to give people a
>> heads up
>>> that updating will lead to such issues? On previous projects, we would
>> send
>>> out an e-mail and then people could be aware to only update if they were
>>> prepared for such re-work.
>>> 
>>> To be clear here, I'm not meaning to pick on anyone in particular...this
>>> has happened several times over the course of my CloudStack development
>> and
>>> I expect that I, too, have checked in such code (without sending out a
>>> relevant e-mail) that lead people to have to perform such a complete
>>> re-build action un-expectedly.
>>> 
>>> What do people think about this? Maybe we should just add an e-mail tag
>> or
>>> something and point people to the relevant commit?
>>> 
>>> 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
>>> *(tm)*
>> 
> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*

Re: Windows Guest vm takes diff. IP

[Tejas Gadaria]

Hi Jaypal,

MS is running in dhcp less environment.
Guest vlan has dhcp enabled.

Regards,
Tejas


On Thu, Mar 6, 2014 at 10:04 AM, Jayapal Reddy Uradi <
jayapalreddy.ur...@citrix.com> wrote:

> Hi Tejas,
>
> Is there any dhcp server running in your setup other than VR ?
> Is the  ip really served by VR ?
>
> Thanks,
> Jayapal
> On 06-Mar-2014, at 9:35 AM, Tejas Gadaria  wrote:
>
> > Hi,
> >
> > I have configured CS 4.0.2 with vmware in advance networking mode.
> > I am facing this problem with only Windows guest vm. Linux gueust as
> > working fine.
> >
> > While deploying Windows 7 guest vm cloudstsck assigning ip from guest ip
> > range.but guest vm actually takes different ip than what is shown under
> > 'NICs' tab.
> >
> > need your help on this.
> >
> > Regards,
> > Tejas
>
>

Re: Windows Guest vm takes diff. IP

[Jayapal Reddy Uradi]

Hi Tejas,

Is there any dhcp server running in your setup other than VR ?
Is the  ip really served by VR ?

Thanks,
Jayapal
On 06-Mar-2014, at 9:35 AM, Tejas Gadaria  wrote:

> Hi,
> 
> I have configured CS 4.0.2 with vmware in advance networking mode.
> I am facing this problem with only Windows guest vm. Linux gueust as
> working fine.
> 
> While deploying Windows 7 guest vm cloudstsck assigning ip from guest ip
> range.but guest vm actually takes different ip than what is shown under
> 'NICs' tab.
> 
> need your help on this.
> 
> Regards,
> Tejas

Re: Review Request 18759: HTTP support for console proxy and making it default

[Animesh Chaturvedi]

John can you review and close out this review. 

Thanks
Animesh

On Mar 5, 2014, at 12:47 PM, "Amogh Vasekar"  wrote:

> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18759/
> ---
> 
> (Updated March 5, 2014, 8:47 p.m.)
> 
> 
> Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-6204
>
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-6204
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes to support HTTP mode in Console Proxy, per 
> http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
> realhostip may go away
> 
> More details here : 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes
> 
> 
> Diffs (updated)
> -
> 
>  core/src/com/cloud/info/ConsoleProxyInfo.java 
> 3439f3d3bfa2e262c48f1d7b1ea4f58522f3fcbe 
>  
> engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
>  a649bb7212308de70c41e2d74de1d865949f1cb7 
>  
> plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
>  52cad3bc7af291e59eabc68e23e09248877e0a81 
>  server/src/com/cloud/configuration/Config.java 
> 473db96059a4367858f9487d901b7cb3a054654a 
>  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 
> c8769d43349dbc5a3103a00c905f29b7edef0468 
>  server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
> 611550e90832911fb182ad18d93a8a18333f3a35 
>  setup/db/db/schema-421to430.sql 39f58d43822ebbe469d9af433582846a80ce91a0 
>  systemvm/conf/consoleproxy.properties 
> bb452f5823cb2da2e12aa61d762de90e4349e9ee 
> 
> Diff: https://reviews.apache.org/r/18759/diff/
> 
> 
> Testing
> ---
> 
> Tested on local environment by 
> 1. Using HTTP based console proxy
> 2. HTTPS with realhostip domain
> 3. HTTPS with custom domain and self-signed cert
> 4. Secondary storage template download with custom domain and self-signed cert
> 
> 
> Thanks,
> 
> Amogh Vasekar
> 

Windows Guest vm takes diff. IP

[Tejas Gadaria]

Hi,

I have configured CS 4.0.2 with vmware in advance networking mode.
I am facing this problem with only Windows guest vm. Linux gueust as
working fine.

While deploying Windows 7 guest vm cloudstsck assigning ip from guest ip
range.but guest vm actually takes different ip than what is shown under
'NICs' tab.

need your help on this.

Regards,
Tejas

Re: The global settings beast...

[Mike Tutkowski]

Hi Alex,

I typically update system.vm.use.local.storage to true before I create my
first zone in a fresh environment. The GUI tells me I need to reboot the CS
Management Server, but I've noticed I don't really have to.

Is there a list somewhere that specifies which parameters really require a
reboot of the CS MS and which ones don't? Also, I wonder if the GUI just
says this for all Global Settings that are changed because it has no
knowledge of which ones really require a reboot. Does that sound correct?

Thanks


On Wed, Mar 5, 2014 at 6:18 PM, Alex Huang  wrote:

> I added something to address this last year.
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration
>
> It addresses several problems.
>
> - Parameter values are not stored in member variables so it's possible for
> changed values to take effect without reboot.
> - Breaks up the enum so that plugins can have their own config parameters
> without changing the Config.java in CloudStack.
> - If the default value for a parameter changes, this change automatically
> updates a default value field and a timestamp so the admin can evaluate
> whether they want to change their current value for the parameter.
> - Deleted parameters from the code are marked with an update time that's
> null so the admin knows the parameter have been removed after an upgrade.
>
> There are several todos left.  They are documented in
> ConfigDepotImpl.java.  For the important ones, I filed bugs.  If you have
> some time, please help work on them.
>
> - CLOUDSTACK-6206: No UI to reflect these changes.
> - CLOUDSTACk-6207: Remove Config.java and move all enums to the new
> ConfigKey parameter.
> - CLOUDSTACK-6208: Create a per management server properties file that
> contains parameters that pertains to each management server node, instead
> of globally.
>
> --Alex
>
> > -Original Message-
> > From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
> > Sent: Wednesday, March 5, 2014 3:22 AM
> > To: dev@cloudstack.apache.org
> > Subject: RE: The global settings beast...
> >
> > The need to restart is, the Managers  have configured with the values in
> > Global Settings and running.
> >
> > -Original Message-
> > From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
> > Sent: Wednesday, March 5, 2014 3:13 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: The global settings beast...
> >
> > The need to restart the management server for any global configuration
> > change is a problem.
> > I spent at least a few hours trying to debug an issue only to realise
> that its not
> > an issue but, I have to restart the management server.
> >
> >
> > ~Rajani
> >
> >
> >
> > On 05-Mar-2014, at 3:01 pm, Donal Lafferty 
> > wrote:
> >
> > > In fairness, the biggest problem is having to reboot.
> > >
> > > WRT to b), there is a search option that avoids the need to scroll.
> > >
> > >> -Original Message-
> > >> From: John Kinsella [mailto:j...@stratosec.co]
> > >> Sent: 05 March 2014 08:22
> > >> To: 
> > >> Subject: The global settings beast...
> > >>
> > >> One thing that's been gnawing on me - we keep shoving more and more
> > >> stuff into the global settings shortcut instead of creating a proper
> settings
> > UI.
> > >> Then some new user comes along all shiny-eyed at the awesomeness of
> > >> ACS, but wonders why something isn't working, only to be told that
> > >> combination of a) it's in the docs and b) you have to scroll down
> > >> through 30 items in global settings, then change something, then
> > >> restart mgmt, then re- login...then it'll work.
> > >>
> > >> I know the UI is supposed to be a proof of concept, but I'm thinking
> > >> we need to shed that label and empty out some closeted skeletons such
> > as this.
> > >>
> > >> Am I the only one this bothers, or should we maybe set it as a goal
> > >> for 4.5 (maybe this is on a feature list and I've missed it...)?
> > >>
> > >> John
>
>


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

RE: The global settings beast...

[Alex Huang]

I added something to address this last year.  

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration

It addresses several problems.

- Parameter values are not stored in member variables so it's possible for 
changed values to take effect without reboot.
- Breaks up the enum so that plugins can have their own config parameters 
without changing the Config.java in CloudStack.
- If the default value for a parameter changes, this change automatically 
updates a default value field and a timestamp so the admin can evaluate whether 
they want to change their current value for the parameter. 
- Deleted parameters from the code are marked with an update time that's null 
so the admin knows the parameter have been removed after an upgrade.

There are several todos left.  They are documented in ConfigDepotImpl.java.  
For the important ones, I filed bugs.  If you have some time, please help work 
on them.

- CLOUDSTACK-6206: No UI to reflect these changes.
- CLOUDSTACk-6207: Remove Config.java and move all enums to the new ConfigKey 
parameter.
- CLOUDSTACK-6208: Create a per management server properties file that contains 
parameters that pertains to each management server node, instead of globally.

--Alex

> -Original Message-
> From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
> Sent: Wednesday, March 5, 2014 3:22 AM
> To: dev@cloudstack.apache.org
> Subject: RE: The global settings beast...
> 
> The need to restart is, the Managers  have configured with the values in
> Global Settings and running.
> 
> -Original Message-
> From: Rajani Karuturi [mailto:rajani.karut...@citrix.com]
> Sent: Wednesday, March 5, 2014 3:13 PM
> To: dev@cloudstack.apache.org
> Subject: Re: The global settings beast...
> 
> The need to restart the management server for any global configuration
> change is a problem.
> I spent at least a few hours trying to debug an issue only to realise that 
> its not
> an issue but, I have to restart the management server.
> 
> 
> ~Rajani
> 
> 
> 
> On 05-Mar-2014, at 3:01 pm, Donal Lafferty 
> wrote:
> 
> > In fairness, the biggest problem is having to reboot.
> >
> > WRT to b), there is a search option that avoids the need to scroll.
> >
> >> -Original Message-
> >> From: John Kinsella [mailto:j...@stratosec.co]
> >> Sent: 05 March 2014 08:22
> >> To: 
> >> Subject: The global settings beast...
> >>
> >> One thing that's been gnawing on me - we keep shoving more and more
> >> stuff into the global settings shortcut instead of creating a proper 
> >> settings
> UI.
> >> Then some new user comes along all shiny-eyed at the awesomeness of
> >> ACS, but wonders why something isn't working, only to be told that
> >> combination of a) it's in the docs and b) you have to scroll down
> >> through 30 items in global settings, then change something, then
> >> restart mgmt, then re- login...then it'll work.
> >>
> >> I know the UI is supposed to be a proof of concept, but I'm thinking
> >> we need to shed that label and empty out some closeted skeletons such
> as this.
> >>
> >> Am I the only one this bothers, or should we maybe set it as a goal
> >> for 4.5 (maybe this is on a feature list and I've missed it...)?
> >>
> >> John

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Alena Prokharchyk]

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


Fails to apply on the latest master :(

alena@Alenas-MacBook-Air: [master]~/repos/dr/cloudstack$ git am --signoff < 
~/Desktop/0001-Dispatcher-corrections-refactoring-and-tests.patch
Applying: Dispatcher corrections, refactoring and tests
error: patch failed: server/src/com/cloud/api/ApiServer.java:881
error: server/src/com/cloud/api/ApiServer.java: patch does not apply
Patch failed at 0001 Dispatcher corrections, refactoring and tests
The copy of the patch that failed is found in:
   /Users/alena/repos/dr/cloudstack/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

- Alena Prokharchyk


On March 5, 2014, 10:35 a.m., Antonio Fornie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17888/
> ---
> 
> (Updated March 5, 2014, 10:35 a.m.)
> 
> 
> Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Dispatcher corrections, refactoring and tests. Corrects problems from 
> previous attempts that were reverted by Alena. Most of the changes are the 
> same, but this one is not creating conflicts of Map types for Aync Commands 
> or for parameters as Lists or Maps.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
>   api/src/org/apache/cloudstack/api/BaseCmd.java e869ddf 
>   api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
>   api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java 
> b2c6734 
>   api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java 
> cf5d355 
>   
> api/src/org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmProfileCmd.java
>  570e018 
>   api/test/org/apache/cloudstack/api/BaseCmdTest.java PRE-CREATION 
>   
> server/resources/META-INF/cloudstack/core/spring-server-core-misc-context.xml 
> fd2f5fb 
>   server/src/com/cloud/api/ApiAsyncJobDispatcher.java f037f2e 
>   server/src/com/cloud/api/ApiDispatcher.java 5bdefe7 
>   server/src/com/cloud/api/ApiServer.java 3df599e 
>   server/src/com/cloud/api/ApiServlet.java 46f7eba 
>   server/src/com/cloud/api/dispatch/CommandCreationWorker.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/DispatchChain.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/DispatchChainFactory.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/DispatchTask.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/DispatchWorker.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/ParamGenericValidationWorker.java 
> PRE-CREATION 
>   server/src/com/cloud/api/dispatch/ParamProcessWorker.java PRE-CREATION 
>   server/src/com/cloud/api/dispatch/ParamSemanticValidationWorker.java 
> PRE-CREATION 
>   server/src/com/cloud/api/dispatch/ParamUnpackWorker.java PRE-CREATION 
>   server/src/com/cloud/network/as/AutoScaleManagerImpl.java 208b4a4 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> 37171f5 
>   server/src/com/cloud/storage/snapshot/SnapshotSchedulerImpl.java a85c052 
>   server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
>   server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
> PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
>   server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/17888/diff/
> 
> 
> Testing
> ---
> 
> Full build and test plus manually testing many features. Also including 
> CreateTagsCommand that failed in previous commit.
> 
> All unit and integration tests.
> 
> Test CS Web UI with the browser going through several use cases.
> 
> Also use the CS API by sending HTTP requests generated manually including 
> requests for Async Commands with Map parameters and during these tests apart 
> fromtesting correct functionality I also debugged to check that Maps created 
> correctly where they should but also that in the cases where the async 
> command must be persisted and later on retrieved and deserialized by gson 
> everything works ok and does what and where is expected. An example based on 
> the comment by Alena:
> http://localhost:8096/client/api?command=createTags&resourceids=ids&resourcetype=type&tags[0].key=r

cherrypick to 4.3

[Alena Prokharchyk]

Animesh, can you please cherry-pick one more commit from 4.3-forward to 4.3? 
Its a one liner change, yet it fixes Critical bug for VPC

d009c8c7b229a1bb02834f52d9cac17f46e33349
https://issues.apache.org/jira/browse/CLOUDSTACK-6205
"VPC: when network is created in Setup state (with vlan specified), it never 
gets plugged to the VPC VR after restart”

Thanks,
Alena.

Re: Review Request 18194: G11N: Fixed the Hardcoding Issue

[Brian Federle]

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

Ship it!


Ship It!

- Brian Federle


On March 5, 2014, 9:01 a.m., Vetrivel Chinnasamy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18194/
> ---
> 
> (Updated March 5, 2014, 9:01 a.m.)
> 
> 
> Review request for cloudstack and Brian Federle.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Externalized the hard coded strings by adding reference ID and label to the 
> resource files. Also updated the dictionary.jsp file.
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages.properties 82ac499 
>   client/WEB-INF/classes/resources/messages_ja_JP.properties 828cf54 
>   client/WEB-INF/classes/resources/messages_zh_CN.properties f4c206b 
>   tools/ngui/static/js/app/accounts/accounts.js eae5070 
>   tools/ngui/static/js/app/storage/storage.js e562a95 
>   ui/dictionary.jsp 11dbeb5 
>   ui/modules/vnmcNetworkProvider/vnmcNetworkProvider.js d618b23 
>   ui/scripts/configuration.js 869b876 
>   ui/scripts/installWizard.js 25de4aa 
>   ui/scripts/instances.js 53c9e98 
>   ui/scripts/network.js 6ce66e8 
>   ui/scripts/sharedFunctions.js f0afea5 
>   ui/scripts/storage.js 1cd8d2e 
>   ui/scripts/system.js c21e277 
>   ui/scripts/templates.js 3551613 
>   ui/scripts/ui-custom/zoneChart.js e847a19 
>   ui/scripts/ui/core.js 06be12b 
>   ui/scripts/ui/widgets/tagger.js 673bd43 
>   ui/scripts/vpc.js 770ee9b 
>   ui/scripts/zoneWizard.js 1de3646 
> 
> Diff: https://reviews.apache.org/r/18194/diff/
> 
> 
> Testing
> ---
> 
> Local unit testing done by replacing the java-script, dictionary.jsp and 
> properties files.
> 
> 
> Thanks,
> 
> Vetrivel Chinnasamy
> 
>

Re: cherry-pick to 4.3

[Alena Prokharchyk]

Done, thank you.

From: Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Date: Wednesday, March 5, 2014 at 1:36 PM
To: Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Cc: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: RE: cherry-pick to 4.3

Alena

I ran into cherry-pick issue. Can you fix it yourself and push in 4.3

From: Alena Prokharchyk
Sent: Wednesday, March 05, 2014 1:18 PM
To: Animesh Chaturvedi
Cc: dev@cloudstack.apache.org
Subject: cherry-pick to 4.3

Animesh, can you please cherry-pick the commit below from 4.3-forward to 43?
444e8f6bb3447a7eeb97f7c5d9b46abba3150072

Bug id is https://issues.apache.org/jira/browse/CLOUDSTACK-6198

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[ASF Subversion and Git Services]

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


Commit e0e13434b9191917342f751c07e8097f7f92a430 in cloudstack's branch 
refs/heads/4.3 from Alena Prokharchyk
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e0e1343 ]

CLOUDSTACK-5872: use List DS for storing NicProfiles as public network can have 
more than one nic

Conflicts:
server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java


- ASF Subversion and Git Services


On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17591/
> ---
> 
> (Updated Jan. 31, 2014, 2:51 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-5872
> https://issues.apache.org/jira/browse/CLOUDSTACK-5872
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain 
> useful information
> 
> Updated the following classes to return a project object after async jobs 
> complete:
>  api/src/com/cloud/projects/ProjectService.java |  6 ++--
>  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
>  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
>  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
>  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
>  .../src/com/cloud/projects/ProjectManagerImpl.java | 34 
> +++---
>  .../com/cloud/projects/MockProjectManagerImpl.java | 16 +-
> 
> Previously these API commands only returned "success => true" in the aysnc 
> job result.  Now it returns the project that a user was added/deleted to.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/projects/ProjectService.java dc882ef 
>   
> api/src/org/apache/cloudstack/api/command/user/account/AddAccountToProjectCmd.java
>  36df579 
>   
> api/src/org/apache/cloudstack/api/command/user/account/DeleteAccountFromProjectCmd.java
>  f6aa36c 
>   
> api/src/org/apache/cloudstack/api/command/user/project/UpdateProjectInvitationCmd.java
>  dda7b54 
>   server/src/com/cloud/projects/ProjectManager.java f568146 
>   server/src/com/cloud/projects/ProjectManagerImpl.java 5a0ed1c 
>   server/test/com/cloud/projects/MockProjectManagerImpl.java dc377ff 
> 
> Diff: https://reviews.apache.org/r/17591/diff/
> 
> 
> Testing
> ---
> 
> Testing done on master.
> 
> 
> Thanks,
> 
> David Grizzanti
> 
>

RE: cherry-pick to 4.3

[Animesh Chaturvedi]

Alena

I ran into cherry-pick issue. Can you fix it yourself and push in 4.3

From: Alena Prokharchyk
Sent: Wednesday, March 05, 2014 1:18 PM
To: Animesh Chaturvedi
Cc: dev@cloudstack.apache.org
Subject: cherry-pick to 4.3

Animesh, can you please cherry-pick the commit below from 4.3-forward to 43?
444e8f6bb3447a7eeb97f7c5d9b46abba3150072

Bug id is https://issues.apache.org/jira/browse/CLOUDSTACK-6198

Re: Review Request 17790: Domain-Account-User Sync Up Among Multiple Regions

[Alex Ough]

What branch needs to be based to create a review request of this
implementation that will be included in 4.4 release?
4.3 or 4.3-forward?

Thanks
Alex Ough


On Tue, Mar 4, 2014 at 1:25 PM, Alex Ough  wrote:

> Yes, by 3/7.
>
> Thanks
> Alex Ough
>
>
> On Tue, Mar 4, 2014 at 12:30 PM, Daan Hoogland wrote:
>
>> This week? should be ok. end of next week is too late!
>>
>> On Tue, Mar 4, 2014 at 6:17 PM, Alex Ough  wrote:
>> > Do you think it is ok to wrap up the implementation until the end of
>> this
>> > week to make this included in 4.4 release?
>> >
>> > Thanks
>> > Alex Ough
>> >
>> >
>> > On Sun, Mar 2, 2014 at 2:10 PM, Daan Hoogland 
>> > wrote:
>> >>
>> >> two weeks from now, but under debate. Let's go with that, though.
>> >>
>> >> On Sun, Mar 2, 2014 at 1:17 AM, Alex Ough 
>> wrote:
>> >> > Can you tell me when the deadline for 4.4 is?
>> >> >
>> >> > Thanks
>> >> > Alex Ough
>> >> >
>> >> >
>> >> > On Sat, Mar 1, 2014 at 2:26 PM, Daan Hoogland <
>> daan.hoogl...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Ha Alex,
>> >> >>
>> >> >> branch 4.3 is going to be a problem. We will be able to release this
>> >> >> with 4.4 if we hurry.
>> >> >>
>> >> >> On Fri, Feb 28, 2014 at 4:01 PM, Alex Ough 
>> >> >> wrote:
>> >> >> > Hi Daan,
>> >> >> >
>> >> >> > 1. Yes, we'll update the request once all the unit tests are
>> >> >> > completed.
>> >> >> > 2. And yes, it is a branch from 4.3
>> >> >> > 3. I'm using the global parameter, called
>> >> >> > 'region.auto.generation.interval'
>> >> >> > and the value is 0 (millisec) by default.
>> >> >> > If you set the value more than 0, it will automatically
>> >> >> > create/update/remove domains/accounts/users with that interval,
>> >> >> > which will trigger the scheduled full scan to sync the newly
>> >> >> > changed
>> >> >> > resources.
>> >> >> >
>> >> >> > Let me know if you need more info.
>> >> >> > Thanks
>> >> >> > Alex Ough
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Feb 27, 2014 at 3:50 PM, Daan Hoogland
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> I see, great.
>> >> >> >>
>> >> >> >> I will find a moment to apply it and test. It looks good at first
>> >> >> >> sight.
>> >> >> >>
>> >> >> >> Don't forget adding the license header to the new files. Are you
>> >> >> >> updating the review request with these tests?
>> >> >> >>
>> >> >> >> You are using a local branch to implement this on,
>> >> >> >> 'alexoughsg/Albatross'  is a fork of cloudstack, is it?
>> >> >> >> Let's discuss merge back and testing.
>> >> >> >> Do you have a integration test script in Marvin and/or scenarios
>> >> >> >> that
>> >> >> >> will ensure continued functionality for the sync feature?
>> >> >> >>
>> >> >> >>
>> >> >> >> thanks,
>> >> >> >> Daan
>> >> >> >>
>> >> >> >> On Thu, Feb 27, 2014 at 9:19 PM, Alex Ough <
>> alex.o...@sungard.com>
>> >> >> >> wrote:
>> >> >> >> > Hi Daan,
>> >> >> >> >
>> >> >> >> > We started to work on implementing unit tests and checked in
>> some
>> >> >> >> > of
>> >> >> >> > them,
>> >> >> >> > so please review them and let us know if there is any
>> >> >> >> > comments/suggestions.
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> https://github.com/alexoughsg/Albatross/commit/fca94db36054ee35f5da85c69c2471430e0eebfe
>> >> >> >> >
>> >> >> >> > Thanks
>> >> >> >> > Alex Ough
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Thu, Feb 13, 2014 at 3:15 PM, Alex Ough <
>> alex.o...@sungard.com>
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> We're just about to add unit tests, so I'll add them once
>> >> >> >> >> completed.
>> >> >> >> >>
>> >> >> >> >> Thanks
>> >> >> >> >> Alex Ough
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> On Thu, Feb 13, 2014 at 3:12 PM, Daan Hoogland
>> >> >> >> >> 
>> >> >> >> >> wrote:
>> >> >> >> >>>
>> >> >> >> >>> h Alex,
>> >> >> >> >>>
>> >> >> >> >>>  looks alright (i did mean with newlines but I don't know if
>> >> >> >> >>> this
>> >> >> >> >>> is
>> >> >> >> >>> actually caught by our checkstyle run) I was wondering if you
>> >> >> >> >>> have
>> >> >> >> >>> any
>> >> >> >> >>> unit
>> >> >> >> >>> tests for your code. I can see you did take testing seriously
>> >> >> >> >>> and I
>> >> >> >> >>> would
>> >> >> >> >>> like to see this formalized for future reference and
>> repetition
>> >> >> >> >>> on
>> >> >> >> >>> updates.
>> >> >> >> >>> Can you add some stuff in this line?
>> >> >> >> >>>
>> >> >> >> >>> thanks,
>> >> >> >> >>> Daan
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >> >>> On Thu, Feb 13, 2014 at 9:52 PM, Alex Ough
>> >> >> >> >>> 
>> >> >> >> >>> wrote:
>> >> >> >> 
>> >> >> >>  Hi Daan,
>> >> >> >>  Does it look good to you?
>> >> >> >> 
>> >> >> >>  Thanks
>> >> >> >>  Alex Ough
>> >> >> >> 
>> >> >> >> 
>> >> >> >>  On Mon, Feb 10, 2014 at 1:07 PM, Alex Ough
>> >> >> >>  
>> >> >> >>  wrote:
>> >> >> >> >
>> >> >> >> > This is an automatically generated e-mail. To reply, visit:
>> >> >> >> > https://review

cherry-pick to 4.3

[Alena Prokharchyk]

Animesh, can you please cherry-pick the commit below from 4.3-forward to 43?
444e8f6bb3447a7eeb97f7c5d9b46abba3150072

Bug id is https://issues.apache.org/jira/browse/CLOUDSTACK-6198

RE: [4.3] [Cherry-pick] developer mysql dependencies

[Animesh Chaturvedi]

Hugo 

Do I need this commit of yours from master into 4.3 which moves mysql ha 
strategy to plugin

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=a0f932437c9ac9a0a82cc9b45b1aa6f17e8a478a


> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Wednesday, March 05, 2014 12:07 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [4.3] [Cherry-pick] developer mysql dependencies
> 
> Done
> 
> > -Original Message-
> > From: John Kinsella [mailto:j...@stratosec.co]
> > Sent: Wednesday, February 26, 2014 6:29 PM
> > To: 
> > Subject: [4.3] [Cherry-pick] developer mysql dependencies
> >
> > Dearest RM - would like the following commits from 4.3-forward picked
> > into 4.3.
> >
> > To the best of my knowledge they comply with ASF third-party licensing
> > policy for build scripts [1].
> >
> > 24dcf2948c2d4cdd98fcda0f766d82f40eee8be1
> > 2c3cd90b5604cde8123968b15ef6c53bad43b5e2
> > f5aeac845df8b73b1525442461a8a811e61439d0
> > 54db315214f8dd518eaf1f1615d423d9f4129d31
> >
> > John
> > 1: https://www.apache.org/legal/3party.html#options-build

jenkins job for the developer build

[chris snow]

Is there a jenkins job for the developer's build, i.e. mvn clean
install -P developer,systemvm?  As a newbie cloudstack developer, when
the build fails locally it's difficult to know whether the problem is
because I am doing something wrong, or if the problem is due to a bad
commit.

Re: Review Request 18759: HTTP support for console proxy and making it default

[Amogh Vasekar]

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

(Updated March 5, 2014, 8:47 p.m.)


Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.


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

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


Repository: cloudstack-git


Description
---

Changes to support HTTP mode in Console Proxy, per 
http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
realhostip may go away

More details here : 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes


Diffs (updated)
-

  core/src/com/cloud/info/ConsoleProxyInfo.java 
3439f3d3bfa2e262c48f1d7b1ea4f58522f3fcbe 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
 a649bb7212308de70c41e2d74de1d865949f1cb7 
  
plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
 52cad3bc7af291e59eabc68e23e09248877e0a81 
  server/src/com/cloud/configuration/Config.java 
473db96059a4367858f9487d901b7cb3a054654a 
  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 
c8769d43349dbc5a3103a00c905f29b7edef0468 
  server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
611550e90832911fb182ad18d93a8a18333f3a35 
  setup/db/db/schema-421to430.sql 39f58d43822ebbe469d9af433582846a80ce91a0 
  systemvm/conf/consoleproxy.properties 
bb452f5823cb2da2e12aa61d762de90e4349e9ee 

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


Testing
---

Tested on local environment by 
1. Using HTTP based console proxy
2. HTTPS with realhostip domain
3. HTTPS with custom domain and self-signed cert
4. Secondary storage template download with custom domain and self-signed cert


Thanks,

Amogh Vasekar

Re: [DISCUSS] Checking in code that will break others' environments

[Mike Tutkowski]

Yeah, in this case, I'm not referring to erroneous code that breaks a
person's environment (since hopefully the person wouldn't have knowingly
checked in such code), but rather, say, DB-type changes that improve the
system, but break current setups.

Just a heads-up e-mail with some easily identifiable tag.

Can anyone think of a good tag for this? It's not always DB related, so we
might want the tag to be more general.


On Wed, Mar 5, 2014 at 1:28 PM, Ian Duffy  wrote:

> +1 to this.
>
> Having the build suddenly break due to a git pull has been very annoying!
> I usually end up searching through the commit log and doing a resets
> until I find a commit where it works. Then waiting awhile until I do a
> git pull again and hoping the code was fixed.
>
> On 5 March 2014 20:19, Mike Tutkowski 
> wrote:
> > Hi,
> >
> > I encountered a bit of a problem this morning and thought I would bring
> it
> > up for discussion.
> >
> > If we already have a policy around this, please let me know.
> >
> > So, I fetched the latest and rebased my local 4.4 development branch on
> top
> > of master. This all went just fine.
> >
> > When I rebuilt and re-started the CS Management Server, I soon realized I
> > could no longer log in from the GUI.
> >
> > As it turns out, the DB schema had been updated and so my database was
> out
> > of date. The code was querying for fields that didn't exist in my DB.
> >
> > As far as I know, the easiest way to get around this is to destroy my
> > current cloud, run the script to re-build my database, then re-create my
> > cloud, which is somewhat time consuming.
> >
> > Do we have a process in place currently in which we ask those who make
> such
> > changes to send out a notification e-mail to dev@ to give people a
> heads up
> > that updating will lead to such issues? On previous projects, we would
> send
> > out an e-mail and then people could be aware to only update if they were
> > prepared for such re-work.
> >
> > To be clear here, I'm not meaning to pick on anyone in particular...this
> > has happened several times over the course of my CloudStack development
> and
> > I expect that I, too, have checked in such code (without sending out a
> > relevant e-mail) that lead people to have to perform such a complete
> > re-build action un-expectedly.
> >
> > What do people think about this? Maybe we should just add an e-mail tag
> or
> > something and point people to the relevant commit?
> >
> > 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
> > *(tm)*
>



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

Re: [DISCUSS] Checking in code that will break others' environments

[Mike Tutkowski]

I see two recent SQL-related updates:

f291951990fbf0c51c2e9aa95d246d73e8abde8b

339c4f4c3fb4f50e58b780893b16be192f985d82


On Wed, Mar 5, 2014 at 1:23 PM, Sudha Ponnaganti <
sudha.ponnaga...@citrix.com> wrote:

> +1 esp changes in DB area should be notified.
> DB changes should be frozen couple of weeks before RC so QA would get time
> to run through tests - otherwise we would be going in circles.
>
> BTW do you have commit id for this particular check in
>
> Thanks
> /Sudha
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, March 05, 2014 12:19 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Checking in code that will break others' environments
>
> Hi,
>
> I encountered a bit of a problem this morning and thought I would bring it
> up for discussion.
>
> If we already have a policy around this, please let me know.
>
> So, I fetched the latest and rebased my local 4.4 development branch on
> top of master. This all went just fine.
>
> When I rebuilt and re-started the CS Management Server, I soon realized I
> could no longer log in from the GUI.
>
> As it turns out, the DB schema had been updated and so my database was out
> of date. The code was querying for fields that didn't exist in my DB.
>
> As far as I know, the easiest way to get around this is to destroy my
> current cloud, run the script to re-build my database, then re-create my
> cloud, which is somewhat time consuming.
>
> Do we have a process in place currently in which we ask those who make
> such changes to send out a notification e-mail to dev@ to give people a
> heads up that updating will lead to such issues? On previous projects, we
> would send out an e-mail and then people could be aware to only update if
> they were prepared for such re-work.
>
> To be clear here, I'm not meaning to pick on anyone in particular...this
> has happened several times over the course of my CloudStack development and
> I expect that I, too, have checked in such code (without sending out a
> relevant e-mail) that lead people to have to perform such a complete
> re-build action un-expectedly.
>
> What do people think about this? Maybe we should just add an e-mail tag or
> something and point people to the relevant commit?
>
> 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
> *(tm)*
>



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

Re: Review Request 18759: HTTP support for console proxy and making it default

[Amogh Vasekar]

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

(Updated March 5, 2014, 8:33 p.m.)


Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.


Changes
---

Updating diff that will keep reviewboard happy and allow to view changes 


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

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


Repository: cloudstack-git


Description
---

Changes to support HTTP mode in Console Proxy, per 
http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
realhostip may go away

More details here : 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes


Diffs (updated)
-

  core/src/com/cloud/info/ConsoleProxyInfo.java 
3439f3d3bfa2e262c48f1d7b1ea4f58522f3fcbe 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
 a649bb7212308de70c41e2d74de1d865949f1cb7 
  
plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
 52cad3bc7af291e59eabc68e23e09248877e0a81 
  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 
c8769d43349dbc5a3103a00c905f29b7edef0468 
  server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
611550e90832911fb182ad18d93a8a18333f3a35 
  setup/db/db/schema-421to430.sql 39f58d43822ebbe469d9af433582846a80ce91a0 
  systemvm/conf/consoleproxy.properties 
bb452f5823cb2da2e12aa61d762de90e4349e9ee 

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


Testing
---

Tested on local environment by 
1. Using HTTP based console proxy
2. HTTPS with realhostip domain
3. HTTPS with custom domain and self-signed cert
4. Secondary storage template download with custom domain and self-signed cert


Thanks,

Amogh Vasekar

Re: [DISCUSS] Checking in code that will break others' environments

[Ian Duffy]

+1 to this.

Having the build suddenly break due to a git pull has been very annoying!
I usually end up searching through the commit log and doing a resets
until I find a commit where it works. Then waiting awhile until I do a
git pull again and hoping the code was fixed.

On 5 March 2014 20:19, Mike Tutkowski  wrote:
> Hi,
>
> I encountered a bit of a problem this morning and thought I would bring it
> up for discussion.
>
> If we already have a policy around this, please let me know.
>
> So, I fetched the latest and rebased my local 4.4 development branch on top
> of master. This all went just fine.
>
> When I rebuilt and re-started the CS Management Server, I soon realized I
> could no longer log in from the GUI.
>
> As it turns out, the DB schema had been updated and so my database was out
> of date. The code was querying for fields that didn't exist in my DB.
>
> As far as I know, the easiest way to get around this is to destroy my
> current cloud, run the script to re-build my database, then re-create my
> cloud, which is somewhat time consuming.
>
> Do we have a process in place currently in which we ask those who make such
> changes to send out a notification e-mail to dev@ to give people a heads up
> that updating will lead to such issues? On previous projects, we would send
> out an e-mail and then people could be aware to only update if they were
> prepared for such re-work.
>
> To be clear here, I'm not meaning to pick on anyone in particular...this
> has happened several times over the course of my CloudStack development and
> I expect that I, too, have checked in such code (without sending out a
> relevant e-mail) that lead people to have to perform such a complete
> re-build action un-expectedly.
>
> What do people think about this? Maybe we should just add an e-mail tag or
> something and point people to the relevant commit?
>
> 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
> *(tm)*

RE: [DISCUSS] Checking in code that will break others' environments

[Sudha Ponnaganti]

+1 esp changes in DB area should be notified. 
DB changes should be frozen couple of weeks before RC so QA would get time to 
run through tests - otherwise we would be going in circles. 

BTW do you have commit id for this particular check in

Thanks
/Sudha

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Wednesday, March 05, 2014 12:19 PM
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Checking in code that will break others' environments

Hi,

I encountered a bit of a problem this morning and thought I would bring it up 
for discussion.

If we already have a policy around this, please let me know.

So, I fetched the latest and rebased my local 4.4 development branch on top of 
master. This all went just fine.

When I rebuilt and re-started the CS Management Server, I soon realized I could 
no longer log in from the GUI.

As it turns out, the DB schema had been updated and so my database was out of 
date. The code was querying for fields that didn't exist in my DB.

As far as I know, the easiest way to get around this is to destroy my current 
cloud, run the script to re-build my database, then re-create my cloud, which 
is somewhat time consuming.

Do we have a process in place currently in which we ask those who make such 
changes to send out a notification e-mail to dev@ to give people a heads up 
that updating will lead to such issues? On previous projects, we would send out 
an e-mail and then people could be aware to only update if they were prepared 
for such re-work.

To be clear here, I'm not meaning to pick on anyone in particular...this has 
happened several times over the course of my CloudStack development and I 
expect that I, too, have checked in such code (without sending out a relevant 
e-mail) that lead people to have to perform such a complete re-build action 
un-expectedly.

What do people think about this? Maybe we should just add an e-mail tag or 
something and point people to the relevant commit?

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
*(tm)*

Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC

[Karl Harris]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

Changes/additions to BASH scripts and .java files as well as pseudo code 
comments. This posting is a sanity check review posting; before I get too far 
along with making the changes required for this JIRA CloudStack-764 nTier Apps 
2.0 : Redundant Virtual Router for VPC I thought I'd publish my intentions to 
the community to review and comment.


Diffs
-

  core/src/com/cloud/agent/api/SetupGuestNetworkCommand.java 
2cf5bf8ffaa2b0df122c69f047ee3f56982267e1 
  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 03af0da51b1eec93eb878fd1ebeca2ff2e0802ce 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 69b7c9e07c753c0f0c93197a809acfb3399cf555 
  systemvm/patches/debian/config/opt/cloud/bin/vpc_guestnw.sh 
e5da2e096b30f6fdb15226e889517537d04f2e3e 

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


Testing
---

None, yet still coding


Thanks,

Karl Harris

[DISCUSS] Checking in code that will break others' environments

[Mike Tutkowski]

Hi,

I encountered a bit of a problem this morning and thought I would bring it
up for discussion.

If we already have a policy around this, please let me know.

So, I fetched the latest and rebased my local 4.4 development branch on top
of master. This all went just fine.

When I rebuilt and re-started the CS Management Server, I soon realized I
could no longer log in from the GUI.

As it turns out, the DB schema had been updated and so my database was out
of date. The code was querying for fields that didn't exist in my DB.

As far as I know, the easiest way to get around this is to destroy my
current cloud, run the script to re-build my database, then re-create my
cloud, which is somewhat time consuming.

Do we have a process in place currently in which we ask those who make such
changes to send out a notification e-mail to dev@ to give people a heads up
that updating will lead to such issues? On previous projects, we would send
out an e-mail and then people could be aware to only update if they were
prepared for such re-work.

To be clear here, I'm not meaning to pick on anyone in particular...this
has happened several times over the course of my CloudStack development and
I expect that I, too, have checked in such code (without sending out a
relevant e-mail) that lead people to have to perform such a complete
re-build action un-expectedly.

What do people think about this? Maybe we should just add an e-mail tag or
something and point people to the relevant commit?

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
*(tm)*

Re: 4.3 vote

[John Kinsella]

The dependency’s actually been broken for a very long time, apparently. On a 
clean box with no maven repository cache (rm -rf ~/.m2/repository), awsapi (and 
therefore RPMs) will not build.

It looks like Noa saw similar issue in 
42f3804fbdde7bfe4f3676ef0c18a54dfe95354c, but I’m still seeing issues.

John

On Mar 5, 2014, at 11:10 AM, Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>> wrote:

John when was the dependency broken? Are you not able to build AWSAPI?

-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Wednesday, March 05, 2014 11:00 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.3 vote

FYI I'm still -1 until CLOUDSTACK-6156 and
https://reviews.apache.org/r/18392/ is addressed.

On Mar 5, 2014, at 10:10 AM, Animesh Chaturvedi
mailto:animesh.chaturv...@citrix.com>> wrote:



-Original Message-
From: sebgoa [mailto:run...@gmail.com]
Sent: Wednesday, March 05, 2014 7:58 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.3 vote


On Mar 5, 2014, at 4:54 PM, Nux! mailto:n...@li.nux.ro>> wrote:

On 05.03.2014 15:52, Animesh Chaturvedi wrote:
Working on it now, waiting on 1 last thing for realhostip changes

So, does the realhostip "feature" disappear starting with 4.3?

if that's the case we need to put this on the release notes. Happy to
do so if someone send me the text..
[Animesh] It is really a convenience that we got used to not a
feature. You can specify your own domain name and change the
certificate even now with 4.2 and prior releases. The instructions are
in Admin Guide [1]

Amogh has put a wiki on the changes at [2].


[1]
http://cloudstack.apache.org/docs/en-US//Apache_CloudStack/4.2.0/html/
Admin_Guide/console-proxy.html#change-console-proxy-ssl-certificate-do
main

[2]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+chan
ges




Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro



Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

RE: Changing the SSL certificate for my own realhostip [HOWTO]

[Nux!]

On 05.03.2014 19:17, Suresh Sadhu wrote:

I have tested with self-signed  ssl certificate with my own local
domain name(replaced realhost with my domain by following steps
mentioned in the  CTX support article) on my test setup..cpvm
recreated  successfully  and console access with new domain name.


Yes, if you have your own CRT and KEY self-signed then you don't need 
to mess with the DB.


Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Review Request 18759: HTTP support for console proxy and making it default

[Amogh Vasekar]

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

(Updated March 5, 2014, 7:26 p.m.)


Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.


Changes
---

Addressing comments, and adding the sql upgrade file as per the mentioned wiki


Repository: cloudstack-git


Description
---

Changes to support HTTP mode in Console Proxy, per 
http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
realhostip may go away

More details here : 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes


Diffs (updated)
-

  core/src/com/cloud/info/ConsoleProxyInfo.java 3439f3d 
  core/src/com/cloud/info/ConsoleProxyInfo.java 3439f3d 
  
engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
 a649bb7 
  
plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
 52cad3b 
  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 3572127 
  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 3572127 
  server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
a3f837b 
  setup/db/db/schema-421to430.sql 3811a5a 
  systemvm/conf/consoleproxy.properties bb452f5 

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


Testing
---

Tested on local environment by 
1. Using HTTP based console proxy
2. HTTPS with realhostip domain
3. HTTPS with custom domain and self-signed cert
4. Secondary storage template download with custom domain and self-signed cert


Thanks,

Amogh Vasekar

RE: Changing the SSL certificate for my own realhostip [HOWTO]

[Suresh Sadhu]

Thanks Nux for sharing the article 
and also found  below links useful to understand 
role of real host ip  and how to replace  with your own domain name:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Role+of+realhostip+in+CloudStack
,http://support.citrix.com/article/CTX133468

I have tested with self-signed  ssl certificate with my own local  domain 
name(replaced realhost with my domain by following steps mentioned in the  CTX 
support article) on my test setup..cpvm recreated  successfully  and console 
access with new domain name.

regards
sadhu

-Original Message-
From: Nux! [mailto:n...@li.nux.ro] 
Sent: 05 March 2014 23:12
To: dev@cloudstack.apache.org
Subject: Re: Changing the SSL certificate for my own realhostip [HOWTO]

Hi,


Wrote in a hurry a small article about how I got it done:
http://www.nux.ro/archive/2014/03/Run_your_own_realhostip.html

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

RE: 4.3 vote

[Animesh Chaturvedi]

John when was the dependency broken? Are you not able to build AWSAPI? 

> -Original Message-
> From: John Kinsella [mailto:j...@stratosec.co]
> Sent: Wednesday, March 05, 2014 11:00 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.3 vote
> 
> FYI I'm still -1 until CLOUDSTACK-6156 and
> https://reviews.apache.org/r/18392/ is addressed.
> 
> On Mar 5, 2014, at 10:10 AM, Animesh Chaturvedi
>  wrote:
> 
> >
> >
> >> -Original Message-
> >> From: sebgoa [mailto:run...@gmail.com]
> >> Sent: Wednesday, March 05, 2014 7:58 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: 4.3 vote
> >>
> >>
> >> On Mar 5, 2014, at 4:54 PM, Nux!  wrote:
> >>
> >>> On 05.03.2014 15:52, Animesh Chaturvedi wrote:
>  Working on it now, waiting on 1 last thing for realhostip changes
> >>>
> >>> So, does the realhostip "feature" disappear starting with 4.3?
> >>
> >> if that's the case we need to put this on the release notes. Happy to
> >> do so if someone send me the text..
> > [Animesh] It is really a convenience that we got used to not a
> > feature. You can specify your own domain name and change the
> > certificate even now with 4.2 and prior releases. The instructions are
> > in Admin Guide [1]
> >
> > Amogh has put a wiki on the changes at [2].
> >
> >
> > [1]
> > http://cloudstack.apache.org/docs/en-US//Apache_CloudStack/4.2.0/html/
> > Admin_Guide/console-proxy.html#change-console-proxy-ssl-certificate-do
> > main
> >
> > [2]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+chan
> ges
> >
> >
> >>
> >>>
> >>> Lucian
> >>>
> >>> --
> >>> Sent from the Delta quadrant using Borg technology!
> >>>
> >>> Nux!
> >>> www.nux.ro
> >

Re: Change Volume IOPS on fly without detaching the disk feature.

[Mike Tutkowski]

Exactly...and that shouldn't be too much of a problem.

The "trick" will come into play when we have to take into consideration
"generic" storage properties and that Min and Max IOPS should really be
part of this group.


On Wed, Mar 5, 2014 at 11:59 AM, Marcus  wrote:

> Yes, that's what I mean. When the offering is changed, we need to have
> a hook in there that calls the applicable storage driver for the
> volume. Then the drivers can be free to implement or not implement.
>
> On Wed, Mar 5, 2014 at 11:36 AM, Mike Tutkowski
>  wrote:
> > Hi Marcus,
> >
> > In 4.4 I'm adding the ability to allow admins to specify Min and Max IOPS
> > for Compute Offerings, as well (support only for XenServer in 4.4).
> >
> > I agree changing of IOPS should be doable through changing a Disk or
> Compute
> > Offering, but this doesn't work right now as the storage framework
> doesn't
> > tell the plug-in in question about the change.
> >
> > This is part of what Punith should investigate as we move forward with
> this
> > in 4.5.
> >
> > Talk to you later,
> > Mike
> >
> >
> > On Wed, Mar 5, 2014 at 11:12 AM, Marcus  wrote:
> >>
> >> Wouldn't this be implemented as just changing disk offerings? The
> >> resizeVolume API call already allows you to switch disk offerings, we
> >> just need to add a hook in there to optionally call the storage driver
> >> (If volume is deployed to a primary storage) to make an update to the
> >> iops properties on the backend storage. Come to think of it, depending
> >> on how storage drivers are implementing the iops/limits feature,
> >> resizeVolume might be breaking this, or simply requiring a reboot to
> >> apply. That is, if the storage driver is setting the iops just once
> >> upon volume creation, it's probably breaking when a user moves a disk
> >> between offerings that may have alternate iops limits (this is
> >> probably not the case for hypervisor throttling, as that's applied
> >> from whatever is current when the VM starts up).
> >>
> >> On Wed, Mar 5, 2014 at 9:58 AM, Mike Tutkowski
> >>  wrote:
> >> > Hi,
> >> >
> >> > Perhaps I'm not following this correctly, but I'm a bit lost on why we
> >> > are
> >> > talking about changing settings on running VMs.
> >> >
> >> > From what I understand, you are a representative of a storage vendor
> >> > that
> >> > has a rate-limiting feature. You want to be able to not only set the
> Max
> >> > IOPS, but also adjust them. Is this true?
> >> >
> >> > If so, I totally agree. SolidFire has control over Min and Max IOPS
> and
> >> > it
> >> > is on my to-do list to add support into CloudStack to be able to
> >> > dynamically change these values (right now customers do this from the
> >> > SolidFire API or its GUI).
> >> >
> >> > If you would like to work on this feature, that would be great. I'd be
> >> > happy to review your design and code.
> >> >
> >> > One complication is that we are looking at adding support for generic
> >> > key/value pairs for storage plug-ins in 4.5 and this would effectively
> >> > remove the need to have Min and Max IOPS as "special" fields in the
> >> > CloudStack API and GUI.
> >> >
> >> > I'm going to CC Chris Suichll (from NetApp) as he and I have already
> >> > discussed this generic-properties concept. It would be good to get his
> >> > feedback on how we might go about dynamically updating storage-plug-in
> >> > key/value pairs.
> >> >
> >> > Thanks!
> >> > Mike
> >> >
> >> >
> >> > On Wed, Mar 5, 2014 at 3:12 AM, Wido den Hollander 
> >> > wrote:
> >> >
> >> >>
> >> >>
> >> >> On 03/05/2014 10:12 AM, Wei ZHOU wrote:
> >> >>
> >> >>> I was thinking about it last week.
> >> >>> AFAIK, libvirt-java 0.5.1 does not support change setting on running
> >> >>> vms,
> >> >>> but virsh command line and libvirt API supports it.
> >> >>> so the sulution are
> >> >>> (1) change libvirt-java to support it, and make it released in the
> >> >>> next
> >> >>> version. Maybe Wido can help us.
> >> >>>
> >> >>
> >> >> Sure! That seems the best way forward. What is currently lacking in
> the
> >> >> libvirt-java bindings?
> >> >>
> >> >>
> >> >>  (2) call virsh command line.
> >> >>>
> >> >>>
> >> >> Please, please, do not do that. That's very hacky. We should really
> >> >> keep
> >> >> using the libvirt-java bindings and stay away from invoking binaries.
> >> >>
> >> >> Wido
> >> >>
> >> >>
> >> >>  -Wei
> >> >>>
> >> >>> 2014-03-05 9:01 GMT+01:00 Punith S :
> >> >>>
> >> >>>  hi guys,
> >> 
> >>  we are having a fixed max iops for each volume being attached to
> the
> >>  instance in managed storage,
> >>  so this a problem where we are making users to pre allocate the
> iops
> >>  of
> >>  the
> >>  disk without having an option to change or resize it, similar to
> the
> >>  size
> >>  metric.
> >> 
> >>  so i would like to introduce a new feature which enables to change
> or
> >>  resize the volume iops on fly without detaching the datadisk of the
> >>  VM
> >>  with

Re: 4.3 vote

[John Kinsella]

FYI I’m still -1 until CLOUDSTACK-6156 and https://reviews.apache.org/r/18392/ 
is addressed.

On Mar 5, 2014, at 10:10 AM, Animesh Chaturvedi  
wrote:

> 
> 
>> -Original Message-
>> From: sebgoa [mailto:run...@gmail.com]
>> Sent: Wednesday, March 05, 2014 7:58 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.3 vote
>> 
>> 
>> On Mar 5, 2014, at 4:54 PM, Nux!  wrote:
>> 
>>> On 05.03.2014 15:52, Animesh Chaturvedi wrote:
 Working on it now, waiting on 1 last thing for realhostip changes
>>> 
>>> So, does the realhostip "feature" disappear starting with 4.3?
>> 
>> if that's the case we need to put this on the release notes. Happy to do so 
>> if
>> someone send me the text..
> [Animesh] It is really a convenience that we got used to not a feature. You 
> can specify your own domain name and change the certificate even now with 4.2 
> and prior releases. The instructions are in Admin Guide [1]
> 
> Amogh has put a wiki on the changes at [2]. 
> 
> 
> [1] 
> http://cloudstack.apache.org/docs/en-US//Apache_CloudStack/4.2.0/html/Admin_Guide/console-proxy.html#change-console-proxy-ssl-certificate-domain
> 
> [2] 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes
> 
> 
> 
>> 
>>> 
>>> Lucian
>>> 
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> 
>>> Nux!
>>> www.nux.ro
> 

Re: Change Volume IOPS on fly without detaching the disk feature.

[Marcus]

Yes, that's what I mean. When the offering is changed, we need to have
a hook in there that calls the applicable storage driver for the
volume. Then the drivers can be free to implement or not implement.

On Wed, Mar 5, 2014 at 11:36 AM, Mike Tutkowski
 wrote:
> Hi Marcus,
>
> In 4.4 I'm adding the ability to allow admins to specify Min and Max IOPS
> for Compute Offerings, as well (support only for XenServer in 4.4).
>
> I agree changing of IOPS should be doable through changing a Disk or Compute
> Offering, but this doesn't work right now as the storage framework doesn't
> tell the plug-in in question about the change.
>
> This is part of what Punith should investigate as we move forward with this
> in 4.5.
>
> Talk to you later,
> Mike
>
>
> On Wed, Mar 5, 2014 at 11:12 AM, Marcus  wrote:
>>
>> Wouldn't this be implemented as just changing disk offerings? The
>> resizeVolume API call already allows you to switch disk offerings, we
>> just need to add a hook in there to optionally call the storage driver
>> (If volume is deployed to a primary storage) to make an update to the
>> iops properties on the backend storage. Come to think of it, depending
>> on how storage drivers are implementing the iops/limits feature,
>> resizeVolume might be breaking this, or simply requiring a reboot to
>> apply. That is, if the storage driver is setting the iops just once
>> upon volume creation, it's probably breaking when a user moves a disk
>> between offerings that may have alternate iops limits (this is
>> probably not the case for hypervisor throttling, as that's applied
>> from whatever is current when the VM starts up).
>>
>> On Wed, Mar 5, 2014 at 9:58 AM, Mike Tutkowski
>>  wrote:
>> > Hi,
>> >
>> > Perhaps I'm not following this correctly, but I'm a bit lost on why we
>> > are
>> > talking about changing settings on running VMs.
>> >
>> > From what I understand, you are a representative of a storage vendor
>> > that
>> > has a rate-limiting feature. You want to be able to not only set the Max
>> > IOPS, but also adjust them. Is this true?
>> >
>> > If so, I totally agree. SolidFire has control over Min and Max IOPS and
>> > it
>> > is on my to-do list to add support into CloudStack to be able to
>> > dynamically change these values (right now customers do this from the
>> > SolidFire API or its GUI).
>> >
>> > If you would like to work on this feature, that would be great. I'd be
>> > happy to review your design and code.
>> >
>> > One complication is that we are looking at adding support for generic
>> > key/value pairs for storage plug-ins in 4.5 and this would effectively
>> > remove the need to have Min and Max IOPS as "special" fields in the
>> > CloudStack API and GUI.
>> >
>> > I'm going to CC Chris Suichll (from NetApp) as he and I have already
>> > discussed this generic-properties concept. It would be good to get his
>> > feedback on how we might go about dynamically updating storage-plug-in
>> > key/value pairs.
>> >
>> > Thanks!
>> > Mike
>> >
>> >
>> > On Wed, Mar 5, 2014 at 3:12 AM, Wido den Hollander 
>> > wrote:
>> >
>> >>
>> >>
>> >> On 03/05/2014 10:12 AM, Wei ZHOU wrote:
>> >>
>> >>> I was thinking about it last week.
>> >>> AFAIK, libvirt-java 0.5.1 does not support change setting on running
>> >>> vms,
>> >>> but virsh command line and libvirt API supports it.
>> >>> so the sulution are
>> >>> (1) change libvirt-java to support it, and make it released in the
>> >>> next
>> >>> version. Maybe Wido can help us.
>> >>>
>> >>
>> >> Sure! That seems the best way forward. What is currently lacking in the
>> >> libvirt-java bindings?
>> >>
>> >>
>> >>  (2) call virsh command line.
>> >>>
>> >>>
>> >> Please, please, do not do that. That's very hacky. We should really
>> >> keep
>> >> using the libvirt-java bindings and stay away from invoking binaries.
>> >>
>> >> Wido
>> >>
>> >>
>> >>  -Wei
>> >>>
>> >>> 2014-03-05 9:01 GMT+01:00 Punith S :
>> >>>
>> >>>  hi guys,
>> 
>>  we are having a fixed max iops for each volume being attached to the
>>  instance in managed storage,
>>  so this a problem where we are making users to pre allocate the iops
>>  of
>>  the
>>  disk without having an option to change or resize it, similar to the
>>  size
>>  metric.
>> 
>>  so i would like to introduce a new feature which enables to change or
>>  resize the volume iops on fly without detaching the datadisk of the
>>  VM
>>  with
>>  zero downtime where performance of the datadisk can be altered at any
>>  point
>>  with the available iops of the primary storage pool, which is similar
>>  in
>>  resizing the volume or datadisk of the vm , where in latter we have
>>  to
>>  detach the datadisk.
>> 
>>  what do you guys think about this feature ? any feedback ?
>> 
>>  thanks,
>> 
>>  --
>>  regards,
>> 
>>  punith s
>>  cloudbyte.com
>> 
>> 
>> >>>
>> >
>> >
>> > --
>> > *Mike Tutk

Re: Review Request 18759: HTTP support for console proxy and making it default

[Amogh Vasekar]

> On March 5, 2014, 7:43 a.m., John Kinsella wrote:
> > server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java, line 1719
> > 
> >
> > This doesn't seem relevant to the issue at hand.

Ditto


- Amogh


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


On March 5, 2014, 1:42 a.m., Amogh Vasekar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18759/
> ---
> 
> (Updated March 5, 2014, 1:42 a.m.)
> 
> 
> Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes to support HTTP mode in Console Proxy, per 
> http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
> realhostip may go away
> 
> More details here : 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/info/ConsoleProxyInfo.java 3439f3d 
>   
> engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
>  a649bb7 
>   
> plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
>  52cad3b 
>   server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 3572127 
>   server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
> a3f837b 
>   systemvm/conf/consoleproxy.properties bb452f5 
> 
> Diff: https://reviews.apache.org/r/18759/diff/
> 
> 
> Testing
> ---
> 
> Tested on local environment by 
> 1. Using HTTP based console proxy
> 2. HTTPS with realhostip domain
> 3. HTTPS with custom domain and self-signed cert
> 4. Secondary storage template download with custom domain and self-signed cert
> 
> 
> Thanks,
> 
> Amogh Vasekar
> 
>

Re: Review Request 18759: HTTP support for console proxy and making it default

[Amogh Vasekar]

> On March 5, 2014, 7:43 a.m., John Kinsella wrote:
> > core/src/com/cloud/info/ConsoleProxyInfo.java, line 45
> > 
> >
> > Can you clean up trailing whitespace added in lines like this?

Will do. IDE issues :(


> On March 5, 2014, 7:43 a.m., John Kinsella wrote:
> > systemvm/conf/consoleproxy.properties, line 19
> > 
> >
> > Why change the listening port? I don't see what this has to do with 
> > moving from HTTPS to HTTP...

The issue arises in code base, where are the some parts where the port of 
console proxy listening service is hard coded to 80 / 443 based on HTTP / HTTPS.
8088 existed for legacy reasons - the developer had used it for local testing 
and it stayed put.


- Amogh


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


On March 5, 2014, 1:42 a.m., Amogh Vasekar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18759/
> ---
> 
> (Updated March 5, 2014, 1:42 a.m.)
> 
> 
> Review request for cloudstack, Demetrius Tsitrelis and John Kinsella.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes to support HTTP mode in Console Proxy, per 
> http://www.mail-archive.com/dev@cloudstack.apache.org/msg24151.html , as 
> realhostip may go away
> 
> More details here : 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/info/ConsoleProxyInfo.java 3439f3d 
>   
> engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java
>  a649bb7 
>   
> plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
>  52cad3b 
>   server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 3572127 
>   server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
> a3f837b 
>   systemvm/conf/consoleproxy.properties bb452f5 
> 
> Diff: https://reviews.apache.org/r/18759/diff/
> 
> 
> Testing
> ---
> 
> Tested on local environment by 
> 1. Using HTTP based console proxy
> 2. HTTPS with realhostip domain
> 3. HTTPS with custom domain and self-signed cert
> 4. Secondary storage template download with custom domain and self-signed cert
> 
> 
> Thanks,
> 
> Amogh Vasekar
> 
>

Re: Change Volume IOPS on fly without detaching the disk feature.

[Mike Tutkowski]

Hi Marcus,

In 4.4 I'm adding the ability to allow admins to specify Min and Max IOPS
for Compute Offerings, as well (support only for XenServer in 4.4).

I agree changing of IOPS should be doable through changing a Disk or
Compute Offering, but this doesn't work right now as the storage framework
doesn't tell the plug-in in question about the change.

This is part of what Punith should investigate as we move forward with this
in 4.5.

Talk to you later,
Mike


On Wed, Mar 5, 2014 at 11:12 AM, Marcus  wrote:

> Wouldn't this be implemented as just changing disk offerings? The
> resizeVolume API call already allows you to switch disk offerings, we
> just need to add a hook in there to optionally call the storage driver
> (If volume is deployed to a primary storage) to make an update to the
> iops properties on the backend storage. Come to think of it, depending
> on how storage drivers are implementing the iops/limits feature,
> resizeVolume might be breaking this, or simply requiring a reboot to
> apply. That is, if the storage driver is setting the iops just once
> upon volume creation, it's probably breaking when a user moves a disk
> between offerings that may have alternate iops limits (this is
> probably not the case for hypervisor throttling, as that's applied
> from whatever is current when the VM starts up).
>
> On Wed, Mar 5, 2014 at 9:58 AM, Mike Tutkowski
>  wrote:
> > Hi,
> >
> > Perhaps I'm not following this correctly, but I'm a bit lost on why we
> are
> > talking about changing settings on running VMs.
> >
> > From what I understand, you are a representative of a storage vendor that
> > has a rate-limiting feature. You want to be able to not only set the Max
> > IOPS, but also adjust them. Is this true?
> >
> > If so, I totally agree. SolidFire has control over Min and Max IOPS and
> it
> > is on my to-do list to add support into CloudStack to be able to
> > dynamically change these values (right now customers do this from the
> > SolidFire API or its GUI).
> >
> > If you would like to work on this feature, that would be great. I'd be
> > happy to review your design and code.
> >
> > One complication is that we are looking at adding support for generic
> > key/value pairs for storage plug-ins in 4.5 and this would effectively
> > remove the need to have Min and Max IOPS as "special" fields in the
> > CloudStack API and GUI.
> >
> > I'm going to CC Chris Suichll (from NetApp) as he and I have already
> > discussed this generic-properties concept. It would be good to get his
> > feedback on how we might go about dynamically updating storage-plug-in
> > key/value pairs.
> >
> > Thanks!
> > Mike
> >
> >
> > On Wed, Mar 5, 2014 at 3:12 AM, Wido den Hollander 
> wrote:
> >
> >>
> >>
> >> On 03/05/2014 10:12 AM, Wei ZHOU wrote:
> >>
> >>> I was thinking about it last week.
> >>> AFAIK, libvirt-java 0.5.1 does not support change setting on running
> vms,
> >>> but virsh command line and libvirt API supports it.
> >>> so the sulution are
> >>> (1) change libvirt-java to support it, and make it released in the next
> >>> version. Maybe Wido can help us.
> >>>
> >>
> >> Sure! That seems the best way forward. What is currently lacking in the
> >> libvirt-java bindings?
> >>
> >>
> >>  (2) call virsh command line.
> >>>
> >>>
> >> Please, please, do not do that. That's very hacky. We should really keep
> >> using the libvirt-java bindings and stay away from invoking binaries.
> >>
> >> Wido
> >>
> >>
> >>  -Wei
> >>>
> >>> 2014-03-05 9:01 GMT+01:00 Punith S :
> >>>
> >>>  hi guys,
> 
>  we are having a fixed max iops for each volume being attached to the
>  instance in managed storage,
>  so this a problem where we are making users to pre allocate the iops
> of
>  the
>  disk without having an option to change or resize it, similar to the
> size
>  metric.
> 
>  so i would like to introduce a new feature which enables to change or
>  resize the volume iops on fly without detaching the datadisk of the VM
>  with
>  zero downtime where performance of the datadisk can be altered at any
>  point
>  with the available iops of the primary storage pool, which is similar
> in
>  resizing the volume or datadisk of the vm , where in latter we have to
>  detach the datadisk.
> 
>  what do you guys think about this feature ? any feedback ?
> 
>  thanks,
> 
>  --
>  regards,
> 
>  punith s
>  cloudbyte.com
> 
> 
> >>>
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*
>



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

RE: OVS plugin in CloudStack 4.3.0

[Animesh Chaturvedi]

From: ng.t...@gmail.com [mailto:ng.t...@gmail.com] On Behalf Of Nguyen Anh Tu
Sent: Wednesday, March 05, 2014 6:26 AM
To: dev@cloudstack.apache.org
Cc: Florin Dumitrascu; Animesh Chaturvedi; Murali Reddy
Subject: Re: OVS plugin in CloudStack 4.3.0


On Wed, Mar 5, 2014 at 6:52 PM, sebgoa 
mailto:run...@gmail.com>> wrote:
Tuna, make sure that all your code and fixes is in Master. That way it will be 
in 4.4
[Animesh] And that it is a big change please revert it from 4.3-forward, it 
should not get accicdently pulled into 4.3 maintenance release

Got it. Thanks Sebastien!

--Tuna

Re: Change Volume IOPS on fly without detaching the disk feature.

[Marcus]

For the hypervisor version of throttling, we just need
ResizeVolumeCommand to pass the VolumeObjectTO rather than just the
volume uuid/path, so that when we change offerings on the agent side
we have the info we need to update libvirt with the new iops/bytes
settings. We also need the libvirt java bindings to do so, per
previous discussion.

On Wed, Mar 5, 2014 at 11:12 AM, Marcus  wrote:
> Wouldn't this be implemented as just changing disk offerings? The
> resizeVolume API call already allows you to switch disk offerings, we
> just need to add a hook in there to optionally call the storage driver
> (If volume is deployed to a primary storage) to make an update to the
> iops properties on the backend storage. Come to think of it, depending
> on how storage drivers are implementing the iops/limits feature,
> resizeVolume might be breaking this, or simply requiring a reboot to
> apply. That is, if the storage driver is setting the iops just once
> upon volume creation, it's probably breaking when a user moves a disk
> between offerings that may have alternate iops limits (this is
> probably not the case for hypervisor throttling, as that's applied
> from whatever is current when the VM starts up).
>
> On Wed, Mar 5, 2014 at 9:58 AM, Mike Tutkowski
>  wrote:
>> Hi,
>>
>> Perhaps I'm not following this correctly, but I'm a bit lost on why we are
>> talking about changing settings on running VMs.
>>
>> From what I understand, you are a representative of a storage vendor that
>> has a rate-limiting feature. You want to be able to not only set the Max
>> IOPS, but also adjust them. Is this true?
>>
>> If so, I totally agree. SolidFire has control over Min and Max IOPS and it
>> is on my to-do list to add support into CloudStack to be able to
>> dynamically change these values (right now customers do this from the
>> SolidFire API or its GUI).
>>
>> If you would like to work on this feature, that would be great. I'd be
>> happy to review your design and code.
>>
>> One complication is that we are looking at adding support for generic
>> key/value pairs for storage plug-ins in 4.5 and this would effectively
>> remove the need to have Min and Max IOPS as "special" fields in the
>> CloudStack API and GUI.
>>
>> I'm going to CC Chris Suichll (from NetApp) as he and I have already
>> discussed this generic-properties concept. It would be good to get his
>> feedback on how we might go about dynamically updating storage-plug-in
>> key/value pairs.
>>
>> Thanks!
>> Mike
>>
>>
>> On Wed, Mar 5, 2014 at 3:12 AM, Wido den Hollander  wrote:
>>
>>>
>>>
>>> On 03/05/2014 10:12 AM, Wei ZHOU wrote:
>>>
 I was thinking about it last week.
 AFAIK, libvirt-java 0.5.1 does not support change setting on running vms,
 but virsh command line and libvirt API supports it.
 so the sulution are
 (1) change libvirt-java to support it, and make it released in the next
 version. Maybe Wido can help us.

>>>
>>> Sure! That seems the best way forward. What is currently lacking in the
>>> libvirt-java bindings?
>>>
>>>
>>>  (2) call virsh command line.


>>> Please, please, do not do that. That's very hacky. We should really keep
>>> using the libvirt-java bindings and stay away from invoking binaries.
>>>
>>> Wido
>>>
>>>
>>>  -Wei

 2014-03-05 9:01 GMT+01:00 Punith S :

  hi guys,
>
> we are having a fixed max iops for each volume being attached to the
> instance in managed storage,
> so this a problem where we are making users to pre allocate the iops of
> the
> disk without having an option to change or resize it, similar to the size
> metric.
>
> so i would like to introduce a new feature which enables to change or
> resize the volume iops on fly without detaching the datadisk of the VM
> with
> zero downtime where performance of the datadisk can be altered at any
> point
> with the available iops of the primary storage pool, which is similar in
> resizing the volume or datadisk of the vm , where in latter we have to
> detach the datadisk.
>
> what do you guys think about this feature ? any feedback ?
>
> thanks,
>
> --
> regards,
>
> punith s
> cloudbyte.com
>
>

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

Re: Change Volume IOPS on fly without detaching the disk feature.

[Marcus]

Wouldn't this be implemented as just changing disk offerings? The
resizeVolume API call already allows you to switch disk offerings, we
just need to add a hook in there to optionally call the storage driver
(If volume is deployed to a primary storage) to make an update to the
iops properties on the backend storage. Come to think of it, depending
on how storage drivers are implementing the iops/limits feature,
resizeVolume might be breaking this, or simply requiring a reboot to
apply. That is, if the storage driver is setting the iops just once
upon volume creation, it's probably breaking when a user moves a disk
between offerings that may have alternate iops limits (this is
probably not the case for hypervisor throttling, as that's applied
from whatever is current when the VM starts up).

On Wed, Mar 5, 2014 at 9:58 AM, Mike Tutkowski
 wrote:
> Hi,
>
> Perhaps I'm not following this correctly, but I'm a bit lost on why we are
> talking about changing settings on running VMs.
>
> From what I understand, you are a representative of a storage vendor that
> has a rate-limiting feature. You want to be able to not only set the Max
> IOPS, but also adjust them. Is this true?
>
> If so, I totally agree. SolidFire has control over Min and Max IOPS and it
> is on my to-do list to add support into CloudStack to be able to
> dynamically change these values (right now customers do this from the
> SolidFire API or its GUI).
>
> If you would like to work on this feature, that would be great. I'd be
> happy to review your design and code.
>
> One complication is that we are looking at adding support for generic
> key/value pairs for storage plug-ins in 4.5 and this would effectively
> remove the need to have Min and Max IOPS as "special" fields in the
> CloudStack API and GUI.
>
> I'm going to CC Chris Suichll (from NetApp) as he and I have already
> discussed this generic-properties concept. It would be good to get his
> feedback on how we might go about dynamically updating storage-plug-in
> key/value pairs.
>
> Thanks!
> Mike
>
>
> On Wed, Mar 5, 2014 at 3:12 AM, Wido den Hollander  wrote:
>
>>
>>
>> On 03/05/2014 10:12 AM, Wei ZHOU wrote:
>>
>>> I was thinking about it last week.
>>> AFAIK, libvirt-java 0.5.1 does not support change setting on running vms,
>>> but virsh command line and libvirt API supports it.
>>> so the sulution are
>>> (1) change libvirt-java to support it, and make it released in the next
>>> version. Maybe Wido can help us.
>>>
>>
>> Sure! That seems the best way forward. What is currently lacking in the
>> libvirt-java bindings?
>>
>>
>>  (2) call virsh command line.
>>>
>>>
>> Please, please, do not do that. That's very hacky. We should really keep
>> using the libvirt-java bindings and stay away from invoking binaries.
>>
>> Wido
>>
>>
>>  -Wei
>>>
>>> 2014-03-05 9:01 GMT+01:00 Punith S :
>>>
>>>  hi guys,

 we are having a fixed max iops for each volume being attached to the
 instance in managed storage,
 so this a problem where we are making users to pre allocate the iops of
 the
 disk without having an option to change or resize it, similar to the size
 metric.

 so i would like to introduce a new feature which enables to change or
 resize the volume iops on fly without detaching the datadisk of the VM
 with
 zero downtime where performance of the datadisk can be altered at any
 point
 with the available iops of the primary storage pool, which is similar in
 resizing the volume or datadisk of the vm , where in latter we have to
 detach the datadisk.

 what do you guys think about this feature ? any feedback ?

 thanks,

 --
 regards,

 punith s
 cloudbyte.com


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

RE: 4.3 vote

[Animesh Chaturvedi]

> -Original Message-
> From: sebgoa [mailto:run...@gmail.com]
> Sent: Wednesday, March 05, 2014 7:58 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.3 vote
> 
> 
> On Mar 5, 2014, at 4:54 PM, Nux!  wrote:
> 
> > On 05.03.2014 15:52, Animesh Chaturvedi wrote:
> >> Working on it now, waiting on 1 last thing for realhostip changes
> >
> > So, does the realhostip "feature" disappear starting with 4.3?
> 
> if that's the case we need to put this on the release notes. Happy to do so if
> someone send me the text..
[Animesh] It is really a convenience that we got used to not a feature. You can 
specify your own domain name and change the certificate even now with 4.2 and 
prior releases. The instructions are in Admin Guide [1]

Amogh has put a wiki on the changes at [2]. 


[1] 
http://cloudstack.apache.org/docs/en-US//Apache_CloudStack/4.2.0/html/Admin_Guide/console-proxy.html#change-console-proxy-ssl-certificate-domain

[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes  


> 
> >
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro

Re: [DISCUSS] realhostip.com going away

[John Kinsella]

It’s not.

On Mar 5, 2014, at 1:48 AM, Erik Weber 
mailto:terbol...@gmail.com>> wrote:

How is security being handled in HTTP mode?


--
Erik


On Wed, Mar 5, 2014 at 2:43 AM, Amogh Vasekar 
mailto:amogh.vase...@citrix.com>>wrote:

Hello,

I have created a review request at : https://reviews.apache.org/r/18759/
that partially address the issue. It has a link to the wiki describing the
changes in detail.

Thanks,
Amogh

On 3/3/14 8:58 AM, "John Kinsella" 
mailto:j...@stratosec.co>> wrote:

I talked with some of the Citrix folk over the weekendŠtheir position is
they think they¹d be doing the community a disfavor by passing the torch,
so-to-speak, and I agree with them [1].

>From what I understand, the patches that are going to be proposed will
remove HTTPS completely and encrypt over http. That said, I haven¹t seen
anything yet, so until we see something we¹re guessing. I¹m waiting a few
more days to see what¹s proposed.

John
1: I¹m sharing conversations with individuals, so take this as hearsay
not official comment from Citrix.

On Mar 2, 2014, at 8:15 AM, Paul Angus
mailto:paul.an...@shapeblue.com>>
 wrote:

There are a few issues with the current console proxy setup, not least of
which is the need to have internet access to resolve
realhostip.com in the first place 
- so console
proxy can't work if you don't have internet access on your client.  I
have configured alternative 
realhostip.com setups
for clients - and quite a lot of work goes into creating the
infrastructure (and certs) to support changing to a user managed
certificate.

Sooo, is it at all possible to secure communications with the console
proxy, without having to rely on ANY outside entity?

Testing alone is going to be a pain, if a full ssl cert setup is required
to use console proxy..

Regards

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
paul.an...@shapeblue.com

-Original Message-
From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
Sent: 28 February 2014 23:05
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] realhostip.com going away



On 2/28/14 2:03 PM, "Nux!" mailto:n...@li.nux.ro>> wrote:

There's also the problem of the certificate. It comes bundled in ACS as
far as I can tell.. When does it expire?

notBefore=Feb  3 03:30:40 2012 GMT
notAfter=Feb  7 05:11:23 2017 GMT

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure
Support offers
the best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1
training
18th-19th February 2014, Brazil.
Classroom
17th-23rd March 2014, Region A. Instructor led,
On-line
24th-28th March 2014, Region B. Instructor led,
On-line
16th-20th June 2014, Region A. Instructor led,
On-line
23rd-27th June 2014, Region B. Instructor led,
On-line

This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views
or opinions expressed are solely those of the author and do not
necessarily represent those of Shape Blue Ltd or related companies. If
you are not the intended recipient of this email, you must neither take
any action based upon its contents, nor copy or show it to anyone. Please
contact the sender if you believe you have received this email in error.
Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
Services India LLP is a company incorporated in India and is operated
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
a company incorporated in Brasil and is operated under license from Shape
Blue Ltd. ShapeBlue is a registered trademark.

Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella




Stratosec - Compliance as a Service
o: 415.315.9385
@johnlkinsella

Re: Changing the SSL certificate for my own realhostip [HOWTO]

[Nux!]

Hi,


Wrote in a hurry a small article about how I got it done:
http://www.nux.ro/archive/2014/03/Run_your_own_realhostip.html

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: JRE 1.7

[Laszlo Hornyak]

Hi,

Now the default java source and target are both 1.7. If you update the
configuration of the imported projects, eclipse should pick up the change
and use java 1.7. Unfortunately it does not do that by default after a git
rebase. But you should check that your default JDK in eclipse is 1.7


On Wed, Mar 5, 2014 at 6:23 PM, Alex Hitchins
wrote:

> Hi all,
>
> Just wanted to double check something. I'm getting a lot of errors in
> Eclipse saying that <> operator isn't allowed for source level below 1.7.
>
> Am I ok to change the compliance and JRE to 1.7?
>
> I have seen some discussion around changing of the JRE, I just want to
> make sure!
>
>
> Regards,
>
> Alex Hitchins
> VP Software Engineering
>
> D: +44 1892 523 587 | S: +44 20 3603 0540 | M: +44 +447968161581> 7788 423 969
>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/> offers the best
> 24/7 SLA for CloudStack Environments.
>
> Apache CloudStack Bootcamp training courses
>
> **NEW!** CloudStack 4.2.1 training<
> http://shapeblue.com/cloudstack-training/>
> 18th-19th February 2014, Brazil. Classroom<
> http://shapeblue.com/cloudstack-training/>
> 17th-23rd March 2014, Region A. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 24th-28th March 2014, Region B. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 16th-20th June 2014, Region A. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 23rd-27th June 2014, Region B. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue is a
> registered trademark.
>



-- 

EOF

JRE 1.7

[Alex Hitchins]

Hi all,

Just wanted to double check something. I'm getting a lot of errors in Eclipse 
saying that <> operator isn't allowed for source level below 1.7.

Am I ok to change the compliance and JRE to 1.7?

I have seen some discussion around changing of the JRE, I just want to make 
sure!


Regards,

Alex Hitchins
VP Software Engineering

D: +44 1892 523 587 | S: +44 20 3603 0540 | M: 
+44 7788 423 969

ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line
24th-28th March 2014, Region B. Instructor led, 
On-line
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Change Volume IOPS on fly without detaching the disk feature.

[chantel_piorecki]

Sent via my BlackBerry from Vodacom - let your email find you!

Re: [TRANSLATION] Update on new doc format

[sebgoa]

yes:
https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs-rn.git

but I am still trying to figure out the proper way to use sphinx-intl with 
transifex, it's not working properly right now

I uploaded the pot files by hand

I looked at the japanese pages and I think the reason why we don't see any 
suggestions in the strings is because we were not translating the release notes 
before.

On Mar 5, 2014, at 6:09 PM, Go Chiba  wrote:

> Hi, do you already have a git repository of "Release Notes"?
> for doc contributor.
> 
> Go Chiba
> E-mail:go.ch...@gmail.com
> 
> 
> On Thu, Mar 6, 2014 at 1:30 AM, sebgoa  wrote:
> 
>> Hi translators,
>> 
>> It's been a while since we had an update on the translation work.
>> I am happy to say that 82 people have contributed translations to the
>> cloudstack documentation.
>> 
>> Since we had an update, the transifex site has changed quite a bit, so if
>> you have not looked at it lately, please do.
>> 
>> The big item that we have coming is a change of format for the
>> documentation.
>> 
>> As you know publican was using docbook xml format, this worked well for
>> translation but building and serving these translated docs on the web was a
>> bit of a pain.
>> 
>> On the dev list we have discussed changing the doc format to restructured
>> text (a simple markdown like format), and using read the docs (
>> https://readthedocs.org) to build and host the documentation [1]. For
>> example see [2].
>> 
>> Note that this is still a work in progress and anyone is welcome to
>> contribute, all the docs repo are now mirrored on github and we can accept
>> pull requests.
>> 
>> This move is going to mean some changes for translations:
>> 
>> We are still using transifex, but we will now use sphinx-intl [3] to
>> manage the pot and po files . All resource files (.pot) will be updated to
>> transifex in new projects since the restructured text format will generate
>> new strings.
>> 
>> I am still working on this, but I am hoping we can re-use all strings
>> already translated and migrate them to the new project. I am just not sure
>> yet how this is going to work out, so I wanted to inform everyone and ask
>> for help and eyes on this.
>> 
>> To get started I setup a new transifex project for the release notes [4]
>> 
>> I would like to ask folks who have already submitted translation to look
>> at this new project and see how they can access already translated strings
>> and migrate them over to this new project.
>> 
>> The end result in RTD will be a much better experience for localization
>> and better browser support.
>> 
>> Thanks for your help on this, I know it's going to be a challenge,
>> 
>> Cheers,
>> 
>> [1] http://markmail.org/thread/r5sun6m6qyabmffy
>> [2] http://markmail.org/thread/m235qyxsswhag47i
>> [3] http://sphinx-doc.org/latest/intl.html
>> [4]
>> https://www.transifex.com/projects/p/apache-cloudstack-release-notes-rtd/
>> 
>> -Sebastien
>> 

Re: [TRANSLATION] Update on new doc format

[Go Chiba]

Hi, do you already have a git repository of "Release Notes"?
for doc contributor.

Go Chiba
E-mail:go.ch...@gmail.com


On Thu, Mar 6, 2014 at 1:30 AM, sebgoa  wrote:

> Hi translators,
>
> It's been a while since we had an update on the translation work.
> I am happy to say that 82 people have contributed translations to the
> cloudstack documentation.
>
> Since we had an update, the transifex site has changed quite a bit, so if
> you have not looked at it lately, please do.
>
> The big item that we have coming is a change of format for the
> documentation.
>
> As you know publican was using docbook xml format, this worked well for
> translation but building and serving these translated docs on the web was a
> bit of a pain.
>
> On the dev list we have discussed changing the doc format to restructured
> text (a simple markdown like format), and using read the docs (
> https://readthedocs.org) to build and host the documentation [1]. For
> example see [2].
>
> Note that this is still a work in progress and anyone is welcome to
> contribute, all the docs repo are now mirrored on github and we can accept
> pull requests.
>
> This move is going to mean some changes for translations:
>
> We are still using transifex, but we will now use sphinx-intl [3] to
> manage the pot and po files . All resource files (.pot) will be updated to
> transifex in new projects since the restructured text format will generate
> new strings.
>
> I am still working on this, but I am hoping we can re-use all strings
> already translated and migrate them to the new project. I am just not sure
> yet how this is going to work out, so I wanted to inform everyone and ask
> for help and eyes on this.
>
> To get started I setup a new transifex project for the release notes [4]
>
> I would like to ask folks who have already submitted translation to look
> at this new project and see how they can access already translated strings
> and migrate them over to this new project.
>
> The end result in RTD will be a much better experience for localization
> and better browser support.
>
> Thanks for your help on this, I know it's going to be a challenge,
>
> Cheers,
>
> [1] http://markmail.org/thread/r5sun6m6qyabmffy
> [2] http://markmail.org/thread/m235qyxsswhag47i
> [3] http://sphinx-doc.org/latest/intl.html
> [4]
> https://www.transifex.com/projects/p/apache-cloudstack-release-notes-rtd/
>
> -Sebastien
>

Re: Change Volume IOPS on fly without detaching the disk feature.

[Mike Tutkowski]

Hi,

Perhaps I'm not following this correctly, but I'm a bit lost on why we are
talking about changing settings on running VMs.

>From what I understand, you are a representative of a storage vendor that
has a rate-limiting feature. You want to be able to not only set the Max
IOPS, but also adjust them. Is this true?

If so, I totally agree. SolidFire has control over Min and Max IOPS and it
is on my to-do list to add support into CloudStack to be able to
dynamically change these values (right now customers do this from the
SolidFire API or its GUI).

If you would like to work on this feature, that would be great. I'd be
happy to review your design and code.

One complication is that we are looking at adding support for generic
key/value pairs for storage plug-ins in 4.5 and this would effectively
remove the need to have Min and Max IOPS as "special" fields in the
CloudStack API and GUI.

I'm going to CC Chris Suichll (from NetApp) as he and I have already
discussed this generic-properties concept. It would be good to get his
feedback on how we might go about dynamically updating storage-plug-in
key/value pairs.

Thanks!
Mike


On Wed, Mar 5, 2014 at 3:12 AM, Wido den Hollander  wrote:

>
>
> On 03/05/2014 10:12 AM, Wei ZHOU wrote:
>
>> I was thinking about it last week.
>> AFAIK, libvirt-java 0.5.1 does not support change setting on running vms,
>> but virsh command line and libvirt API supports it.
>> so the sulution are
>> (1) change libvirt-java to support it, and make it released in the next
>> version. Maybe Wido can help us.
>>
>
> Sure! That seems the best way forward. What is currently lacking in the
> libvirt-java bindings?
>
>
>  (2) call virsh command line.
>>
>>
> Please, please, do not do that. That's very hacky. We should really keep
> using the libvirt-java bindings and stay away from invoking binaries.
>
> Wido
>
>
>  -Wei
>>
>> 2014-03-05 9:01 GMT+01:00 Punith S :
>>
>>  hi guys,
>>>
>>> we are having a fixed max iops for each volume being attached to the
>>> instance in managed storage,
>>> so this a problem where we are making users to pre allocate the iops of
>>> the
>>> disk without having an option to change or resize it, similar to the size
>>> metric.
>>>
>>> so i would like to introduce a new feature which enables to change or
>>> resize the volume iops on fly without detaching the datadisk of the VM
>>> with
>>> zero downtime where performance of the datadisk can be altered at any
>>> point
>>> with the available iops of the primary storage pool, which is similar in
>>> resizing the volume or datadisk of the vm , where in latter we have to
>>> detach the datadisk.
>>>
>>> what do you guys think about this feature ? any feedback ?
>>>
>>> thanks,
>>>
>>> --
>>> regards,
>>>
>>> punith s
>>> cloudbyte.com
>>>
>>>
>>


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

[TRANSLATION] Update on new doc format

[sebgoa]

Hi translators,

It's been a while since we had an update on the translation work.
I am happy to say that 82 people have contributed translations to the 
cloudstack documentation.

Since we had an update, the transifex site has changed quite a bit, so if you 
have not looked at it lately, please do.

The big item that we have coming is a change of format for the documentation.

As you know publican was using docbook xml format, this worked well for 
translation but building and serving these translated docs on the web was a bit 
of a pain.

On the dev list we have discussed changing the doc format to restructured text 
(a simple markdown like format), and using read the docs 
(https://readthedocs.org) to build and host the documentation [1]. For example 
see [2]. 

Note that this is still a work in progress and anyone is welcome to contribute, 
all the docs repo are now mirrored on github and we can accept pull requests.

This move is going to mean some changes for translations:

We are still using transifex, but we will now use sphinx-intl [3] to manage the 
pot and po files . All resource files (.pot) will be updated to transifex in 
new projects since the restructured text format will generate new strings.

I am still working on this, but I am hoping we can re-use all strings already 
translated and migrate them to the new project. I am just not sure yet how this 
is going to work out, so I wanted to inform everyone and ask for help and eyes 
on this.

To get started I setup a new transifex project for the release notes [4]

I would like to ask folks who have already submitted translation to look at 
this new project and see how they can access already translated strings and 
migrate them over to this new project.

The end result in RTD will be a much better experience for localization and 
better browser support.

Thanks for your help on this, I know it's going to be a challenge,

Cheers,

[1] http://markmail.org/thread/r5sun6m6qyabmffy
[2] http://markmail.org/thread/m235qyxsswhag47i 
[3] http://sphinx-doc.org/latest/intl.html
[4] https://www.transifex.com/projects/p/apache-cloudstack-release-notes-rtd/

-Sebastien

A word about cloudy stuff at ApacheCon

[David Nalley]

Hello mah cloudies,

Just a reminder that in addition to CloudStack Collab Conference (Apr
9-11), ApacheCon is happening immediately prior to it at the same
location (Apr 7-9) and there is a dedicated cloud track with talks
from a number of the cloudy Apache talks, as well as a number of other
interesting things (10 tracks of Apache-content per day)

Take a look at the schedule here:
http://apacheconnorthamerica2014.sched.org/overview#.UxdPsEJ5r-Y

So please join us for CCC and arrive a couple of days early to see ApacheCon.

--David

Re: 4.3 vote

[sebgoa]

On Mar 5, 2014, at 4:54 PM, Nux!  wrote:

> On 05.03.2014 15:52, Animesh Chaturvedi wrote:
>> Working on it now, waiting on 1 last thing for realhostip changes
> 
> So, does the realhostip "feature" disappear starting with 4.3?

if that's the case we need to put this on the release notes. Happy to do so if 
someone send me the text..

> 
> Lucian
> 
> -- 
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

RE: 4.3 vote

[Nux!]

On 05.03.2014 15:52, Animesh Chaturvedi wrote:

Working on it now, waiting on 1 last thing for realhostip changes


So, does the realhostip "feature" disappear starting with 4.3?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

RE: 4.3 vote

[Animesh Chaturvedi]

Working on it now, waiting on 1 last thing for realhostip changes


From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
Sent: Wednesday, March 05, 2014 7:27 AM
To: dev@cloudstack.apache.org
Subject: 4.3 vote

I've lost track a little of the 4.3 vote.
Last I saw was that 6th round had been cancelled due to the MySQL dependencies
Animesh  - have you an idea when you'll be calling round 7 ?



Kind Regards
Giles

Giles Sirett
CEO

[Description: Mail Logo Bottom Align]

D: +44 20 3603 0541 | S: +44 20 3603 0540 | M: +44 796 111 2055

giles.sir...@shapeblue.com | 
www.shapeblue.com | 
Twitter:@shapeBlue


Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line
24th-28th March 2014, Region B. Instructor led, 
On-line
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: New EC2 interface

[Noel King]

Really good blog post thanks for sharing.   Great work Ian and Darren the
project looks really good.

Thanks

Noel
On Mar 5, 2014 2:34 PM, "sebgoa"  wrote:

> Hi,
>
> I just wrote a short blog about a new EC2 interface that Ian Duffy and
> Darren Brogan have been working on for course work:
>
> http://buildacloud.org/blog/321-new-ec2-interface-to-cloudstack.html
>
> Once they get their grade for this project we should all be able to send
> pull requests and if we want merge it in CloudStack code (to be discussed)
>
> I want to bring this to dev@ as this might be a way to offer an improved
> EC2 interface and deprecate the current awsapi.
>
> Removing awsapi might simplify packaging for 4.5
>
> Cheers,
>
> -Sebastien

4.3 vote

[Giles Sirett]

I've lost track a little of the 4.3 vote.
Last I saw was that 6th round had been cancelled due to the MySQL dependencies
Animesh  - have you an idea when you'll be calling round 7 ?



Kind Regards
Giles

Giles Sirett
CEO

[Description: Mail Logo Bottom Align]

D: +44 20 3603 0541 | S: +44 20 3603 0540 | M: +44 796 111 2055

giles.sir...@shapeblue.com | 
www.shapeblue.com | 
Twitter:@shapeBlue


Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line
24th-28th March 2014, Region B. Instructor led, 
On-line
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

RE: [4.3][Cherry-pick] CLOUDSTACK-6162:support OVS as connectivity service provider

[Animesh Chaturvedi]

Done

From: Murali Reddy
Sent: Wednesday, March 05, 2014 12:53 AM
To: Animesh Chaturvedi; dev@cloudstack.apache.org
Subject: [4.3][Cherry-pick] CLOUDSTACK-6162:support OVS as connectivity service 
provider

Can you please cherry-pick below commits

BUG-ID: CLOUDSTACK-6162: UI > zone > physical network > service provider > add 
OVS.
Reviewed-by: Brian
Branch: refs/heads/4.3-forward
Commit: 82121a214926fe3ace33183da9e76e0c13c5e203
Parents: 94257c0
Author: Jessica Wang mailto:jessicaw...@apache.org>>

CLOUDSTACK-6162:support OVS as connectivity service provider
adds 'Ovs' as network service provider in the physical network
Branch: refs/heads/4.3-forward
Commit: b8c4ed435abc26950e36e21f9d482639b6691206
Parents: 24dcf29
Author: Murali Reddy mailto:muralimmre...@gmail.com>>

RE: OVS plugin in CloudStack 4.3.0

[Animesh Chaturvedi]

I did pick up Jessica's commits for OVS.

From: Murali Reddy
Sent: Wednesday, March 05, 2014 1:12 AM
To: Nguyen Anh Tu; dev@cloudstack.apache.org; Florin Dumitrascu; Animesh 
Chaturvedi
Subject: Re: OVS plugin in CloudStack 4.3.0

Tuna,

Jessica made a commit 82121a214926fe3ace33183da9e76e0c13c5e203 to fix the UI 
part. That should be good enough to go for 4.3

I do not understand some of the changes and refactoring. They are best done on 
master after proposing. Unlike the other SDN controller and corresponding 
providers which need the details (ip, credentials etc) to be configured in 
order to be enabled, Ovs being internal provider can enabled directly instead 
of having its own API.

From: Nguyen Anh Tu mailto:t...@apache.org>>
Date: Wednesday, 5 March 2014 1:46 PM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Murali Reddy 
mailto:murali.re...@citrix.com>>, Florin Dumitrascu 
mailto:florin.dumitra...@intunenetworks.com>>,
 Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Subject: RE: OVS plugin in CloudStack 4.3.0


Animesh, so what should I do? Can these commits be cherry-picked to 4.3?

Murali & Florin: The complete UI for OVS plugin already commited to 4.3-forward 
branch. Take your time checking it and help me reviewing please. I also add L3 
services and KVM support for OVS plugin in these commits.

Cheers,

--Tuna

Sent from my GT-N7000
On Mar 5, 2014 9:56 AM, "Animesh Chaturvedi" 
mailto:animesh.chaturv...@citrix.com>> wrote:
Tuna I look at your commits in 4.3-forwards and seems the changes are a lot, 
this would have to come in the next release

Thanks
Animesh

> -Original Message-
> From: ng.t...@gmail.com 
> [mailto:ng.t...@gmail.com] On Behalf Of Nguyen
> Anh Tu
> Sent: Monday, February 24, 2014 8:31 AM
> To: dev@cloudstack.apache.org
> Subject: Re: OVS plugin in CloudStack 4.3.0
>
> On Mon, Feb 24, 2014 at 7:01 PM, Murali Reddy
> mailto:murali.re...@citrix.com>>wrote:
>
> > Opened UI bug for 4.3 CLOUDSTACK-6162 if some one can help fixing the
> > UI part.
> >
>
> Murali,
>
> We'll get it in the end of February, I promise!
>
> --Tuna

New EC2 interface

[sebgoa]

Hi,

I just wrote a short blog about a new EC2 interface that Ian Duffy and Darren 
Brogan have been working on for course work:

http://buildacloud.org/blog/321-new-ec2-interface-to-cloudstack.html

Once they get their grade for this project we should all be able to send pull 
requests and if we want merge it in CloudStack code (to be discussed)

I want to bring this to dev@ as this might be a way to offer an improved EC2 
interface and deprecate the current awsapi.

Removing awsapi might simplify packaging for 4.5

Cheers,

-Sebastien

Re: OVS plugin in CloudStack 4.3.0

[Nguyen Anh Tu]

On Wed, Mar 5, 2014 at 6:52 PM, sebgoa  wrote:

> Tuna, make sure that all your code and fixes is in Master. That way it
> will be in 4.4


Got it. Thanks Sebastien!

--Tuna

Re: Review Request 15323: CLOUDSTACK-5080: Hypervisor Capabilities table missing entry for Simulator

[ASF Subversion and Git Services]

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


Commit 844ebab3f65614722fd9cbf61ab9c6f736af7ec0 in cloudstack's branch 
refs/heads/4.3-forward from David Grizzanti
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=844ebab ]

CLOUDSTACK-5080: Hypervisor Capabilities table missing entry for Simulator

Signed-off-by: Prasanna Santhanam 


- ASF Subversion and Git Services


On Nov. 7, 2013, 8:31 p.m., David Grizzanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15323/
> ---
> 
> (Updated Nov. 7, 2013, 8:31 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-5080
> https://issues.apache.org/jira/browse/CLOUDSTACK-5080
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5080: Hypervisor Capabilities table missing entry for Simulator
> - Added new SQL file to db/setup so that a row gets inserted during simulator 
> DB setup for a 'Simulator' hypervisor (in hypervisor_capabilities).
> - Updated developer/pom.xml to include this new file
> 
> 
> Diffs
> -
> 
>   developer/pom.xml 0eb18bf 
>   setup/db/hypervisor_capabilities.simulator.sql PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15323/diff/
> 
> 
> Testing
> ---
> 
> Tested on master and 4.2
> 
> 
> Thanks,
> 
> David Grizzanti
> 
>

Re: OVS plugin in CloudStack 4.3.0

[sebgoa]

On Mar 5, 2014, at 9:18 AM, Nguyen Anh Tu  wrote:

> We still get problem in migrating VM. Continue working…
> 

Tuna, make sure that all your code and fixes is in Master. That way it will be 
in 4.4

> --Tuna
> 
> Sent from my GT-N7000
> On Mar 5, 2014 3:16 PM, "Nguyen Anh Tu"  wrote:
> 
>> Animesh, so what should I do? Can these commits be cherry-picked to 4.3?
>> 
>> Murali & Florin: The complete UI for OVS plugin already commited to
>> 4.3-forward branch. Take your time checking it and help me reviewing
>> please. I also add L3 services and KVM support for OVS plugin in these
>> commits.
>> 
>> Cheers,
>> 
>> --Tuna
>> 
>> Sent from my GT-N7000
>> On Mar 5, 2014 9:56 AM, "Animesh Chaturvedi" <
>> animesh.chaturv...@citrix.com> wrote:
>> 
>>> Tuna I look at your commits in 4.3-forwards and seems the changes are a
>>> lot, this would have to come in the next release
>>> 
>>> Thanks
>>> Animesh
>>> 
 -Original Message-
 From: ng.t...@gmail.com [mailto:ng.t...@gmail.com] On Behalf Of Nguyen
 Anh Tu
 Sent: Monday, February 24, 2014 8:31 AM
 To: dev@cloudstack.apache.org
 Subject: Re: OVS plugin in CloudStack 4.3.0
 
 On Mon, Feb 24, 2014 at 7:01 PM, Murali Reddy
 wrote:
 
> Opened UI bug for 4.3 CLOUDSTACK-6162 if some one can help fixing the
> UI part.
> 
 
 Murali,
 
 We'll get it in the end of February, I promise!
 
 --Tuna
>>> 
>> 

RE: The global settings beast...

[Rajesh Battala]

The need to restart is, the Managers  have configured with the values in Global 
Settings and running.

-Original Message-
From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] 
Sent: Wednesday, March 5, 2014 3:13 PM
To: dev@cloudstack.apache.org
Subject: Re: The global settings beast...

The need to restart the management server for any global configuration change 
is a problem.
I spent at least a few hours trying to debug an issue only to realise that its 
not an issue but, I have to restart the management server. 


~Rajani



On 05-Mar-2014, at 3:01 pm, Donal Lafferty  wrote:

> In fairness, the biggest problem is having to reboot.
> 
> WRT to b), there is a search option that avoids the need to scroll.
> 
>> -Original Message-
>> From: John Kinsella [mailto:j...@stratosec.co]
>> Sent: 05 March 2014 08:22
>> To: 
>> Subject: The global settings beast...
>> 
>> One thing that's been gnawing on me - we keep shoving more and more 
>> stuff into the global settings shortcut instead of creating a proper 
>> settings UI.
>> Then some new user comes along all shiny-eyed at the awesomeness of 
>> ACS, but wonders why something isn't working, only to be told that 
>> combination of a) it's in the docs and b) you have to scroll down 
>> through 30 items in global settings, then change something, then 
>> restart mgmt, then re- login...then it'll work.
>> 
>> I know the UI is supposed to be a proof of concept, but I'm thinking 
>> we need to shed that label and empty out some closeted skeletons such as 
>> this.
>> 
>> Am I the only one this bothers, or should we maybe set it as a goal 
>> for 4.5 (maybe this is on a feature list and I've missed it...)?
>> 
>> John

Review Request 18768: CLOUDSTACK-6151: Local data disk with tag goes to the wrong local storage pool

[Saksham Srivastava]

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

Review request for cloudstack and Koushik Das.


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


Repository: cloudstack-git


Description
---

Patch for master :
https://reviews.apache.org/r/18352/


Diffs
-

  
engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
 08efb83 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
 2c4369d 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
 57afa16 
  server/test/resources/createNetworkOffering.xml c6228da 

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


Testing
---


Thanks,

Saksham Srivastava

RE: SSO

[Alex Hitchins]

Hello María,

This is something I will be looking into later, I will ping you here when I 
have more information.


Regards

Alex Hitchins

D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969

alex.hitch...@shapeblue.com

-Original Message-
From: María Noelia Gil [mailto:marianoelia@um.es]
Sent: 04 March 2014 19:34
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: SSO

Hello, I am studying the operation of single sign-on in CloudStack. Does anyone 
can provide me information about this topic?

I want to know if you can use SAML, OpenID, ..., and as it should be.

Thank you.
Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training
18th-19th February 2014, Brazil. 
Classroom
17th-23rd March 2014, Region A. Instructor led, 
On-line
24th-28th March 2014, Region B. Instructor led, 
On-line
16th-20th June 2014, Region A. Instructor led, 
On-line
23rd-27th June 2014, Region B. Instructor led, 
On-line

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Antonio Fornie]

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

(Updated March 5, 2014, 10:35 a.m.)


Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and Hugo 
Trippaers.


Changes
---

CallContext.current().setEventDisplayEnabled(cmd.isDisplayResourceEnabled());
should be called after the dispatch chain


Repository: cloudstack-git


Description
---

Dispatcher corrections, refactoring and tests. Corrects problems from previous 
attempts that were reverted by Alena. Most of the changes are the same, but 
this one is not creating conflicts of Map types for Aync Commands or for 
parameters as Lists or Maps.


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
  api/src/org/apache/cloudstack/api/BaseCmd.java e869ddf 
  api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
  api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java b2c6734 
  api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java 
cf5d355 
  
api/src/org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmProfileCmd.java
 570e018 
  api/test/org/apache/cloudstack/api/BaseCmdTest.java PRE-CREATION 
  server/resources/META-INF/cloudstack/core/spring-server-core-misc-context.xml 
fd2f5fb 
  server/src/com/cloud/api/ApiAsyncJobDispatcher.java f037f2e 
  server/src/com/cloud/api/ApiDispatcher.java 5bdefe7 
  server/src/com/cloud/api/ApiServer.java 3df599e 
  server/src/com/cloud/api/ApiServlet.java 46f7eba 
  server/src/com/cloud/api/dispatch/CommandCreationWorker.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchChain.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchChainFactory.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchTask.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchWorker.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamGenericValidationWorker.java 
PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamProcessWorker.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamSemanticValidationWorker.java 
PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamUnpackWorker.java PRE-CREATION 
  server/src/com/cloud/network/as/AutoScaleManagerImpl.java 208b4a4 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
37171f5 
  server/src/com/cloud/storage/snapshot/SnapshotSchedulerImpl.java a85c052 
  server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
  server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
PRE-CREATION 

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


Testing
---

Full build and test plus manually testing many features. Also including 
CreateTagsCommand that failed in previous commit.

All unit and integration tests.

Test CS Web UI with the browser going through several use cases.

Also use the CS API by sending HTTP requests generated manually including 
requests for Async Commands with Map parameters and during these tests apart 
fromtesting correct functionality I also debugged to check that Maps created 
correctly where they should but also that in the cases where the async command 
must be persisted and later on retrieved and deserialized by gson everything 
works ok and does what and where is expected. An example based on the comment 
by Alena:
http://localhost:8096/client/api?command=createTags&resourceids=ids&resourcetype=type&tags[0].key=region&tags[0].value=canada
Also other examples like
http://localhost:8096/client/api?command=createSecondaryStagingStore&url=httpbla&details[0].key=region&details[0].value=canada&details[1].key=element&details[1].value=fire


Thanks,

Antonio Fornie

Re: Review Request 17888: Dispatcher corrections, refactoring and tests. Corrects problems from previous attempt

[Antonio Fornie]

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

(Updated March 5, 2014, 10:29 a.m.)


Review request for cloudstack, Alena Prokharchyk, daan Hoogland, and Hugo 
Trippaers.


Changes
---

New BaseCmd#getActualCommandName plus resolving new conflict with recent commits


Repository: cloudstack-git


Description
---

Dispatcher corrections, refactoring and tests. Corrects problems from previous 
attempts that were reverted by Alena. Most of the changes are the same, but 
this one is not creating conflicts of Map types for Aync Commands or for 
parameters as Lists or Maps.


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca 
  api/src/org/apache/cloudstack/api/BaseCmd.java e869ddf 
  api/src/org/apache/cloudstack/api/BaseListCmd.java c1a4b4c 
  api/src/org/apache/cloudstack/api/command/admin/user/GetUserCmd.java b2c6734 
  api/src/org/apache/cloudstack/api/command/admin/user/UpdateUserCmd.java 
cf5d355 
  
api/src/org/apache/cloudstack/api/command/user/autoscale/CreateAutoScaleVmProfileCmd.java
 570e018 
  api/test/org/apache/cloudstack/api/BaseCmdTest.java PRE-CREATION 
  server/resources/META-INF/cloudstack/core/spring-server-core-misc-context.xml 
fd2f5fb 
  server/src/com/cloud/api/ApiAsyncJobDispatcher.java f037f2e 
  server/src/com/cloud/api/ApiDispatcher.java 5bdefe7 
  server/src/com/cloud/api/ApiServer.java 3df599e 
  server/src/com/cloud/api/ApiServlet.java 46f7eba 
  server/src/com/cloud/api/dispatch/CommandCreationWorker.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchChain.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchChainFactory.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchTask.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/DispatchWorker.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamGenericValidationWorker.java 
PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamProcessWorker.java PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamSemanticValidationWorker.java 
PRE-CREATION 
  server/src/com/cloud/api/dispatch/ParamUnpackWorker.java PRE-CREATION 
  server/src/com/cloud/network/as/AutoScaleManagerImpl.java 208b4a4 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
37171f5 
  server/src/com/cloud/storage/snapshot/SnapshotSchedulerImpl.java a85c052 
  server/test/com/cloud/api/ApiDispatcherTest.java 7314a57 
  server/test/com/cloud/api/dispatch/CommandCreationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/DispatchChainFactoryTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamGenericValidationWorkerTest.java 
PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamProcessWorkerTest.java PRE-CREATION 
  server/test/com/cloud/api/dispatch/ParamSemanticValidationWorkerTest.java 
PRE-CREATION 

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


Testing
---

Full build and test plus manually testing many features. Also including 
CreateTagsCommand that failed in previous commit.

All unit and integration tests.

Test CS Web UI with the browser going through several use cases.

Also use the CS API by sending HTTP requests generated manually including 
requests for Async Commands with Map parameters and during these tests apart 
fromtesting correct functionality I also debugged to check that Maps created 
correctly where they should but also that in the cases where the async command 
must be persisted and later on retrieved and deserialized by gson everything 
works ok and does what and where is expected. An example based on the comment 
by Alena:
http://localhost:8096/client/api?command=createTags&resourceids=ids&resourcetype=type&tags[0].key=region&tags[0].value=canada
Also other examples like
http://localhost:8096/client/api?command=createSecondaryStagingStore&url=httpbla&details[0].key=region&details[0].value=canada&details[1].key=element&details[1].value=fire


Thanks,

Antonio Fornie

Re: Review Request 17591: CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain useful information

[daan Hoogland]

> On March 4, 2014, 11:35 p.m., ASF Subversion and Git Services wrote:
> > Commit 444e8f6bb3447a7eeb97f7c5d9b46abba3150072 in cloudstack's branch 
> > refs/heads/4.3-forward from Alena Prokharchyk
> > [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=444e8f6 ]
> > 
> > CLOUDSTACK-5872: use List DS for storing NicProfiles as public network can 
> > have more than one nic
> >

is this really related to CLOUDSTACK-5872 or is it a typo


- daan


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


On Jan. 31, 2014, 2:51 p.m., David Grizzanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17591/
> ---
> 
> (Updated Jan. 31, 2014, 2:51 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-5872
> https://issues.apache.org/jira/browse/CLOUDSTACK-5872
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5872: Async response from addAccountToProject doesn't contain 
> useful information
> 
> Updated the following classes to return a project object after async jobs 
> complete:
>  api/src/com/cloud/projects/ProjectService.java |  6 ++--
>  .../user/account/AddAccountToProjectCmd.java   |  7 +++--
>  .../user/account/DeleteAccountFromProjectCmd.java  |  7 +++--
>  .../user/project/UpdateProjectInvitationCmd.java   |  8 +++--
>  server/src/com/cloud/projects/ProjectManager.java  |  2 +-
>  .../src/com/cloud/projects/ProjectManagerImpl.java | 34 
> +++---
>  .../com/cloud/projects/MockProjectManagerImpl.java | 16 +-
> 
> Previously these API commands only returned "success => true" in the aysnc 
> job result.  Now it returns the project that a user was added/deleted to.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/projects/ProjectService.java dc882ef 
>   
> api/src/org/apache/cloudstack/api/command/user/account/AddAccountToProjectCmd.java
>  36df579 
>   
> api/src/org/apache/cloudstack/api/command/user/account/DeleteAccountFromProjectCmd.java
>  f6aa36c 
>   
> api/src/org/apache/cloudstack/api/command/user/project/UpdateProjectInvitationCmd.java
>  dda7b54 
>   server/src/com/cloud/projects/ProjectManager.java f568146 
>   server/src/com/cloud/projects/ProjectManagerImpl.java 5a0ed1c 
>   server/test/com/cloud/projects/MockProjectManagerImpl.java dc377ff 
> 
> Diff: https://reviews.apache.org/r/17591/diff/
> 
> 
> Testing
> ---
> 
> Testing done on master.
> 
> 
> Thanks,
> 
> David Grizzanti
> 
>

Re: Change Volume IOPS on fly without detaching the disk feature.

[Wido den Hollander]

On 03/05/2014 10:12 AM, Wei ZHOU wrote:

I was thinking about it last week.
AFAIK, libvirt-java 0.5.1 does not support change setting on running vms,
but virsh command line and libvirt API supports it.
so the sulution are
(1) change libvirt-java to support it, and make it released in the next
version. Maybe Wido can help us.


Sure! That seems the best way forward. What is currently lacking in the 
libvirt-java bindings?



(2) call virsh command line.



Please, please, do not do that. That's very hacky. We should really keep 
using the libvirt-java bindings and stay away from invoking binaries.


Wido


-Wei

2014-03-05 9:01 GMT+01:00 Punith S :


hi guys,

we are having a fixed max iops for each volume being attached to the
instance in managed storage,
so this a problem where we are making users to pre allocate the iops of the
disk without having an option to change or resize it, similar to the size
metric.

so i would like to introduce a new feature which enables to change or
resize the volume iops on fly without detaching the datadisk of the VM with
zero downtime where performance of the datadisk can be altered at any point
with the available iops of the primary storage pool, which is similar in
resizing the volume or datadisk of the vm , where in latter we have to
detach the datadisk.

what do you guys think about this feature ? any feedback ?

thanks,

--
regards,

punith s
cloudbyte.com

Re: [DISCUSS] realhostip.com going away

[Erik Weber]

How is security being handled in HTTP mode?


-- 
Erik


On Wed, Mar 5, 2014 at 2:43 AM, Amogh Vasekar wrote:

> Hello,
>
> I have created a review request at : https://reviews.apache.org/r/18759/
> that partially address the issue. It has a link to the wiki describing the
> changes in detail.
>
> Thanks,
> Amogh
>
> On 3/3/14 8:58 AM, "John Kinsella"  wrote:
>
> >I talked with some of the Citrix folk over the weekendŠtheir position is
> >they think they¹d be doing the community a disfavor by passing the torch,
> >so-to-speak, and I agree with them [1].
> >
> >From what I understand, the patches that are going to be proposed will
> >remove HTTPS completely and encrypt over http. That said, I haven¹t seen
> >anything yet, so until we see something we¹re guessing. I¹m waiting a few
> >more days to see what¹s proposed.
> >
> >John
> >1: I¹m sharing conversations with individuals, so take this as hearsay
> >not official comment from Citrix.
> >
> >On Mar 2, 2014, at 8:15 AM, Paul Angus
> >mailto:paul.an...@shapeblue.com>> wrote:
> >
> >There are a few issues with the current console proxy setup, not least of
> >which is the need to have internet access to resolve
> >realhostip.com in the first place - so console
> >proxy can't work if you don't have internet access on your client.  I
> >have configured alternative realhostip.com setups
> >for clients - and quite a lot of work goes into creating the
> >infrastructure (and certs) to support changing to a user managed
> >certificate.
> >
> >Sooo, is it at all possible to secure communications with the console
> >proxy, without having to rely on ANY outside entity?
> >
> >Testing alone is going to be a pain, if a full ssl cert setup is required
> >to use console proxy..
> >
> >Regards
> >
> >Paul Angus
> >Cloud Architect
> >S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> >paul.an...@shapeblue.com
> >
> >-Original Message-
> >From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
> >Sent: 28 February 2014 23:05
> >To: dev@cloudstack.apache.org
> >Subject: Re: [DISCUSS] realhostip.com going away
> >
> >
> >
> >On 2/28/14 2:03 PM, "Nux!"  wrote:
> >
> >There's also the problem of the certificate. It comes bundled in ACS as
> >far as I can tell.. When does it expire?
> >
> >notBefore=Feb  3 03:30:40 2012 GMT
> >notAfter=Feb  7 05:11:23 2017 GMT
> >
> >Need Enterprise Grade Support for Apache CloudStack?
> >Our CloudStack Infrastructure
> >Support offers
> >the best 24/7 SLA for CloudStack Environments.
> >
> >Apache CloudStack Bootcamp training courses
> >
> >**NEW!** CloudStack 4.2.1
> >training
> >18th-19th February 2014, Brazil.
> >Classroom
> >17th-23rd March 2014, Region A. Instructor led,
> >On-line
> >24th-28th March 2014, Region B. Instructor led,
> >On-line
> >16th-20th June 2014, Region A. Instructor led,
> >On-line
> >23rd-27th June 2014, Region B. Instructor led,
> >On-line
> >
> >This email and any attachments to it may be confidential and are intended
> >solely for the use of the individual to whom it is addressed. Any views
> >or opinions expressed are solely those of the author and do not
> >necessarily represent those of Shape Blue Ltd or related companies. If
> >you are not the intended recipient of this email, you must neither take
> >any action based upon its contents, nor copy or show it to anyone. Please
> >contact the sender if you believe you have received this email in error.
> >Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> >Services India LLP is a company incorporated in India and is operated
> >under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
> >a company incorporated in Brasil and is operated under license from Shape
> >Blue Ltd. ShapeBlue is a registered trademark.
> >
> >Stratosec - Compliance as a Service
> >o: 415.315.9385
> >@johnlkinsella
> >
>
>

Re: The global settings beast...

[Rajani Karuturi]

The need to restart the management server for any global configuration change 
is a problem.
I spent at least a few hours trying to debug an issue only to realise that its 
not an issue but, I have to restart the management server. 


~Rajani



On 05-Mar-2014, at 3:01 pm, Donal Lafferty  wrote:

> In fairness, the biggest problem is having to reboot.
> 
> WRT to b), there is a search option that avoids the need to scroll.
> 
>> -Original Message-
>> From: John Kinsella [mailto:j...@stratosec.co]
>> Sent: 05 March 2014 08:22
>> To: 
>> Subject: The global settings beast...
>> 
>> One thing that's been gnawing on me - we keep shoving more and more
>> stuff into the global settings shortcut instead of creating a proper 
>> settings UI.
>> Then some new user comes along all shiny-eyed at the awesomeness of
>> ACS, but wonders why something isn't working, only to be told that
>> combination of a) it's in the docs and b) you have to scroll down through 30
>> items in global settings, then change something, then restart mgmt, then re-
>> login...then it'll work.
>> 
>> I know the UI is supposed to be a proof of concept, but I'm thinking we need
>> to shed that label and empty out some closeted skeletons such as this.
>> 
>> Am I the only one this bothers, or should we maybe set it as a goal for 4.5
>> (maybe this is on a feature list and I've missed it...)?
>> 
>> John

RE: The global settings beast...

[Donal Lafferty]

In fairness, the biggest problem is having to reboot.

WRT to b), there is a search option that avoids the need to scroll.

> -Original Message-
> From: John Kinsella [mailto:j...@stratosec.co]
> Sent: 05 March 2014 08:22
> To: 
> Subject: The global settings beast...
> 
> One thing that's been gnawing on me - we keep shoving more and more
> stuff into the global settings shortcut instead of creating a proper settings 
> UI.
> Then some new user comes along all shiny-eyed at the awesomeness of
> ACS, but wonders why something isn't working, only to be told that
> combination of a) it's in the docs and b) you have to scroll down through 30
> items in global settings, then change something, then restart mgmt, then re-
> login...then it'll work.
> 
> I know the UI is supposed to be a proof of concept, but I'm thinking we need
> to shed that label and empty out some closeted skeletons such as this.
> 
> Am I the only one this bothers, or should we maybe set it as a goal for 4.5
> (maybe this is on a feature list and I've missed it...)?
> 
> John

Re: Change Volume IOPS on fly without detaching the disk feature.

[Wei ZHOU]

I was thinking about it last week.
AFAIK, libvirt-java 0.5.1 does not support change setting on running vms,
but virsh command line and libvirt API supports it.
so the sulution are
(1) change libvirt-java to support it, and make it released in the next
version. Maybe Wido can help us.
(2) call virsh command line.

-Wei

2014-03-05 9:01 GMT+01:00 Punith S :

> hi guys,
>
> we are having a fixed max iops for each volume being attached to the
> instance in managed storage,
> so this a problem where we are making users to pre allocate the iops of the
> disk without having an option to change or resize it, similar to the size
> metric.
>
> so i would like to introduce a new feature which enables to change or
> resize the volume iops on fly without detaching the datadisk of the VM with
> zero downtime where performance of the datadisk can be altered at any point
> with the available iops of the primary storage pool, which is similar in
> resizing the volume or datadisk of the vm , where in latter we have to
> detach the datadisk.
>
> what do you guys think about this feature ? any feedback ?
>
> thanks,
>
> --
> regards,
>
> punith s
> cloudbyte.com
>

Re: Review Request 18352: CLOUDSTACK-6151: Local data disk with tag goes to the wrong local storage pool

[Koushik Das]

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

Ship it!


Ship It!

- Koushik Das


On March 5, 2014, 8:50 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18352/
> ---
> 
> (Updated March 5, 2014, 8:50 a.m.)
> 
> 
> Review request for cloudstack, Koushik Das and Prachi Damle.
> 
> 
> Bugs: CLOUDSTACK-6151
> https://issues.apache.org/jira/browse/CLOUDSTACK-6151
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Attaching a new disk created from local disk offering with tags, to a VM was 
> going to wrong local storage pool.
> Cause : In LocalStoragePoolAlocator-
> List hostPools = 
> _poolHostDao.listByHostId(plan.getHostId());
> It return pools by hostId, but nowhere were the tags being compared.
> 
> Added new method findLocalStoragePoolsByHostAndTags() that returns stoage 
> pools by hostid and tags both.
> 
> 
> Diffs
> -
> 
>   
> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
>  ea0bad9 
>   
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>  59c338e 
>   
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>  d35aa44 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
>  1f61e8b 
>   server/test/resources/createNetworkOffering.xml c6228da 
> 
> Diff: https://reviews.apache.org/r/18352/diff/
> 
> 
> Testing
> ---
> 
> Tested the folowing scenarios:
> attaching local volume with tags
> attaching local volume without tags
> attaching local volume with different tags
> attaching shared volume
> 
> Build passes successfully.
> Patch applies cleanly.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: OVS plugin in CloudStack 4.3.0

[Murali Reddy]

Tuna,

Jessica made a commit 82121a214926fe3ace33183da9e76e0c13c5e203 to fix the UI 
part. That should be good enough to go for 4.3

I do not understand some of the changes and refactoring. They are best done on 
master after proposing. Unlike the other SDN controller and corresponding 
providers which need the details (ip, credentials etc) to be configured in 
order to be enabled, Ovs being internal provider can enabled directly instead 
of having its own API.

From: Nguyen Anh Tu mailto:t...@apache.org>>
Date: Wednesday, 5 March 2014 1:46 PM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, Murali Reddy 
mailto:murali.re...@citrix.com>>, Florin Dumitrascu 
mailto:florin.dumitra...@intunenetworks.com>>,
 Animesh Chaturvedi 
mailto:animesh.chaturv...@citrix.com>>
Subject: RE: OVS plugin in CloudStack 4.3.0


Animesh, so what should I do? Can these commits be cherry-picked to 4.3?

Murali & Florin: The complete UI for OVS plugin already commited to 4.3-forward 
branch. Take your time checking it and help me reviewing please. I also add L3 
services and KVM support for OVS plugin in these commits.

Cheers,

--Tuna

Sent from my GT-N7000

On Mar 5, 2014 9:56 AM, "Animesh Chaturvedi" 
mailto:animesh.chaturv...@citrix.com>> wrote:
Tuna I look at your commits in 4.3-forwards and seems the changes are a lot, 
this would have to come in the next release

Thanks
Animesh

> -Original Message-
> From: ng.t...@gmail.com 
> [mailto:ng.t...@gmail.com] On Behalf Of Nguyen
> Anh Tu
> Sent: Monday, February 24, 2014 8:31 AM
> To: dev@cloudstack.apache.org
> Subject: Re: OVS plugin in CloudStack 4.3.0
>
> On Mon, Feb 24, 2014 at 7:01 PM, Murali Reddy
> mailto:murali.re...@citrix.com>>wrote:
>
> > Opened UI bug for 4.3 CLOUDSTACK-6162 if some one can help fixing the
> > UI part.
> >
>
> Murali,
>
> We'll get it in the end of February, I promise!
>
> --Tuna

Re: Review Request 18352: CLOUDSTACK-6151: Local data disk with tag goes to the wrong local storage pool

[ASF Subversion and Git Services]

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


Commit a8b34c0c4f99067243524813f136b31cb78c5f78 in cloudstack's branch 
refs/heads/4.3-forward from Saksham Srivastava
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a8b34c0 ]

CLOUDSTACK-6151: Local data disk with tag goes to the wrong local storage pool

Signed-off-by: Koushik Das 


- ASF Subversion and Git Services


On March 5, 2014, 8:50 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18352/
> ---
> 
> (Updated March 5, 2014, 8:50 a.m.)
> 
> 
> Review request for cloudstack, Koushik Das and Prachi Damle.
> 
> 
> Bugs: CLOUDSTACK-6151
> https://issues.apache.org/jira/browse/CLOUDSTACK-6151
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Attaching a new disk created from local disk offering with tags, to a VM was 
> going to wrong local storage pool.
> Cause : In LocalStoragePoolAlocator-
> List hostPools = 
> _poolHostDao.listByHostId(plan.getHostId());
> It return pools by hostId, but nowhere were the tags being compared.
> 
> Added new method findLocalStoragePoolsByHostAndTags() that returns stoage 
> pools by hostid and tags both.
> 
> 
> Diffs
> -
> 
>   
> engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
>  ea0bad9 
>   
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
>  59c338e 
>   
> engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>  d35aa44 
>   
> engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
>  1f61e8b 
>   server/test/resources/createNetworkOffering.xml c6228da 
> 
> Diff: https://reviews.apache.org/r/18352/diff/
> 
> 
> Testing
> ---
> 
> Tested the folowing scenarios:
> attaching local volume with tags
> attaching local volume without tags
> attaching local volume with different tags
> attaching shared volume
> 
> Build passes successfully.
> Patch applies cleanly.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request 18194: G11N: Fixed the Hardcoding Issue

[Vetrivel Chinnasamy]

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

(Updated March 5, 2014, 9:01 a.m.)


Review request for cloudstack and Brian Federle.


Repository: cloudstack-git


Description
---

Externalized the hard coded strings by adding reference ID and label to the 
resource files. Also updated the dictionary.jsp file.


Diffs (updated)
-

  client/WEB-INF/classes/resources/messages.properties 82ac499 
  client/WEB-INF/classes/resources/messages_ja_JP.properties 828cf54 
  client/WEB-INF/classes/resources/messages_zh_CN.properties f4c206b 
  tools/ngui/static/js/app/accounts/accounts.js eae5070 
  tools/ngui/static/js/app/storage/storage.js e562a95 
  ui/dictionary.jsp 11dbeb5 
  ui/modules/vnmcNetworkProvider/vnmcNetworkProvider.js d618b23 
  ui/scripts/configuration.js 869b876 
  ui/scripts/installWizard.js 25de4aa 
  ui/scripts/instances.js 53c9e98 
  ui/scripts/network.js 6ce66e8 
  ui/scripts/sharedFunctions.js f0afea5 
  ui/scripts/storage.js 1cd8d2e 
  ui/scripts/system.js c21e277 
  ui/scripts/templates.js 3551613 
  ui/scripts/ui-custom/zoneChart.js e847a19 
  ui/scripts/ui/core.js 06be12b 
  ui/scripts/ui/widgets/tagger.js 673bd43 
  ui/scripts/vpc.js 770ee9b 
  ui/scripts/zoneWizard.js 1de3646 

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


Testing
---

Local unit testing done by replacing the java-script, dictionary.jsp and 
properties files.


Thanks,

Vetrivel Chinnasamy

[4.3][Cherry-pick] CLOUDSTACK-6162:support OVS as connectivity service provider

[Murali Reddy]

Can you please cherry-pick below commits

BUG-ID: CLOUDSTACK-6162: UI > zone > physical network > service provider > add 
OVS.
Reviewed-by: Brian
Branch: refs/heads/4.3-forward
Commit: 82121a214926fe3ace33183da9e76e0c13c5e203
Parents: 94257c0
Author: Jessica Wang mailto:jessicaw...@apache.org>>

CLOUDSTACK-6162:support OVS as connectivity service provider
adds 'Ovs' as network service provider in the physical network
Branch: refs/heads/4.3-forward
Commit: b8c4ed435abc26950e36e21f9d482639b6691206
Parents: 24dcf29
Author: Murali Reddy mailto:muralimmre...@gmail.com>>

Re: Review Request 18352: CLOUDSTACK-6151: Local data disk with tag goes to the wrong local storage pool

[Saksham Srivastava]

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

(Updated March 5, 2014, 8:50 a.m.)


Review request for cloudstack, Koushik Das and Prachi Damle.


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


Repository: cloudstack-git


Description
---

Attaching a new disk created from local disk offering with tags, to a VM was 
going to wrong local storage pool.
Cause : In LocalStoragePoolAlocator-
List hostPools = _poolHostDao.listByHostId(plan.getHostId());
It return pools by hostId, but nowhere were the tags being compared.

Added new method findLocalStoragePoolsByHostAndTags() that returns stoage pools 
by hostid and tags both.


Diffs (updated)
-

  
engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
 ea0bad9 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDao.java
 59c338e 
  
engine/schema/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
 d35aa44 
  
engine/storage/src/org/apache/cloudstack/storage/allocator/LocalStoragePoolAllocator.java
 1f61e8b 
  server/test/resources/createNetworkOffering.xml c6228da 

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


Testing
---

Tested the folowing scenarios:
attaching local volume with tags
attaching local volume without tags
attaching local volume with different tags
attaching shared volume

Build passes successfully.
Patch applies cleanly.


Thanks,

Saksham Srivastava

The global settings beast...

[John Kinsella]

One thing that’s been gnawing on me - we keep shoving more and more stuff into 
the global settings shortcut instead of creating a proper settings UI. Then 
some new user comes along all shiny-eyed at the awesomeness of ACS, but wonders 
why something isn’t working, only to be told that combination of a) it’s in the 
docs and b) you have to scroll down through 30 items in global settings, then 
change something, then restart mgmt, then re-login…then it’ll work.

I know the UI is supposed to be a proof of concept, but I’m thinking we need to 
shed that label and empty out some closeted skeletons such as this.

Am I the only one this bothers, or should we maybe set it as a goal for 4.5 
(maybe this is on a feature list and I’ve missed it…)?

John

RE: OVS plugin in CloudStack 4.3.0

[Nguyen Anh Tu]

We still get problem in migrating VM. Continue working...

--Tuna

Sent from my GT-N7000
On Mar 5, 2014 3:16 PM, "Nguyen Anh Tu"  wrote:

> Animesh, so what should I do? Can these commits be cherry-picked to 4.3?
>
> Murali & Florin: The complete UI for OVS plugin already commited to
> 4.3-forward branch. Take your time checking it and help me reviewing
> please. I also add L3 services and KVM support for OVS plugin in these
> commits.
>
> Cheers,
>
> --Tuna
>
> Sent from my GT-N7000
> On Mar 5, 2014 9:56 AM, "Animesh Chaturvedi" <
> animesh.chaturv...@citrix.com> wrote:
>
>> Tuna I look at your commits in 4.3-forwards and seems the changes are a
>> lot, this would have to come in the next release
>>
>> Thanks
>> Animesh
>>
>> > -Original Message-
>> > From: ng.t...@gmail.com [mailto:ng.t...@gmail.com] On Behalf Of Nguyen
>> > Anh Tu
>> > Sent: Monday, February 24, 2014 8:31 AM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: OVS plugin in CloudStack 4.3.0
>> >
>> > On Mon, Feb 24, 2014 at 7:01 PM, Murali Reddy
>> > wrote:
>> >
>> > > Opened UI bug for 4.3 CLOUDSTACK-6162 if some one can help fixing the
>> > > UI part.
>> > >
>> >
>> > Murali,
>> >
>> > We'll get it in the end of February, I promise!
>> >
>> > --Tuna
>>
>

RE: OVS plugin in CloudStack 4.3.0

[Nguyen Anh Tu]

Animesh, so what should I do? Can these commits be cherry-picked to 4.3?

Murali & Florin: The complete UI for OVS plugin already commited to
4.3-forward branch. Take your time checking it and help me reviewing
please. I also add L3 services and KVM support for OVS plugin in these
commits.

Cheers,

--Tuna

Sent from my GT-N7000
On Mar 5, 2014 9:56 AM, "Animesh Chaturvedi" 
wrote:

> Tuna I look at your commits in 4.3-forwards and seems the changes are a
> lot, this would have to come in the next release
>
> Thanks
> Animesh
>
> > -Original Message-
> > From: ng.t...@gmail.com [mailto:ng.t...@gmail.com] On Behalf Of Nguyen
> > Anh Tu
> > Sent: Monday, February 24, 2014 8:31 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: OVS plugin in CloudStack 4.3.0
> >
> > On Mon, Feb 24, 2014 at 7:01 PM, Murali Reddy
> > wrote:
> >
> > > Opened UI bug for 4.3 CLOUDSTACK-6162 if some one can help fixing the
> > > UI part.
> > >
> >
> > Murali,
> >
> > We'll get it in the end of February, I promise!
> >
> > --Tuna
>

RE: [4.3] [Cherry-pick] developer mysql dependencies

[Animesh Chaturvedi]

Done

> -Original Message-
> From: John Kinsella [mailto:j...@stratosec.co]
> Sent: Wednesday, February 26, 2014 6:29 PM
> To: 
> Subject: [4.3] [Cherry-pick] developer mysql dependencies
> 
> Dearest RM - would like the following commits from 4.3-forward picked into
> 4.3.
> 
> To the best of my knowledge they comply with ASF third-party licensing
> policy for build scripts [1].
> 
> 24dcf2948c2d4cdd98fcda0f766d82f40eee8be1
> 2c3cd90b5604cde8123968b15ef6c53bad43b5e2
> f5aeac845df8b73b1525442461a8a811e61439d0
> 54db315214f8dd518eaf1f1615d423d9f4129d31
> 
> John
> 1: https://www.apache.org/legal/3party.html#options-build

CloudStack Bay Area Meetup

[Amogh Vasekar]

Hi all,
 
The CloudStack SF Bay Area Users Meetup group is holding the 2nd
CloudStack meetup of the year on Wednesday, March 19th, 2014 at NetApp in
Sunnyvale, CA US. The hands-on session was a popular request the last
time, and this meet-up will focus on the same.

 
Here are the details:
 
Date: Wednesday, March 19th, 2014
Time: 6:00pm - 9:00pm
Details: Registration / Refreshments from 6:00pm - 6:30pm. Hands-on
CloudStack Session with David Nalley from 6:30pm ­ 9:00pm.
Link to event page: http://clds.co/1lx1GgN


Hope to see you there in large numbers!

Thanks,
Amogh

Change Volume IOPS on fly without detaching the disk feature.

[Punith S]

hi guys,

we are having a fixed max iops for each volume being attached to the
instance in managed storage,
so this a problem where we are making users to pre allocate the iops of the
disk without having an option to change or resize it, similar to the size
metric.

so i would like to introduce a new feature which enables to change or
resize the volume iops on fly without detaching the datadisk of the VM with
zero downtime where performance of the datadisk can be altered at any point
with the available iops of the primary storage pool, which is similar in
resizing the volume or datadisk of the vm , where in latter we have to
detach the datadisk.

what do you guys think about this feature ? any feedback ?

thanks,

-- 
regards,

punith s
cloudbyte.com