Re: Apache Cloudstack 4.8 and XenServer 7

2016-09-08 Thread Erik Weber
On Fri, Jul 29, 2016 at 7:53 AM, Marty Godsey  wrote:

> Should there be any issues running XS7 with CS 4.8?
>
>
Most likely, yes. There are some major changes with the OS in XS7 that is
likely to break.

I think there are some efforts from Accelerite to fix it, but I don't know
the status.

-- 
Erik


Re: storage affinity groups

2016-09-08 Thread Tutkowski, Mike
Personally, I think the most flexible way is if you have a developer write a 
storage-pool allocator to customize the placement of virtual disks as you see 
fit.

You extend the StoragePoolAllocator class, write your logic, and update a 
config file so that Spring is aware of the new allocator and creates an 
instance of it when the management server is started up.

You might even want to extend ClusterScopeStoragePoolAllocator (instead of 
directly implementing StoragePoolAllocator) as it possibly provides some useful 
functionality for you already.

From: Marty Godsey 
Sent: Thursday, September 8, 2016 6:27 PM
To: dev@cloudstack.apache.org
Subject: RE: storage affinity groups

So what would be the best way to do it? I use templates to make it simple for 
my users so that the Xen tools are already installed as an example.

Regards,
Marty Godsey

-Original Message-
From: Yiping Zhang [mailto:yzh...@marketo.com]
Sent: Thursday, September 8, 2016 7:55 PM
To: dev@cloudstack.apache.org
Subject: Re: storage affinity groups

Well, using tags leads to proliferation of templates or service offerings etc. 
It is not very scalable and gets out of hand very quickly.

Yiping

On 9/8/16, 4:25 PM, "Marty Godsey"  wrote:

I do this by using storage tags. As an example I have some templates that 
are either created on SSD or magnetic storage. The template has a storage tag 
associated with it and then I assigned the appropriate storage tag to the 
primary storage.

Regards,
Marty Godsey

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
Sent: Thursday, September 8, 2016 7:16 PM
To: dev@cloudstack.apache.org
Subject: Re: storage affinity groups

If one doesn't already exist, you can write a custom storage allocator to 
handle this scenario.

> On Sep 8, 2016, at 4:25 PM, Yiping Zhang  wrote:
>
> Hi,  Devs:
>
> We all know how (anti)-host affinity group works in CloudStack,  I am 
wondering if there is a similar concept for (anti)-storage affinity group?
>
> The use case is as this:  in a setup with just one (somewhat) unreliable 
primary storage, if the primary storage is off line, then all VM instances 
would be impacted. Now if we have two primary storage volumes for the cluster, 
then when one of them goes offline, only half of VM instances would be impacted 
(assuming the VM instances are evenly distributed between the two primary 
storage volumes).  Thus, the (anti)-storage affinity groups would make sure 
that instance's disk volumes are distributed among available primary storage 
volumes just like (anti)-host affinity groups would distribute instances among 
hosts.
>
> Does anyone else see the benefits of anti-storage affinity groups?
>
> Yiping




RE: storage affinity groups

2016-09-08 Thread Marty Godsey
So what would be the best way to do it? I use templates to make it simple for 
my users so that the Xen tools are already installed as an example.

Regards,
Marty Godsey

-Original Message-
From: Yiping Zhang [mailto:yzh...@marketo.com] 
Sent: Thursday, September 8, 2016 7:55 PM
To: dev@cloudstack.apache.org
Subject: Re: storage affinity groups

Well, using tags leads to proliferation of templates or service offerings etc. 
It is not very scalable and gets out of hand very quickly.

Yiping

On 9/8/16, 4:25 PM, "Marty Godsey"  wrote:

I do this by using storage tags. As an example I have some templates that 
are either created on SSD or magnetic storage. The template has a storage tag 
associated with it and then I assigned the appropriate storage tag to the 
primary storage.

Regards,
Marty Godsey

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
Sent: Thursday, September 8, 2016 7:16 PM
To: dev@cloudstack.apache.org
Subject: Re: storage affinity groups

If one doesn't already exist, you can write a custom storage allocator to 
handle this scenario.

> On Sep 8, 2016, at 4:25 PM, Yiping Zhang  wrote:
> 
> Hi,  Devs:
> 
> We all know how (anti)-host affinity group works in CloudStack,  I am 
wondering if there is a similar concept for (anti)-storage affinity group?
> 
> The use case is as this:  in a setup with just one (somewhat) unreliable 
primary storage, if the primary storage is off line, then all VM instances 
would be impacted. Now if we have two primary storage volumes for the cluster, 
then when one of them goes offline, only half of VM instances would be impacted 
(assuming the VM instances are evenly distributed between the two primary 
storage volumes).  Thus, the (anti)-storage affinity groups would make sure 
that instance's disk volumes are distributed among available primary storage 
volumes just like (anti)-host affinity groups would distribute instances among 
hosts.
> 
> Does anyone else see the benefits of anti-storage affinity groups?
> 
> Yiping




Re: storage affinity groups

2016-09-08 Thread Yiping Zhang
Well, using tags leads to proliferation of templates or service offerings etc. 
It is not very scalable and gets out of hand very quickly.

Yiping

On 9/8/16, 4:25 PM, "Marty Godsey"  wrote:

I do this by using storage tags. As an example I have some templates that 
are either created on SSD or magnetic storage. The template has a storage tag 
associated with it and then I assigned the appropriate storage tag to the 
primary storage.

Regards,
Marty Godsey

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
Sent: Thursday, September 8, 2016 7:16 PM
To: dev@cloudstack.apache.org
Subject: Re: storage affinity groups

If one doesn't already exist, you can write a custom storage allocator to 
handle this scenario.

> On Sep 8, 2016, at 4:25 PM, Yiping Zhang  wrote:
> 
> Hi,  Devs:
> 
> We all know how (anti)-host affinity group works in CloudStack,  I am 
wondering if there is a similar concept for (anti)-storage affinity group?
> 
> The use case is as this:  in a setup with just one (somewhat) unreliable 
primary storage, if the primary storage is off line, then all VM instances 
would be impacted. Now if we have two primary storage volumes for the cluster, 
then when one of them goes offline, only half of VM instances would be impacted 
(assuming the VM instances are evenly distributed between the two primary 
storage volumes).  Thus, the (anti)-storage affinity groups would make sure 
that instance's disk volumes are distributed among available primary storage 
volumes just like (anti)-host affinity groups would distribute instances among 
hosts.
> 
> Does anyone else see the benefits of anti-storage affinity groups?
> 
> Yiping




RE: storage affinity groups

2016-09-08 Thread Marty Godsey
I do this by using storage tags. As an example I have some templates that are 
either created on SSD or magnetic storage. The template has a storage tag 
associated with it and then I assigned the appropriate storage tag to the 
primary storage.

Regards,
Marty Godsey

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
Sent: Thursday, September 8, 2016 7:16 PM
To: dev@cloudstack.apache.org
Subject: Re: storage affinity groups

If one doesn't already exist, you can write a custom storage allocator to 
handle this scenario.

> On Sep 8, 2016, at 4:25 PM, Yiping Zhang  wrote:
> 
> Hi,  Devs:
> 
> We all know how (anti)-host affinity group works in CloudStack,  I am 
> wondering if there is a similar concept for (anti)-storage affinity group?
> 
> The use case is as this:  in a setup with just one (somewhat) unreliable 
> primary storage, if the primary storage is off line, then all VM instances 
> would be impacted. Now if we have two primary storage volumes for the 
> cluster, then when one of them goes offline, only half of VM instances would 
> be impacted (assuming the VM instances are evenly distributed between the two 
> primary storage volumes).  Thus, the (anti)-storage affinity groups would 
> make sure that instance's disk volumes are distributed among available 
> primary storage volumes just like (anti)-host affinity groups would 
> distribute instances among hosts.
> 
> Does anyone else see the benefits of anti-storage affinity groups?
> 
> Yiping


Re: storage affinity groups

2016-09-08 Thread Tutkowski, Mike
If one doesn't already exist, you can write a custom storage allocator to 
handle this scenario.

> On Sep 8, 2016, at 4:25 PM, Yiping Zhang  wrote:
> 
> Hi,  Devs:
> 
> We all know how (anti)-host affinity group works in CloudStack,  I am 
> wondering if there is a similar concept for (anti)-storage affinity group?
> 
> The use case is as this:  in a setup with just one (somewhat) unreliable 
> primary storage, if the primary storage is off line, then all VM instances 
> would be impacted. Now if we have two primary storage volumes for the 
> cluster, then when one of them goes offline, only half of VM instances would 
> be impacted (assuming the VM instances are evenly distributed between the two 
> primary storage volumes).  Thus, the (anti)-storage affinity groups would 
> make sure that instance’s disk volumes are distributed among available 
> primary storage volumes just like (anti)-host affinity groups would 
> distribute instances among hosts.
> 
> Does anyone else see the benefits of anti-storage affinity groups?
> 
> Yiping


storage affinity groups

2016-09-08 Thread Yiping Zhang
Hi,  Devs:

We all know how (anti)-host affinity group works in CloudStack,  I am wondering 
if there is a similar concept for (anti)-storage affinity group?

The use case is as this:  in a setup with just one (somewhat) unreliable 
primary storage, if the primary storage is off line, then all VM instances 
would be impacted. Now if we have two primary storage volumes for the cluster, 
then when one of them goes offline, only half of VM instances would be impacted 
(assuming the VM instances are evenly distributed between the two primary 
storage volumes).  Thus, the (anti)-storage affinity groups would make sure 
that instance’s disk volumes are distributed among available primary storage 
volumes just like (anti)-host affinity groups would distribute instances among 
hosts.

Does anyone else see the benefits of anti-storage affinity groups?

Yiping


[GitHub] cloudstack issue #1658: Added an additional JSON diff output to the ApiXmlDo...

2016-09-08 Thread swill
Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1658
  
Can we get another code review of this PR so we can get this merged so I 
can submit PRs to include the doc generation scripts to the docs repos which 
depend on this functionality?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


ApacheCon

2016-09-08 Thread Will Stevens
Is anyone planning to represent CloudStack at ApacheCon in Seville?

Cheers,

Will


Apache Board Report

2016-09-08 Thread Will Stevens
Hey All,
I will be working on the report for the Apache meeting later this month.
It needs to be submitted by EOD tomorrow.

Please respond with anything you would like included in the report.

Some items I plan to cover:
- Why is the Github repository move stalled?
- 4.9.0 is out...
- Introducing the new release schedule.  Any notes you guys want to add on
that?

Anything else I should be adding?

Cheers,

Will


Re: Cloud Platform Dashboard's System Capacity is not updated with newly added resources

2016-09-08 Thread Will Stevens
Well it works properly, just not the way people expect. The purpose of that
dashboard is to highlight the
​ cluster
​which is most likely to need capacity changes when doing capacity planning.

​Unfortunately CloudPlatform is behind CloudStack on these features.  In
CloudPlatform it is not possible to get a good summary of the capacity for
the different clusters/hosts.  You basically get the most used cluster and
the global summary, but you have to go and manually audit each host in the
Infrastructure tab to get a clearer picture.  CloudStack has some new
features which CloudPlatform does not which makes visualizing these details
easier in ACS.

​Cheers,

Will​

​

On Sep 8, 2016 2:28 AM, "anil lakineni" 
wrote:

> Hi Will,
>
> Thank you for your inputs and clarifications.
> Yes, I have already seen the reflected resources at Zone tab.
> I thought it was an issue with my CloudPlatform when those were not
> reflected at Dashboard, now i can leave this as the Dashboard wouldn't work
> properly in many cases.
>
> Regards,
> Anil.
>
> On Wed, Sep 7, 2016 at 4:05 PM, Will Stevens 
> wrote:
>
> > I don't have the ui in front of me, so I can't give you specifics.
> >
> > The dashboard does not work how most people expect. The dashboard only
> > shows the most used cluster, which is why it did not change. When you
> click
> > on the dashboard, it will take you to a second screen full of horizontal
> > bars. Those should reflect the total capacity of the system. Hope that
> > helps.
> >
> > Will
> >
> > On Sep 7, 2016 5:45 AM, "anil lakineni"  >
> > wrote:
> >
> > Hi  All,
> >
> > Guys, Can any one help me on this issue.
> > *Newly added resources are not updated in the Dashboard's System Capacity
> > but those new resources are updated in Infrastructure tab's Zone
> > Resources(Infrastructure --> Zone --> Resources)*
> >
> > Thanks,
> > Anil.
> >
> > On Sun, Sep 4, 2016 at 12:13 PM, anil lakineni <
> > anilkumar459.lakin...@gmail.com> wrote:
> >
> > > Greetings All,
> > >
> > > Cloud Platform version is 4.5.0
> > > Existing Cloud Managed Hypervisor version is XenServer 6.2
> > > New Cloud Managed Hypervisor version is XenServer 6.5
> > >
> > > I have successfully added new cluster with Xen 6.5 into Cloud Platform
> > but
> > > the Dashboard's System Capacity is not updated with new resources
> (Except
> > > CPU and Memory resources), but I'm seeing storage resources are updated
> > > with new values.
> > >
> > >
> > > Also, I can see the newly updated resources in Infrastructure tab's
> Zone
> > > Resources(Infrastructure --> Zone --> Resources), but i can't see these
> > > resources in the Dashboard tab.
> > >
> > > Please can anyone suggest me that what I have been missing here to get
> > > changes updated in Dashboard.
> > >
> > > *P.S:* I have restarted Cloud Management service but no luck and I'm
> able
> > > to deploy new VM's in the newly added cluster.
> > >
> > > Looking forward for your valuable suggestions.
> > >
> > > Thanks,
> > > Anil.
> > >
> > >
> > >
> > >
> > >
> >
>


Re: Cloud Platform Dashboard's System Capacity is not updated with newly added resources

2016-09-08 Thread anil lakineni
Hi Will,

Thank you for your inputs and clarifications.
Yes, I have already seen the reflected resources at Zone tab.
I thought it was an issue with my CloudPlatform when those were not
reflected at Dashboard, now i can leave this as the Dashboard wouldn't work
properly in many cases.

Regards,
Anil.

On Wed, Sep 7, 2016 at 4:05 PM, Will Stevens 
wrote:

> I don't have the ui in front of me, so I can't give you specifics.
>
> The dashboard does not work how most people expect. The dashboard only
> shows the most used cluster, which is why it did not change. When you click
> on the dashboard, it will take you to a second screen full of horizontal
> bars. Those should reflect the total capacity of the system. Hope that
> helps.
>
> Will
>
> On Sep 7, 2016 5:45 AM, "anil lakineni" 
> wrote:
>
> Hi  All,
>
> Guys, Can any one help me on this issue.
> *Newly added resources are not updated in the Dashboard's System Capacity
> but those new resources are updated in Infrastructure tab's Zone
> Resources(Infrastructure --> Zone --> Resources)*
>
> Thanks,
> Anil.
>
> On Sun, Sep 4, 2016 at 12:13 PM, anil lakineni <
> anilkumar459.lakin...@gmail.com> wrote:
>
> > Greetings All,
> >
> > Cloud Platform version is 4.5.0
> > Existing Cloud Managed Hypervisor version is XenServer 6.2
> > New Cloud Managed Hypervisor version is XenServer 6.5
> >
> > I have successfully added new cluster with Xen 6.5 into Cloud Platform
> but
> > the Dashboard's System Capacity is not updated with new resources (Except
> > CPU and Memory resources), but I'm seeing storage resources are updated
> > with new values.
> >
> >
> > Also, I can see the newly updated resources in Infrastructure tab's Zone
> > Resources(Infrastructure --> Zone --> Resources), but i can't see these
> > resources in the Dashboard tab.
> >
> > Please can anyone suggest me that what I have been missing here to get
> > changes updated in Dashboard.
> >
> > *P.S:* I have restarted Cloud Management service but no luck and I'm able
> > to deploy new VM's in the newly added cluster.
> >
> > Looking forward for your valuable suggestions.
> >
> > Thanks,
> > Anil.
> >
> >
> >
> >
> >
>