[GitHub] cloudstack pull request: Squashing two commits in to single commit

[remibergsma]

Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/1411#issuecomment-183226537
  
Thanks! LGTM, based on #667.

I'd suggest though to make the commit message and PR title more descriptive.


---
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.
---

[GitHub] cloudstack pull request: Add lsb-release dependency to mgmt server...

[ProjectMoon]

GitHub user ProjectMoon opened a pull request:

https://github.com/apache/cloudstack/pull/1412

Add lsb-release dependency to mgmt server on Debian/Ubuntu.

The cloudstack-setup-management script needs the lsb_release command. This 
command is provided by the `lsb-release` package on Debian and Ubuntu, and this 
is not always installed by default. So, it should be added as a dependency to 
cloudstack-management.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/greenqloud/cloudstack pr-lsb-release

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1412.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1412


commit 9222043991ab7c54fe0cd8a431d76327c61d4606
Author: jeff 
Date:   2016-02-12T10:45:44Z

Add lsb-release dependency to mgmt server on Debian/Ubuntu.

Needed because cloudstack-setup-management tries to use lsb-release
command. This is not always installed by default (e.g. on Debian 8).




---
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.
---

[GitHub] cloudstack pull request: Add lsb-release dependency to mgmt server...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/1412#issuecomment-183277819
  
LGTM, simple change


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

Re: [Propose][New Feature] Storage Snapshots

[Syed Mushtaq]

I agree with Mike's concern about backward compatibility. We can add a
global flag which makes sure that the way volume snapshots work currently
on managed storage (stay on the device) is retained after upgrade. We can
then safely implement the Storage Snapshot API while making the Volume
Snpashot API move the snapshot to Secondary Storage.

Sounds good guys?

-Syed


On Mon, Feb 8, 2016 at 2:56 PM, Mike Tutkowski  wrote:

> Here's what we have for snapshots for managed storage as of 4.6, Paul:
>
> 1. VM snapshots (no proposed changes to this).
>
> 2. Volume snapshots that do not end up on secondary storage, but rather are
> stored on a SAN (effectively storing snapshots on primary storage).
>
> Pierre-Luc is saying he'd like this for snapshots for managed storage:
>
> A. VM snapshots (no proposed changes to this).
>
> B. Volume snapshots that export to secondary storage.
>
> C. New: Storage snapshots that behave like 2 (above).
>
> I like Pierre-Luc's ideas there, but the problem is backward compatibility.
>
> If customers who were using managed storage with volume snapshots in 4.6
> were getting their snapshots put on a SAN, then in 4.9 - all of a sudden -
> their new snapshots are put on secondary storage (unless they explicitly
> change over to using the new Storage snapshots feature).
>
>
>
> On Mon, Feb 8, 2016 at 12:32 PM, Paul Angus 
> wrote:
>
> > Just to make sure I'm on the same page, are we talking about;
> > https://issues.apache.org/jira/browse/CLOUDSTACK-9278 ?
> >
> > The FS reads (to me) more like 1a + the possibility to export to
> secondary
> > storage if required?
> > Have I understood correctly?
> > I have seen [1a] implemented for VMware by NetApp in their beta
> CloudStack
> > plugin (pleased I can say that without Mike beating me up now). No
> changes
> > to the CloudStack API were required. (nb it didn't export to secondary
> > storage).
> >
> >
> >
> > 1. VM Snapshot (point-in-time hypervisor based snapshots)
> > 1a. SAN assisted VM snapshots (point-in-time hypervisor snapshot takes
> > place on transparently SAN to avoid performance issue in disk chains)
> > 2. SAN Snapshot (Storage Snapshot) - NEW
> > 3. Volume Snapshot (current old/slow transfer to secstorage)
> > 4. Backup - JUST AN IDEAL.
> >
> >
> >
> >
> > [image: ShapeBlue] 
> > Paul Angus
> > VP Technology ,  ShapeBlue
> > d:  *+44 203 617 0528 | s: +44 203 603 0540*
> > <+44%20203%20617%200528%20%7C%20s:%20+44%20203%20603%200540>  |  m:
> > *+44 7711 418784* <+44%207711%20418784>
> > e:  *paul.an...@shapeblue.com | t: @cloudyangus*
> >   |  w:
> > *www.shapeblue.com* 
> > a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> > 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 SA Pty Ltd is a company registered by The Republic of
> > South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
> is
> > a registered trademark.
> > 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.
> >
> >
> > -Original Message-
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Monday, February 8, 2016 7:16 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [Propose][New Feature] Storage Snapshots
> >
> > Correct, Will.
> >
> > That Global Settings would only be for managed storage. Non-managed
> > (traditional) volume snapshots are completely un-impacted by this
> feature.
> >
> > If we need to sometimes keep the snapshots on the SAN and sometimes push
> > them to secondary storage, we'll need a more robust solution than Global
> > Settings, though.
> >
> > On Mon, Feb 8, 2016 at 12:11 PM, Will Stevens 
> > wrote:
> >
> > > Sorry. I missed a bit of context when I responded. The global setting
> > > would be only for the managed storage case, currently being called
> > Storage
> > > Snapshots, and is only to determine if a copy is pushed to secondary
> > > storage right? The global setting would not change the behavior of the
> > > Volume Snapshots right?
> > >
> > > I was referring to the need for Volume Snapshots and Storage Snapshots
> to
> > > exist together. Disregard my comment. I caught up on context after I
> > > posted. My bad...
> > >
> > > *Will STEVENS*
> > > Lead Developer
> > >
> > > *Clo

Re: [Propose][New Feature] Storage Snapshots

[Mike Tutkowski]

Hi Syed,

Can you clarify how you see these behaviors (below) working now that we are
considering a global settings value applicable to managed storage with
volume snapshots?

State: Global setting value defaults to keep snapshot on storage system
(primary storage) for managed storage.

1) Action: Volume snapshot is taken with managed storage. Result: Snapshot
is taken and kept on storage system (primary storage). (This is what you
and I have been working on for a couple months now.)

Situation: Global setting value is changed to a non-default value.

2) Action: Volume snapshot is taken with managed storage. Result: ??? I'm
not sure which scenario we're looking at here now.

3) Action: Storage snapshot is taken with managed storage. Result: ??? I'm
not sure which scenario we're looking at here now.

Thanks!
Mike

On Fri, Feb 12, 2016 at 9:15 AM, Syed Mushtaq 
wrote:

> I agree with Mike's concern about backward compatibility. We can add a
> global flag which makes sure that the way volume snapshots work currently
> on managed storage (stay on the device) is retained after upgrade. We can
> then safely implement the Storage Snapshot API while making the Volume
> Snpashot API move the snapshot to Secondary Storage.
>
> Sounds good guys?
>
> -Syed
>
>
> On Mon, Feb 8, 2016 at 2:56 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com
> > wrote:
>
> > Here's what we have for snapshots for managed storage as of 4.6, Paul:
> >
> > 1. VM snapshots (no proposed changes to this).
> >
> > 2. Volume snapshots that do not end up on secondary storage, but rather
> are
> > stored on a SAN (effectively storing snapshots on primary storage).
> >
> > Pierre-Luc is saying he'd like this for snapshots for managed storage:
> >
> > A. VM snapshots (no proposed changes to this).
> >
> > B. Volume snapshots that export to secondary storage.
> >
> > C. New: Storage snapshots that behave like 2 (above).
> >
> > I like Pierre-Luc's ideas there, but the problem is backward
> compatibility.
> >
> > If customers who were using managed storage with volume snapshots in 4.6
> > were getting their snapshots put on a SAN, then in 4.9 - all of a sudden
> -
> > their new snapshots are put on secondary storage (unless they explicitly
> > change over to using the new Storage snapshots feature).
> >
> >
> >
> > On Mon, Feb 8, 2016 at 12:32 PM, Paul Angus 
> > wrote:
> >
> > > Just to make sure I'm on the same page, are we talking about;
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-9278 ?
> > >
> > > The FS reads (to me) more like 1a + the possibility to export to
> > secondary
> > > storage if required?
> > > Have I understood correctly?
> > > I have seen [1a] implemented for VMware by NetApp in their beta
> > CloudStack
> > > plugin (pleased I can say that without Mike beating me up now). No
> > changes
> > > to the CloudStack API were required. (nb it didn't export to secondary
> > > storage).
> > >
> > >
> > >
> > > 1. VM Snapshot (point-in-time hypervisor based snapshots)
> > > 1a. SAN assisted VM snapshots (point-in-time hypervisor snapshot takes
> > > place on transparently SAN to avoid performance issue in disk chains)
> > > 2. SAN Snapshot (Storage Snapshot) - NEW
> > > 3. Volume Snapshot (current old/slow transfer to secstorage)
> > > 4. Backup - JUST AN IDEAL.
> > >
> > >
> > >
> > >
> > > [image: ShapeBlue] 
> > > Paul Angus
> > > VP Technology ,  ShapeBlue
> > > d:  *+44 203 617 0528 | s: +44 203 603 0540*
> > > <+44%20203%20617%200528%20%7C%20s:%20+44%20203%20603%200540>  |  m:
> > > *+44 7711 418784* <+44%207711%20418784>
> > > e:  *paul.an...@shapeblue.com | t: @cloudyangus*
> > >   |  w:
> > > *www.shapeblue.com* 
> > > a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> > > 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 SA Pty Ltd is a company registered by The Republic
> of
> > > South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
> > is
> > > a registered trademark.
> > > 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.
> > >
> > >
> > > -Original Message-
> > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > Sent: Monday, February 8, 2016

Proxied management UI no longer opens the virtual console

[Nux!]

Hi,

I'm proxying the cloudstack UI via apache+mod_ssl (easiest way to get ssl 
working) with these options:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
ProxyPass /client ajp://localhost:20400/client
ProxyPassReverse /client ajp://localhost:20400/client

So https://domain.tld/client/ now opens securely the UI.


It used to work great (our production on 4.4 works like this) and I've noticed 
that 4.8 at least kind of breaks when I do this. Everything seems to work 
except the virtual consoles - for any VM.
If I login via the unsecured port 8080 everything works as expected.

Has anyone else seen this?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

[GitHub] cloudstack pull request: CLOUDSTACK-9012 :automation of cores feat...

[NuxRo]

Github user NuxRo commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1011#discussion_r52766006
  
--- Diff: tools/marvin/marvin/config/test_data.py ---
@@ -784,6 +784,18 @@
 "format": "OVA",
 "ispublic": "true"
 },
+"coreos": {
+"displaytext": "coreos",
+"name": "coreos",
+"passwordenabled": False,
+"ostype": "Coreos",
+
"urlvmware":"http://10.147.28.7/templates/coreos/coreos_production_vmware.ova";,
--- End diff --

I am now building OVA files for my templates, CoreOS is done, soon the 
other OSes as well.

Thanks for the help with the conversion script.


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

Re: [Propose][New Feature] Storage Snapshots

[Syed Mushtaq]

> Situation: Global setting value is changed to a non-default value.
>
> 2) Action: Volume snapshot is taken with managed storage. Result: ??? I'm
> not sure which scenario we're looking at here now.
>

In this situation, volume snapshots will end up on secondary storage and
the snapshot on the managed storage will be deleted.


>
> 3) Action: Storage snapshot is taken with managed storage. Result: ??? I'm
> not sure which scenario we're looking at here now.
>

In this situation, the snapshot stays on the managed storage.

Does this answer your question Mike?





On Fri, Feb 12, 2016 at 11:43 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi Syed,
>
> Can you clarify how you see these behaviors (below) working now that we are
> considering a global settings value applicable to managed storage with
> volume snapshots?
>
> State: Global setting value defaults to keep snapshot on storage system
> (primary storage) for managed storage.
>
> 1) Action: Volume snapshot is taken with managed storage. Result: Snapshot
> is taken and kept on storage system (primary storage). (This is what you
> and I have been working on for a couple months now.)
>
>
>
> Thanks!
> Mike
>
> On Fri, Feb 12, 2016 at 9:15 AM, Syed Mushtaq 
> wrote:
>
> > I agree with Mike's concern about backward compatibility. We can add a
> > global flag which makes sure that the way volume snapshots work currently
> > on managed storage (stay on the device) is retained after upgrade. We can
> > then safely implement the Storage Snapshot API while making the Volume
> > Snpashot API move the snapshot to Secondary Storage.
> >
> > Sounds good guys?
> >
> > -Syed
> >
> >
> > On Mon, Feb 8, 2016 at 2:56 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com
> > > wrote:
> >
> > > Here's what we have for snapshots for managed storage as of 4.6, Paul:
> > >
> > > 1. VM snapshots (no proposed changes to this).
> > >
> > > 2. Volume snapshots that do not end up on secondary storage, but rather
> > are
> > > stored on a SAN (effectively storing snapshots on primary storage).
> > >
> > > Pierre-Luc is saying he'd like this for snapshots for managed storage:
> > >
> > > A. VM snapshots (no proposed changes to this).
> > >
> > > B. Volume snapshots that export to secondary storage.
> > >
> > > C. New: Storage snapshots that behave like 2 (above).
> > >
> > > I like Pierre-Luc's ideas there, but the problem is backward
> > compatibility.
> > >
> > > If customers who were using managed storage with volume snapshots in
> 4.6
> > > were getting their snapshots put on a SAN, then in 4.9 - all of a
> sudden
> > -
> > > their new snapshots are put on secondary storage (unless they
> explicitly
> > > change over to using the new Storage snapshots feature).
> > >
> > >
> > >
> > > On Mon, Feb 8, 2016 at 12:32 PM, Paul Angus 
> > > wrote:
> > >
> > > > Just to make sure I'm on the same page, are we talking about;
> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-9278 ?
> > > >
> > > > The FS reads (to me) more like 1a + the possibility to export to
> > > secondary
> > > > storage if required?
> > > > Have I understood correctly?
> > > > I have seen [1a] implemented for VMware by NetApp in their beta
> > > CloudStack
> > > > plugin (pleased I can say that without Mike beating me up now). No
> > > changes
> > > > to the CloudStack API were required. (nb it didn't export to
> secondary
> > > > storage).
> > > >
> > > >
> > > >
> > > > 1. VM Snapshot (point-in-time hypervisor based snapshots)
> > > > 1a. SAN assisted VM snapshots (point-in-time hypervisor snapshot
> takes
> > > > place on transparently SAN to avoid performance issue in disk chains)
> > > > 2. SAN Snapshot (Storage Snapshot) - NEW
> > > > 3. Volume Snapshot (current old/slow transfer to secstorage)
> > > > 4. Backup - JUST AN IDEAL.
> > > >
> > > >
> > > >
> > > >
> > > > [image: ShapeBlue] 
> > > > Paul Angus
> > > > VP Technology ,  ShapeBlue
> > > > d:  *+44 203 617 0528 | s: +44 203 603 0540*
> > > > <+44%20203%20617%200528%20%7C%20s:%20+44%20203%20603%200540>  |  m:
> > > > *+44 7711 418784* <+44%207711%20418784>
> > > > e:  *paul.an...@shapeblue.com | t: @cloudyangus*
> > > >   |  w:
> > > > *www.shapeblue.com* 
> > > > a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> > > > 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 SA Pty Ltd is a company registered by The
> Republic
> > of
> > > > South Africa and is traded under license from Shape Blue Ltd.
> ShapeBlue
> > > is
> > > > a registered trademark.
> > > > This email and any attachments to it may be confidential and are
> > intended
> > > > solely for the use of the individual 

Re: [Propose][New Feature] Storage Snapshots

[Mike Tutkowski]

I think so.

Just to confirm: The default behavior for a volume snapshot with managed
storage is equivalent to a storage snapshot.

When the global setting value is changed, the data ends up on secondary
storage (NFS).

Is that accurate?

On Friday, February 12, 2016, Syed Mushtaq  wrote:

> > Situation: Global setting value is changed to a non-default value.
> >
> > 2) Action: Volume snapshot is taken with managed storage. Result: ??? I'm
> > not sure which scenario we're looking at here now.
> >
>
> In this situation, volume snapshots will end up on secondary storage and
> the snapshot on the managed storage will be deleted.
>
>
> >
> > 3) Action: Storage snapshot is taken with managed storage. Result: ???
> I'm
> > not sure which scenario we're looking at here now.
> >
>
> In this situation, the snapshot stays on the managed storage.
>
> Does this answer your question Mike?
>
>
>
>
>
> On Fri, Feb 12, 2016 at 11:43 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com > wrote:
>
> > Hi Syed,
> >
> > Can you clarify how you see these behaviors (below) working now that we
> are
> > considering a global settings value applicable to managed storage with
> > volume snapshots?
> >
> > State: Global setting value defaults to keep snapshot on storage system
> > (primary storage) for managed storage.
> >
> > 1) Action: Volume snapshot is taken with managed storage. Result:
> Snapshot
> > is taken and kept on storage system (primary storage). (This is what you
> > and I have been working on for a couple months now.)
> >
> >
> >
> > Thanks!
> > Mike
> >
> > On Fri, Feb 12, 2016 at 9:15 AM, Syed Mushtaq 
> > wrote:
> >
> > > I agree with Mike's concern about backward compatibility. We can add a
> > > global flag which makes sure that the way volume snapshots work
> currently
> > > on managed storage (stay on the device) is retained after upgrade. We
> can
> > > then safely implement the Storage Snapshot API while making the Volume
> > > Snpashot API move the snapshot to Secondary Storage.
> > >
> > > Sounds good guys?
> > >
> > > -Syed
> > >
> > >
> > > On Mon, Feb 8, 2016 at 2:56 PM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com
> > > > wrote:
> > >
> > > > Here's what we have for snapshots for managed storage as of 4.6,
> Paul:
> > > >
> > > > 1. VM snapshots (no proposed changes to this).
> > > >
> > > > 2. Volume snapshots that do not end up on secondary storage, but
> rather
> > > are
> > > > stored on a SAN (effectively storing snapshots on primary storage).
> > > >
> > > > Pierre-Luc is saying he'd like this for snapshots for managed
> storage:
> > > >
> > > > A. VM snapshots (no proposed changes to this).
> > > >
> > > > B. Volume snapshots that export to secondary storage.
> > > >
> > > > C. New: Storage snapshots that behave like 2 (above).
> > > >
> > > > I like Pierre-Luc's ideas there, but the problem is backward
> > > compatibility.
> > > >
> > > > If customers who were using managed storage with volume snapshots in
> > 4.6
> > > > were getting their snapshots put on a SAN, then in 4.9 - all of a
> > sudden
> > > -
> > > > their new snapshots are put on secondary storage (unless they
> > explicitly
> > > > change over to using the new Storage snapshots feature).
> > > >
> > > >
> > > >
> > > > On Mon, Feb 8, 2016 at 12:32 PM, Paul Angus <
> paul.an...@shapeblue.com>
> > > > wrote:
> > > >
> > > > > Just to make sure I'm on the same page, are we talking about;
> > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-9278 ?
> > > > >
> > > > > The FS reads (to me) more like 1a + the possibility to export to
> > > > secondary
> > > > > storage if required?
> > > > > Have I understood correctly?
> > > > > I have seen [1a] implemented for VMware by NetApp in their beta
> > > > CloudStack
> > > > > plugin (pleased I can say that without Mike beating me up now). No
> > > > changes
> > > > > to the CloudStack API were required. (nb it didn't export to
> > secondary
> > > > > storage).
> > > > >
> > > > >
> > > > >
> > > > > 1. VM Snapshot (point-in-time hypervisor based snapshots)
> > > > > 1a. SAN assisted VM snapshots (point-in-time hypervisor snapshot
> > takes
> > > > > place on transparently SAN to avoid performance issue in disk
> chains)
> > > > > 2. SAN Snapshot (Storage Snapshot) - NEW
> > > > > 3. Volume Snapshot (current old/slow transfer to secstorage)
> > > > > 4. Backup - JUST AN IDEAL.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [image: ShapeBlue] 
> > > > > Paul Angus
> > > > > VP Technology ,  ShapeBlue
> > > > > d:  *+44 203 617 0528 | s: +44 203 603 0540*
> > > > > <+44%20203%20617%200528%20%7C%20s:%20+44%20203%20603%200540>  |  m:
> > > > > *+44 7711 418784* <+44%207711%20418784>
> > > > > e:  *paul.an...@shapeblue.com | t: @cloudyangus*
> > > > >   |  w:
> > > > > *www.shapeblue.com* 
> > > > > a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> > > > > Shape Blue Ltd is a company incorporated in England & Wales.
> > Sha

Re: [Propose][New Feature] Storage Snapshots

[Syed Mushtaq]

Correct. Keeping the snapshot on managed storage should be the default
behaviour as it will not break backward compatibility.

-Syed


On Fri, Feb 12, 2016 at 12:02 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I think so.
>
> Just to confirm: The default behavior for a volume snapshot with managed
> storage is equivalent to a storage snapshot.
>
> When the global setting value is changed, the data ends up on secondary
> storage (NFS).
>
> Is that accurate?
>
> On Friday, February 12, 2016, Syed Mushtaq 
> wrote:
>
> > > Situation: Global setting value is changed to a non-default value.
> > >
> > > 2) Action: Volume snapshot is taken with managed storage. Result: ???
> I'm
> > > not sure which scenario we're looking at here now.
> > >
> >
> > In this situation, volume snapshots will end up on secondary storage and
> > the snapshot on the managed storage will be deleted.
> >
> >
> > >
> > > 3) Action: Storage snapshot is taken with managed storage. Result: ???
> > I'm
> > > not sure which scenario we're looking at here now.
> > >
> >
> > In this situation, the snapshot stays on the managed storage.
> >
> > Does this answer your question Mike?
> >
> >
> >
> >
> >
> > On Fri, Feb 12, 2016 at 11:43 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com > wrote:
> >
> > > Hi Syed,
> > >
> > > Can you clarify how you see these behaviors (below) working now that we
> > are
> > > considering a global settings value applicable to managed storage with
> > > volume snapshots?
> > >
> > > State: Global setting value defaults to keep snapshot on storage system
> > > (primary storage) for managed storage.
> > >
> > > 1) Action: Volume snapshot is taken with managed storage. Result:
> > Snapshot
> > > is taken and kept on storage system (primary storage). (This is what
> you
> > > and I have been working on for a couple months now.)
> > >
> > >
> > >
> > > Thanks!
> > > Mike
> > >
> > > On Fri, Feb 12, 2016 at 9:15 AM, Syed Mushtaq  >
> > > wrote:
> > >
> > > > I agree with Mike's concern about backward compatibility. We can add
> a
> > > > global flag which makes sure that the way volume snapshots work
> > currently
> > > > on managed storage (stay on the device) is retained after upgrade. We
> > can
> > > > then safely implement the Storage Snapshot API while making the
> Volume
> > > > Snpashot API move the snapshot to Secondary Storage.
> > > >
> > > > Sounds good guys?
> > > >
> > > > -Syed
> > > >
> > > >
> > > > On Mon, Feb 8, 2016 at 2:56 PM, Mike Tutkowski <
> > > > mike.tutkow...@solidfire.com
> > > > > wrote:
> > > >
> > > > > Here's what we have for snapshots for managed storage as of 4.6,
> > Paul:
> > > > >
> > > > > 1. VM snapshots (no proposed changes to this).
> > > > >
> > > > > 2. Volume snapshots that do not end up on secondary storage, but
> > rather
> > > > are
> > > > > stored on a SAN (effectively storing snapshots on primary storage).
> > > > >
> > > > > Pierre-Luc is saying he'd like this for snapshots for managed
> > storage:
> > > > >
> > > > > A. VM snapshots (no proposed changes to this).
> > > > >
> > > > > B. Volume snapshots that export to secondary storage.
> > > > >
> > > > > C. New: Storage snapshots that behave like 2 (above).
> > > > >
> > > > > I like Pierre-Luc's ideas there, but the problem is backward
> > > > compatibility.
> > > > >
> > > > > If customers who were using managed storage with volume snapshots
> in
> > > 4.6
> > > > > were getting their snapshots put on a SAN, then in 4.9 - all of a
> > > sudden
> > > > -
> > > > > their new snapshots are put on secondary storage (unless they
> > > explicitly
> > > > > change over to using the new Storage snapshots feature).
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Feb 8, 2016 at 12:32 PM, Paul Angus <
> > paul.an...@shapeblue.com>
> > > > > wrote:
> > > > >
> > > > > > Just to make sure I'm on the same page, are we talking about;
> > > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-9278 ?
> > > > > >
> > > > > > The FS reads (to me) more like 1a + the possibility to export to
> > > > > secondary
> > > > > > storage if required?
> > > > > > Have I understood correctly?
> > > > > > I have seen [1a] implemented for VMware by NetApp in their beta
> > > > > CloudStack
> > > > > > plugin (pleased I can say that without Mike beating me up now).
> No
> > > > > changes
> > > > > > to the CloudStack API were required. (nb it didn't export to
> > > secondary
> > > > > > storage).
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1. VM Snapshot (point-in-time hypervisor based snapshots)
> > > > > > 1a. SAN assisted VM snapshots (point-in-time hypervisor snapshot
> > > takes
> > > > > > place on transparently SAN to avoid performance issue in disk
> > chains)
> > > > > > 2. SAN Snapshot (Storage Snapshot) - NEW
> > > > > > 3. Volume Snapshot (current old/slow transfer to secstorage)
> > > > > > 4. Backup - JUST AN IDEAL.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > [image: ShapeBlue] 

Re: [Propose][New Feature] Storage Snapshots

[Mike Tutkowski]

OK, then - perfect. I agree with this approach.

Global setting's value for volume snapshots on managed storage:

Default value: Volume snapshot on managed storage = storage snapshot

Non-default value: Take snapshot on primary storage, but move it to NFS.

On Fri, Feb 12, 2016 at 10:04 AM, Syed Mushtaq 
wrote:

> Correct. Keeping the snapshot on managed storage should be the default
> behaviour as it will not break backward compatibility.
>
> -Syed
>
>
> On Fri, Feb 12, 2016 at 12:02 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > I think so.
> >
> > Just to confirm: The default behavior for a volume snapshot with managed
> > storage is equivalent to a storage snapshot.
> >
> > When the global setting value is changed, the data ends up on secondary
> > storage (NFS).
> >
> > Is that accurate?
> >
> > On Friday, February 12, 2016, Syed Mushtaq 
> > wrote:
> >
> > > > Situation: Global setting value is changed to a non-default value.
> > > >
> > > > 2) Action: Volume snapshot is taken with managed storage. Result: ???
> > I'm
> > > > not sure which scenario we're looking at here now.
> > > >
> > >
> > > In this situation, volume snapshots will end up on secondary storage
> and
> > > the snapshot on the managed storage will be deleted.
> > >
> > >
> > > >
> > > > 3) Action: Storage snapshot is taken with managed storage. Result:
> ???
> > > I'm
> > > > not sure which scenario we're looking at here now.
> > > >
> > >
> > > In this situation, the snapshot stays on the managed storage.
> > >
> > > Does this answer your question Mike?
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Feb 12, 2016 at 11:43 AM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com > wrote:
> > >
> > > > Hi Syed,
> > > >
> > > > Can you clarify how you see these behaviors (below) working now that
> we
> > > are
> > > > considering a global settings value applicable to managed storage
> with
> > > > volume snapshots?
> > > >
> > > > State: Global setting value defaults to keep snapshot on storage
> system
> > > > (primary storage) for managed storage.
> > > >
> > > > 1) Action: Volume snapshot is taken with managed storage. Result:
> > > Snapshot
> > > > is taken and kept on storage system (primary storage). (This is what
> > you
> > > > and I have been working on for a couple months now.)
> > > >
> > > >
> > > >
> > > > Thanks!
> > > > Mike
> > > >
> > > > On Fri, Feb 12, 2016 at 9:15 AM, Syed Mushtaq <
> syed1.mush...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > I agree with Mike's concern about backward compatibility. We can
> add
> > a
> > > > > global flag which makes sure that the way volume snapshots work
> > > currently
> > > > > on managed storage (stay on the device) is retained after upgrade.
> We
> > > can
> > > > > then safely implement the Storage Snapshot API while making the
> > Volume
> > > > > Snpashot API move the snapshot to Secondary Storage.
> > > > >
> > > > > Sounds good guys?
> > > > >
> > > > > -Syed
> > > > >
> > > > >
> > > > > On Mon, Feb 8, 2016 at 2:56 PM, Mike Tutkowski <
> > > > > mike.tutkow...@solidfire.com
> > > > > > wrote:
> > > > >
> > > > > > Here's what we have for snapshots for managed storage as of 4.6,
> > > Paul:
> > > > > >
> > > > > > 1. VM snapshots (no proposed changes to this).
> > > > > >
> > > > > > 2. Volume snapshots that do not end up on secondary storage, but
> > > rather
> > > > > are
> > > > > > stored on a SAN (effectively storing snapshots on primary
> storage).
> > > > > >
> > > > > > Pierre-Luc is saying he'd like this for snapshots for managed
> > > storage:
> > > > > >
> > > > > > A. VM snapshots (no proposed changes to this).
> > > > > >
> > > > > > B. Volume snapshots that export to secondary storage.
> > > > > >
> > > > > > C. New: Storage snapshots that behave like 2 (above).
> > > > > >
> > > > > > I like Pierre-Luc's ideas there, but the problem is backward
> > > > > compatibility.
> > > > > >
> > > > > > If customers who were using managed storage with volume snapshots
> > in
> > > > 4.6
> > > > > > were getting their snapshots put on a SAN, then in 4.9 - all of a
> > > > sudden
> > > > > -
> > > > > > their new snapshots are put on secondary storage (unless they
> > > > explicitly
> > > > > > change over to using the new Storage snapshots feature).
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Feb 8, 2016 at 12:32 PM, Paul Angus <
> > > paul.an...@shapeblue.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Just to make sure I'm on the same page, are we talking about;
> > > > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-9278 ?
> > > > > > >
> > > > > > > The FS reads (to me) more like 1a + the possibility to export
> to
> > > > > > secondary
> > > > > > > storage if required?
> > > > > > > Have I understood correctly?
> > > > > > > I have seen [1a] implemented for VMware by NetApp in their beta
> > > > > > CloudStack
> > > > > > > plugin (pleased I can say that without Mike beating me up now).
> > No
> > > > > > changes
> > > > >

Re: Proxied management UI no longer opens the virtual console

[Nux!]

Ok, ignore. It's just me being stupid.

Firefox (Chrome too) decided I should not be able to access http content linked 
from a https page ...

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nux!" 
> To: "dev" 
> Sent: Friday, 12 February, 2016 16:44:39
> Subject: Proxied management UI no longer opens the virtual console

> Hi,
> 
> I'm proxying the cloudstack UI via apache+mod_ssl (easiest way to get ssl
> working) with these options:
> 
> LoadModule proxy_module modules/mod_proxy.so
> LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
> ProxyPass /client ajp://localhost:20400/client
> ProxyPassReverse /client ajp://localhost:20400/client
> 
> So https://domain.tld/client/ now opens securely the UI.
> 
> 
> It used to work great (our production on 4.4 works like this) and I've noticed
> that 4.8 at least kind of breaks when I do this. Everything seems to work
> except the virtual consoles - for any VM.
> If I login via the unsecured port 8080 everything works as expected.
> 
> Has anyone else seen this?
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

[GitHub] cloudstack pull request: CLOUDSTACK-9012 :automation of cores feat...

[bhaisaab]

Github user bhaisaab commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1011#discussion_r52769282
  
--- Diff: tools/marvin/marvin/config/test_data.py ---
@@ -784,6 +784,18 @@
 "format": "OVA",
 "ispublic": "true"
 },
+"coreos": {
+"displaytext": "coreos",
+"name": "coreos",
+"passwordenabled": False,
+"ostype": "Coreos",
+
"urlvmware":"http://10.147.28.7/templates/coreos/coreos_production_vmware.ova";,
--- End diff --

Great, thanks @NuxRo 


---
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.
---

Build failed in Jenkins: build-master-slowbuild #3221

[jenkins]

See 

--
[...truncated 824 lines...]
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
2016-02-13 05:13:22,218 DEBUG [utils.script.Script] (main:) Executing: 
/bin/bash -c /not/existing/scripts/1455340402218 
2016-02-13 05:13:22,220 DEBUG [utils.script.Script] (main:) Exit value is 127
2016-02-13 05:13:22,221 DEBUG [utils.script.Script] (main:) /bin/bash: 
/not/existing/scripts/1455340402218: No such file or directory
2016-02-13 05:13:22,222 DEBUG [utils.script.Script] (main:) Executing: 
/bin/bash -c echo 'hello world!' 
2016-02-13 05:13:22,225 DEBUG [utils.script.Script] (main:) Execution is 
successful.
2016-02-13 05:13:22,226 DEBUG [utils.script.Script] (main:) Executing: 
/bin/bash -c echo 'hello world!' 
2016-02-13 05:13:22,228 DEBUG [utils.script.Script] (main:) Execution is 
successful.
Tests run: 10, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.062 sec - in 
com.cloud.utils.ScriptTest
Running com.cloud.utils.TestProfiler
Configure log4j with default properties
2016-02-13 05:13:22,256 INFO  [cloud.utils.TestProfiler] (main:) testProfiler() 
started
2016-02-13 05:13:23,267 INFO  [cloud.utils.TestProfiler] (main:) Duration in 
Millis: 1010
2016-02-13 05:13:23,267 INFO  [cloud.utils.TestProfiler] (main:) testProfiler() 
stopped
Configure log4j with default properties
Configure log4j with default properties
2016-02-13 05:13:24,299 INFO  [cloud.utils.TestProfiler] (main:) Duration in 
Nano: 1010151554
Configure log4j with default properties
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.066 sec - in 
com.cloud.utils.TestProfiler
Running com.cloud.utils.net.NetUtilsTest
2016-02-13 05:13:24,336 INFO  [utils.net.NetUtils] (main:) Invalid value of 
cidr 10.3.6.5/50
2016-02-13 05:13:24,345 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::1
2016-02-13 05:13:24,346 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::1
2016-02-13 05:13:24,347 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::2
2016-02-13 05:13:24,349 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::1
2016-02-13 05:13:24,350 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::1
2016-02-13 05:13:24,351 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::c38e:6470:191:32f3
2016-02-13 05:13:24,353 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::eb40:9e49:5a7:cbfe
2016-02-13 05:13:24,355 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::ef0d:6b6f:b360:e201
2016-02-13 05:13:24,356 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::e529:b43a:af7:289b
2016-02-13 05:13:24,358 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::3975:63ba:14b0:f4a
2016-02-13 05:13:24,360 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::d666:1c05:be1e:9ea5
2016-02-13 05:13:24,361 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::dca7:c5fc:b2a9:a87c
2016-02-13 05:13:24,363 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::2a04:7ba0:ec8e:53f
2016-02-13 05:13:24,364 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::4278:7a6e:def5:ca88
2016-02-13 05:13:24,366 INFO  [utils.net.NetUtilsTest] (main:) IP is 
1234:5678::5cec:158a:5cf8:350b
2016-02-13 05:13:24,383 ERROR [utils.net.NetUtils] (main:) empty cidr can not 
be converted to longs
com.cloud.utils.exception.CloudRuntimeException: empty cidr can not be 
converted to longs
at com.cloud.utils.net.NetUtils.cidrToLong(NetUtils.java:887)
at com.cloud.utils.net.NetUtils.isNetworksOverlap(NetUtils.java:1174)
at 
com.cloud.utils.net.NetUtilsTest.testIsNetworksOverlapWithEmptyValues(NetUtilsTest.java:509)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner