>>
> >>>>> --
> >>>>> Erik
> >>>>>
> >>>>> On Mon, Nov 23, 2015 at 11:16 AM, Nux! wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I think we
>>>>>
>>>>> --
>>>>> Erik
>>>>>
>>>>> On Mon, Nov 23, 2015 at 11:16 AM, Nux! wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I think we do need to mention this i
>>>> Hi,
> >>>>
> >>>> I think we do need to mention this in the notes, if people have the
> >>>> "awsapi" package installed, they should remove it, or we should
> gracefully
> >>>> "obsolete" it from the RPM packaging.
&g
te" it from the RPM packaging.
>>>>
>>>> I had to manually "rpm -e --nodeps cloudstack-awsapi" to avoid conflicts,
>>>> but otherwise the upgrade went fine.
>>>>
>>>> --
>>>> Sent from the Delta quadrant usin
aging.
>>>
>>> I had to manually "rpm -e --nodeps cloudstack-awsapi" to avoid conflicts,
>>> but otherwise the upgrade went fine.
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux
pi" to avoid conflicts,
>> but otherwise the upgrade went fine.
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>> > From: "Sebastien Goasguen"
>&g
; <
> rberg...@schubergphilis.com>, "Pierre-Luc Dion"
> > Sent: Monday, 23 November, 2015 09:53:10
> > Subject: Re: 4.6 release
>
> >> On Nov 21, 2015, at 10:51 AM, Sebastien Goasguen
> wrote:
> >>
> >> Talking about 4.6
> >>
ut
otherwise the upgrade went fine.
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
> From: "Sebastien Goasguen"
> To: dev@cloudstack.apache.org, "Remi Bergsma" ,
> "Pierre-Luc Dion"
> Sent: Monday, 2
> On Nov 21, 2015, at 10:51 AM, Sebastien Goasguen wrote:
>
> Talking about 4.6
>
> There seems to be an issue when people upgrade from 4.5.2 and the awsapi
> package is missing.
>
Ping on this.
Before me make the 4.6 release announcement is there an issue with the
rchitect
>> ShapeBlue Ltd
>> S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
>> paul.an...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue
>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>
>>
>>
>>
>> -Origi
om | www.shapeblue.com | Twitter:@shapeblue
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>
>
>
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Friday, November 20, 2015 11:56 AM
> To: dev
> Subject: Re:
On Fri, Nov 20, 2015 at 2:04 PM, Paul Angus
wrote:
> Which version (noredist or oss) have the packages on cloudstack.apt-get.eu
> been built with?
>
these used to be build noredist. Has anything changed? I think we must
replace them if it has.
--
Daan
ev
Subject: Re: 4.6 release
Paul, this is not helpful. please supply changes for what you would like to see
instead so we can discuss.
On Fri, Nov 20, 2015 at 10:10 AM, Paul Angus
wrote:
> Guys,
>
>
>
> I’m out and about this morning, but I’ve noticed that the release
> notes sta
Paul, this is not helpful. please supply changes for what you would like to
see instead so we can discuss.
On Fri, Nov 20, 2015 at 10:10 AM, Paul Angus
wrote:
> Guys,
>
>
>
> I’m out and about this morning, but I’ve noticed that the release notes
> state that baseurl for 4.6 is http://cloudstack
Guys,
I'm out and about this morning, but I've noticed that the release notes state
that baseurl for 4.6 is http://cloudstack.apt-get.eu/rhel/4.5/
And that somewhat buried in the vmware install information is the fact that the
apt-get repo only includes the oss build.
1. I fundamentally d
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/1071
---
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
Github user DaanHoogland commented on the pull request:
https://github.com/apache/cloudstack/pull/1071#issuecomment-157299325
Had a look yesterday and lgtm, didn't want to comment untill I saw the
test results. (It seemed so small ;)
---
If your project is set up for it, you can rep
Github user wilderrodrigues commented on the pull request:
https://github.com/apache/cloudstack/pull/1071#issuecomment-157286509
Hi @remibergsma and @karuturi
Went through the code, which was quite straight forward. Based on that,
this PR LGTM :+1:
Cheers,
Wilde
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1071#issuecomment-157169270
@DaanHoogland @wilderrodrigues @miguelaferreira Can either of you review so
we can merge this and open master for new features?
---
If your project is set up f
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1071#issuecomment-157168301
LGTM:
```
nosetests --with-marvin --marvin-config=${marvinCfg} -s -a
tags=advanced,required_hardware=true \
component/test_vpc_redundant.py \
Github user karuturi commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1071#discussion_r44907513
--- Diff: build/replace.properties ---
@@ -26,4 +26,4 @@ AGENTLOG=logs/agent.log
MSMNTDIR=/mnt
COMPONENTS-SPEC=components.xml
REMOTEHOST=l
Github user remibergsma commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1071#discussion_r44907228
--- Diff: build/replace.properties ---
@@ -26,4 +26,4 @@ AGENTLOG=logs/agent.log
MSMNTDIR=/mnt
COMPONENTS-SPEC=components.xml
REMOTEHOS
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/1071#issuecomment-156980076
Thanks @karuturi will give it a test-drive soon!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well.
GitHub user karuturi opened a pull request:
https://github.com/apache/cloudstack/pull/1071
Merge 4.6 release branch to master
Initial merge of 4.6 to master
ignored pom.xml version number changes and changes to debian/changelog and
engine/schema/src/com/cloud/upgrade
ev@cloudstack.apache.org>"
Subject: Re: 4.6 release
Ladies & Gents,
I’ve just tried installing the current 4.6 from Jenkins on CentOS 7 it fails to
start the management service completely (Failed at step EXEC spawning
/usr/sbin/tomcat-sysd: No such file or directory) I’ve updated
h
Ladies & Gents,
I've just tried installing the current 4.6 from Jenkins on CentOS 7 it fails to
start the management service completely (Failed at step EXEC spawning
/usr/sbin/tomcat-sysd: No such file or directory) I've updated
https://issues.apache.org/jira/browse/CLOUDSTACK-8812 as CentOS 7
to knock off blockers in this week and create RC
next week.
~Rajani
On Thu, Sep 24, 2015 at 11:45 AM, Rajani Karuturi wrote:
> (resending in plain text)
>
> Thanks Boris(@borisroman) for fixing 3 blockers.
>
> We now have 7 blockers for the 4.6 release
> https://issues.apac
(resending in plain text)
Thanks Boris(@borisroman) for fixing 3 blockers.
We now have 7 blockers for the 4.6 release
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765
Key Summary Assignee Creator
CLOUDSTACK-8881[Blocker] PF , static nat , LB , egress
Thanks Boris(@borisroman) for fixing 3 blockers.
We now have 7 blockers for the 4.6 release
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765
T Key P Summary Assignee Creator [image: Bug]
<https://issues.apache.org/jira/browse/CLOUDSTACK-8881> CLOUDSTACK-8881
ache.org>"
Date: Wednesday 16 September 2015 10:07
To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>"
Subject: Re: [PROPOSAL] stable master and 4.6 release
Based on some discussion from slack, I think there is no harm in experimenting
this for let’s say 2
I think you are being an optimist saying 2-4 weeks but I second the
attempt. +1
On Wed, Sep 16, 2015 at 10:07 AM, Rohit Yadav
wrote:
> Based on some discussion from slack, I think there is no harm in
> experimenting this for let’s say 2-4 weeks; at worst we would have blocked
> people from mergi
Then we create a 4.6.0 branch, fix all of it and allow people to continue to
merge broken code on master. Once we merge 4.6 back to master, most probably
the 4.6 stuff won’t work anymore. I have seen it before.
I would still say +1 for the freeze and suggest that we get the contributors
aligned
Based on some discussion from slack, I think there is no harm in experimenting
this for let’s say 2-4 weeks; at worst we would have blocked people from
merging new features etc.
Remi/Rajani - do you think we can pull this off (fix blockers and do a 4.6.0
release) in next 2-4 weeks?
On 16-Sep-2
> On Sep 16, 2015, at 9:58 AM, Daan Hoogland wrote:
>
> On Wed, Sep 16, 2015 at 9:38 AM, Rohit Yadav
> wrote:
>
>> 1. Only BLOCKER fixes to master. If there's something else that needs to
>> get in, it can be discussed with the RMs on a case-by-case basis.
>>
>>
>> -1 -ish
>> What you’re eff
On Wed, Sep 16, 2015 at 9:38 AM, Rohit Yadav
wrote:
> 1. Only BLOCKER fixes to master. If there's something else that needs to
> get in, it can be discussed with the RMs on a case-by-case basis.
>
>
> -1 -ish
> What you’re effectively saying is to freeze/block master from new changes
> until 4.6.
On 16-Sep-2015, at 11:47 am, Rajani Karuturi
mailto:raj...@apache.org>> wrote:
Here is what we propose:
1. Only BLOCKER fixes to master. If there's something else that needs to
get in, it can be discussed with the RMs on a case-by-case basis.
-1 -ish
What you’re effectively saying is to freeze
e'll have 6-8 blocker issues to resolve. Most
of them are virtual router related and we feel we cannot do a RC without
properly fixing them.
If you have some time, please:
Look at the 4.6 release dashboard:
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=1
RC without
properly fixing them.
If you have some time, please:
Look at the 4.6 release dashboard:
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765
Fix one of the blockers (or critical issues):
https://issues.apache.org/jira/browse/CLOUDSTACK-8697?filter=12332940
means we'll have 6-8 blocker issues to resolve.
> Most
> > of them are virtual router related and we feel we cannot do a RC without
> > properly fixing them.
> >
> >
> > If you have some time, please:
> >
> >
> > Look at the 4.6 releas
C without
> properly fixing them.
>
>
> If you have some time, please:
>
>
> Look at the 4.6 release dashboard:
>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326765
>
>
> Fix one of the blockers (or critical issues):
>
> https:
I never intended for all 6 RM to be involved in every commit. Just to have
6 in order to spread the load. I just want at least two of them to verify
each merge.
Op wo 13 mei 2015 om 18:32 schreef sebgoa :
>
> On May 13, 2015, at 6:07 PM, David Nalley wrote:
>
> > On Wed, May 13, 2015 at 8:36 AM,
On May 13, 2015, at 6:07 PM, David Nalley wrote:
> On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues
> wrote:
>> Hi guys,
>>
>> I hope that’s not too late to react on this one.
>>
>> Having 6 RMs seems a bit too much for me. For PRs containing a few lines of
>> code, just bug fixes or changi
Thanks, David. I really appreciate that!
Should we change the subject to development guidelines? It is also related the
way we commit/push code to git. I can contribute on that by writing a few lines
that would help the community on producing better code (i.e increasing
coverage) and having a c
On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues
wrote:
> Hi guys,
>
> I hope that’s not too late to react on this one.
>
> Having 6 RMs seems a bit too much for me. For PRs containing a few lines of
> code, just bug fixes or changing maven files, python, sh, etc it might be
> simple and quick.
cycle. If we consider we can
do
all
that starting in 4.6, I'm all for it!
Is there really a difference between creating a 4.6 and doing what
you
say, and tagging master (start) and doing it on master leading to
4.6
release ?
Assuming the QA does not improve, 4.6 would not be worse than 4.5.
erre-Luc Dion
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> In my mind it was kind of making more sense to start by keeping 4.6
>>>>>> into
>>
t;>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> In my mind it was kind of making more sense to start by keeping 4.6
> >>>> into
> >>>>>> a
> >>>>>>> separat
;> into
>>>>>> a
>>>>>>> separate branch, enforce pull-requests and deploy the CI. smaller
>> step
>>>>>> but
>>>>>>> faster result, and from there, once we get stable with the CI
>>>>>>
>>&
> but
> >>>>> faster result, and from there, once we get stable with the CI
> >>>>
> >>>> I hear you.
> >>>>
> >>>> But we have waited for way too long for better CI. I see great efforts
> >> in
> >>>>
>>
>>>> I hear you.
>>>>
>>>> But we have waited for way too long for better CI. I see great efforts
>> in
>>>> that direction.
>>>> But I personally do not want to wait any longer to make a move.
>>>>
>>>
tart by keeping
> 4.6
> >> >> into
> >> >>>> a
> >> >>>>> separate branch, enforce pull-requests and deploy the CI. smaller
> >> >>>>> step
> >> >>>> but
> >> >>>>> fast
t;>>>> separate branch, enforce pull-requests and deploy the CI. smaller
>> >>>>> step
>> >>>> but
>> >>>>> faster result, and from there, once we get stable with the CI
>> >>>>
>> >>>> I h
. I see great efforts
> >> in
> >>>> that direction.
> >>>> But I personally do not want to wait any longer to make a move.
> >>>>
> >>>> We do open source, we should have fun, take risks, move fast, fail
> fast,
> >>>&
great efforts
>> in
>>>> that direction.
>>>> But I personally do not want to wait any longer to make a move.
>>>>
>>>> We do open source, we should have fun, take risks, move fast, fail fast,
>>>> recover etc….
>>>>
>
move.
>> >>
>> >> We do open source, we should have fun, take risks, move fast, fail
>> fast,
>> >> recover etc….
>> >>
>> >> so let's JFDI
>> >>
>> >>> and git flow;
>> >>> move into master,
efforts
> in
> >> that direction.
> >> But I personally do not want to wait any longer to make a move.
> >>
> >> We do open source, we should have fun, take risks, move fast, fail fast,
> >> recover etc….
> >>
> >> so let's JFDI
&
e into master, do fastest releases cycle. If we consider we can do all
>>> that starting in 4.6, I'm all for it!
>>
>>
>> Is there really a difference between creating a 4.6 and doing what you
>> say, and tagging master (start) and doing it on master leading to 4.6
n, take risks, move fast, fail fast,
> recover etc….
>
> so let's JFDI
>
> > and git flow;
> > move into master, do fastest releases cycle. If we consider we can do all
> > that starting in 4.6, I'm all for it!
>
>
> Is there really a difference between c
> move into master, do fastest releases cycle. If we consider we can do all
> that starting in 4.6, I'm all for it!
Is there really a difference between creating a 4.6 and doing what you say, and
tagging master (start) and doing it on master leading to 4.6 release ?
Assuming the QA
yes, you do :)
Op vr 1 mei 2015 om 05:00 schreef Abhinandan Prateek <
abhinandan.prat...@shapeblue.com>:
> Guys,
>
> Do I see a QACloud in works, something in line with devcloud but with a
> bigger collection of Hypervisors + marvin ?
> If we can bundle these Hypervisors and QA automation then
Guys,
Do I see a QACloud in works, something in line with devcloud but with a
bigger collection of Hypervisors + marvin ?
If we can bundle these Hypervisors and QA automation then effectively we can
have many more people join our QA effort.
> On 29-Apr-2015, at 9:24 pm, Rohit Yadav wrote:
>
On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen wrote:
>
>> On Apr 29, 2015, at 9:49 PM, Marcus wrote:
>>
>> After reviewing the history as mentioned by Daan, unless we propose
>> and vote on a newer workflow model I think the best we can do is to
>> simply be more strict about commits to mas
Hi,
In my mind it was kind of making more sense to start by keeping 4.6 into a
separate branch, enforce pull-requests and deploy the CI. smaller step but
faster result, and from there, once we get stable with the CI and git flow;
move into master, do fastest releases cycle. If we consider we can d
> On Apr 29, 2015, at 9:49 PM, Marcus wrote:
>
> After reviewing the history as mentioned by Daan, unless we propose
> and vote on a newer workflow model I think the best we can do is to
> simply be more strict about commits to master. They all need to be
> merges that have been tested against m
After reviewing the history as mentioned by Daan, unless we propose
and vote on a newer workflow model I think the best we can do is to
simply be more strict about commits to master. They all need to be
merges that have been tested against master before merge. This will in
theory make master more s
Hi Remi,
Thanks. Sure we can work together on this, I guess you would be running
KVM/XenServer on KVM. Ping me if you need help on running ESX 5.x on KVM as it
requires a patched qemu system binary (prebuilt debs here
http://people.apache.org/~bhaisaab/qemu). If these nested hosts are managed b
Hi Rohit,
Nice work!
I agree we need an environment that does run on something else than the local
machine, as we need more horse power. We worked on something similar, where we
have a cluster of KVM controlled by CloudStack in our Employee Cloud and spin
large VMs running CentOS 7.1 (we use 3
Hi Ilya,
In short - to run ESX and other hypervisors (Xen, KVM, OVM3, HyperV etc) on KVM
you need to;
- use patched qemu (tested to work on both Ubuntu 14.04 and 15.04 x64, I’m
waiting for Fedora 22 to test it on F22 as well), you may install the pre-built
debs or build/install qemu from sourc
Rohit
Any headway on ESX 5.5? I've done this many times before using
cloudstack and esx, but i was using esx as parent hypervisor.
The challenge for me was being able to automatically deploy and
configure the vSphere + ESXi env. I managed to get the whole flow
working with bash script, puppe
undlichen Grüßen / With kind regards,
>
> Swen Brüseke
>
> -Ursprüngliche Nachricht-
> Von: Simon Weller [mailto:swel...@ena.com]
> Gesendet: Montag, 20. April 2015 15:24
> An: dev@cloudstack.apache.org
> Betreff: Re: [DISCUSS] 4.6 release management
>
>>
u fork on your own github, pushes to your own branch will run
through Travis as well.
> best,
> Raja
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Friday, April 17, 2015 1:14 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] 4
On Fri, Apr 24, 2015 at 4:53 PM, Rohit Yadav wrote:
> Daan,
>
>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland wrote:
>>
>> Rohit, the issues you mention are not as painful if we release in a
>> two week schedule as the period of creating a fix to seeing it in a
>> release will be shorter. Some relea
Daan,
> On 24-Apr-2015, at 3:53 pm, Daan Hoogland wrote:
>
> Rohit, the issues you mention are not as painful if we release in a
> two week schedule as the period of creating a fix to seeing it in a
> release will be shorter. Some releases will be broken for some people,
> I don't think we can pr
Rohit, the issues you mention are not as painful if we release in a
two week schedule as the period of creating a fix to seeing it in a
release will be shorter. Some releases will be broken for some people,
I don't think we can prevent this. The target we are aiming for is to
big to cover it comple
I think we need to have a faster release management to speed up process in
general, and for that I propose that we have at least two co-pilots for the
release manager who would support them with things like reviewing/merging
patches, creating RC candidates etc whenever necessary. Having only one
Marcus, I think we decided to take small steps in the direction of
something resambling git-workflow instead of adopting it as a
standard. merging branches for fixes and features was one of those
steps. We had a pre-vote discussion on git-flow and it was rejected as
such. That shouldn't stop us fro
Before I rough draft anything, I just wanted to ask if we had voted on
moving to git-workflow, and dropping the multiple release branch
design. This seems like a significant change, and while good in many
ways, it also seems that many users are seeking for point releases to
their pet version and I'
@gmail.com]
Sent: Friday, April 17, 2015 1:14 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] 4.6 release management
> On Apr 17, 2015, at 6:26 AM, Raja Pullela wrote:
>
> +1 for the "Some people (I'm part of them) are concerned on our current way
> of supp
]
Gesendet: Montag, 20. April 2015 15:24
An: dev@cloudstack.apache.org
Betreff: Re: [DISCUSS] 4.6 release management
>
>From: Sebastien Goasguen
>Sent: Saturday, April 18, 2015 2:50 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCU
>
>From: Sebastien Goasguen
>Sent: Saturday, April 18, 2015 2:50 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] 4.6 release management
> On Apr 18, 2015, at 8:36 AM, Marcus wrote:
>
> Have they diverged that much? Due to
> On Apr 18, 2015, at 8:36 AM, Marcus wrote:
>
> Have they diverged that much? Due to cherry-picking, I guess.
> Otherwise you should be able to do it cleanly.
>
> There's a good opportunity to do this next release. Instead of
> creating a release branch, we freeze master and start creating dev
Have they diverged that much? Due to cherry-picking, I guess.
Otherwise you should be able to do it cleanly.
There's a good opportunity to do this next release. Instead of
creating a release branch, we freeze master and start creating dev
branches.
On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland
We heavily invested in code now on master. Not looking forward to
backporting that.
mobile dev with bilingual spelling checker used (read at your own risk)
Op 17 apr. 2015 21:02 schreef "Marcus" :
> Well, would we just swap the last release branch with master? Master
> is the dev branch, and the
Well, would we just swap the last release branch with master? Master
is the dev branch, and the last release is really what we have as a
stable branch.
On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland wrote:
> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen wrote:
>>
>>> On Apr 17, 2015, at 12
On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen wrote:
>
>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion wrote:
>>
>> Today during the CloudStackdays we did a round table about Release
>> management targeting the next 4.6 releases.
>>
>>
>> Quick bullet point discussions:
>>
>> ideas to cha
; From: Marcus [mailto:shadow...@gmail.com]
> Sent: Friday, April 17, 2015 4:35 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] 4.6 release management
>
> "storage plugin involve changes on Hypervisor code"
>
> I know this is just an example, but at
> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion wrote:
>
> Today during the CloudStackdays we did a round table about Release
> management targeting the next 4.6 releases.
>
>
> Quick bullet point discussions:
>
> ideas to change release planning
>
> - Plugin contribution is complicated b
easing test/BVT coverage, that will be super!
Thanks,
Raja
-Original Message-
From: Marcus [mailto:shadow...@gmail.com]
Sent: Friday, April 17, 2015 4:35 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] 4.6 release management
"storage plugin involve changes on Hypervisor code&q
"storage plugin involve changes on Hypervisor code"
I know this is just an example, but at least on KVM side this is no
longer true. Previously you had to implement a KVM-specific
'StorageAdaptor' that would run on the hypervisor, and register that
with the agent code, but Mike and I added some re
Today during the CloudStackdays we did a round table about Release
management targeting the next 4.6 releases.
Quick bullet point discussions:
ideas to change release planning
- Plugin contribution is complicated because often a new plugin involve
change on the core:
- ex: storage
90 matches
Mail list logo
