It would be great if we could work together to complete the remaining items.
Including release notes, docs, website updates etc. Haven’t done these myself
and until now someone always stepped in and helped :-)
Thanks,
Remi
On 06/02/16 19:29, "Sebastien Goasguen" wrote:
>
>> On Feb 5, 2016,
Github user ProjectMoon commented on the pull request:
https://github.com/apache/cloudstack/pull/1378#issuecomment-181280984
License header is now in the file. Let's hope the tests succeed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user ProjectMoon commented on the pull request:
https://github.com/apache/cloudstack/pull/1378#issuecomment-181286402
Apparently cloud-utils has a test failure. Will run tests locally and see
what happens.
---
If your project is set up for it, you can reply to this email and h
Github user ProjectMoon commented on the pull request:
https://github.com/apache/cloudstack/pull/1378#issuecomment-181300513
The tests all succeed locally. Looking at the error message, it appears to
be some one-off thing. Will try to force them to run again.
---
If your project is s
John,
Something is not clear to me about the frequency of new LTS releases and
support time range.
You wrote in the proposal, that we branch off for a new LTS version 2
times a year, but only 2 LTS versions will in active maintained at any
time, but supported for 20 months.
This conflicting in m
Github user ProjectMoon commented on the pull request:
https://github.com/apache/cloudstack/pull/1378#issuecomment-181313425
Jenkins failed with a false positive again, similar to another issue I had
with a different pull request.
---
If your project is set up for it, you can reply t
Interesting – yeah, this VR seems to be stuck in the Starting state.
Not sure what to do about it.
As you noted, 4.6 and later behave like this. I can observe the VR entering
the Starting state properly on 4.5.
On Monday, February 8, 2016, Paul Angus wrote:
> Hi Mike,
>
> I have the VR running
Hi Mike,
The reason behind the creation of a SAN snapshot which is exported into
secondary storage, is because creating a copy of the .VHD directly would
impact uptime of the VM as creating that copy take lots of time. Has oppose
to a SAN snapshot that is close to instantaneous which can afterward
To me it sounds like number two and number three are different uses for the
same "thing"(which is totally fine).
As for taking a fast SAN snapshot and exporting it asynchronously, do we
see the SSVM as performing the export?
To be backwards compatible with what we have in 4.6 and later for volume
@Milamber and other internationalisation specialists. I cannot get access
to the spannish strings on transifex. It seems these get mangled into the
source base. for instnce ```label.traffic.type=Tipo de Tráfico``` or
```label.total.of.vm=Total de máquinas virtuales```. Can someone give me
access?
GitHub user remibergsma opened a pull request:
https://github.com/apache/cloudstack/pull/1404
prevent RTNETLINK errors as we were iterating over empty list
Error seen:
RTNETLINK answers: File exists
Integration tests are running, will post results later.
You can merge
I think a service provider backup scenario is more likely to take advantage
of SAN snapshot. There are a few reasons for this. Traditional backups
involve access to the file system, and there is an expectation that this
can be done with reasonably short time frames without negatively impacting
VM p
Mike,
In terms of API's, would you prefer introducing a parameter to the existing
VolumeSnapshot, example: extract={true|false} with a default value of
true which would extract snapshot into the secondary storage, which is the
current default behavior. Then for SAN snapshot that remain on the
Github user ProjectMoon closed the pull request at:
https://github.com/apache/cloudstack/pull/1405
---
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 featu
GitHub user ProjectMoon opened a pull request:
https://github.com/apache/cloudstack/pull/1406
CLOUDSTACK-9280: Allow system VM volumes to be expunged if no system VMs
are remaining.
This pull request is our proposed fix for
https://issues.apache.org/jira/browse/CLOUDSTACK-9280. I a
Github user ProjectMoon commented on the pull request:
https://github.com/apache/cloudstack/pull/1405#issuecomment-181465209
Wrong base branch.
---
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
GitHub user ProjectMoon opened a pull request:
https://github.com/apache/cloudstack/pull/1405
CLOUDSTACK-9280: Allow system VM volumes to be expunged when there are no
system VMs remaining
This pull request is our proposed fix for
https://issues.apache.org/jira/browse/CLOUDSTACK-92
Github user syed commented on the pull request:
https://github.com/apache/cloudstack/pull/1331#issuecomment-181507090
Fixed
---
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
enabl
Hi Pierre-Luc,
My recommendation would be this:
Add an "archive" flag to the current volume-snapshot API. Its default would
be "false" because that would be backward compatible with how 4.6 has
volume snapshots implemented (i.e. they stay on the SAN in 4.6, 4.7, and
4.8).
If you set archive=true
Hi Mike,
Adding a flag to createSnapshot was the first and the most obvious thing
that came to our minds. The problem that I had with this was that:
1) I feel it is exposing something to the end user that is internal to the
cloud.
2) We have to follow two different ways of restore/deletion in th
It's not ideal - true, but it does allow us to be backward compatible.
If you have other ideas, though, about how to maintain backward
compatibility, I'm definitely open to hear them.
Thanks!
On Mon, Feb 8, 2016 at 11:42 AM, Syed Mushtaq
wrote:
> Hi Mike,
>
> Adding a flag to createSnapshot wa
Now that I re-read your e-mail, it dawned on me: The end-user doesn't care
where the snapshot is.
If that's true, then we should perhaps control this via Global Settings or
something.
On Mon, Feb 8, 2016 at 11:46 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> It's not ideal - true,
I don't think a global setting is a good option because we need both
functionality to be available at the same time and for different use cases
to be able to pick which they choose.
*Will STEVENS*
Lead Developer
*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S
That is what I was going to suggest Mike. Add a global setting to be
backwards compatible and add the StorageSnapshot API for doing SAN
snapshots (while the VolumeSnapshots uploads to Sec storage)
On Mon, Feb 8, 2016 at 1:48 PM, Mike Tutkowski wrote:
> Now that I re-read your e-mail, it dawned o
I would hope that default behaviour in CloudStack is the traditional volume
snapshot moved to secondary storage. A global setting to change that
behaviour is probably ok if it is not default, but the user would want to
in certain cases make copies of those snapshots to secondary storage in
addition
So, right now in 4.6, 4.7, and 4.8, the behavior for a managed storage
volume snapshot is for the data to remain on the SAN (not secondary
storage).
It was simply designed as a space-efficient and fast alternative to copying
data to NFS (secondary storage).
What we need to do is somehow maintain
Hey Will,
Who's picking the behavior? Is it the cloud provider or the end user?
Thanks
On Mon, Feb 8, 2016 at 11:52 AM, Will Stevens wrote:
> I don't think a global setting is a good option because we need both
> functionality to be available at the same time and for different use cases
> to b
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 Snap
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
A global setting would probably be fine. How would the case be handled if
the global setting is changed? Would it only affect the snapshots created
after the change was made? We would also code defensively so if the global
setting changes that we don't assume all the snapshots in the past had th
Right, we'd want to keep track of what kind of a volume snapshot was taken
and not assume all in the past were using the same Global Settings value.
On Mon, Feb 8, 2016 at 12:33 PM, Will Stevens wrote:
> A global setting would probably be fine. How would the case be handled if
> the global sett
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 thi
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1361#issuecomment-181569850
@nvazquez I think the job doesn't clean the prior classes well. I cleared
the workspace. Can you push again?
---
If your project is set up for it, you can re
Github user nvazquez commented on the pull request:
https://github.com/apache/cloudstack/pull/1361#issuecomment-181571630
Thanks @DaanHoogland, I pushed again
---
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 projec
Github user nvazquez commented on the pull request:
https://github.com/apache/cloudstack/pull/1361#issuecomment-181644342
This time it failed for timeout
---
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 doe
Github user rafaelweingartner commented on the pull request:
https://github.com/apache/cloudstack/pull/1361#issuecomment-181646167
Since it timed out, what about squashing those 3 last commits into one, and
crossing the fingers hoping that jenkins succeeds.
---
If your project is set
Github user nvazquez commented on the pull request:
https://github.com/apache/cloudstack/pull/1361#issuecomment-181646997
Sure, I'll do it
---
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
Github user kishankavala commented on the pull request:
https://github.com/apache/cloudstack/pull/1361#issuecomment-181715514
@nvazquez
Apologies for reviewing it late.
1. Since version is fetched from image_store_details, can we send a map
with all details for the image_store
38 matches
Mail list logo
