Re: [VOTE] Move forward with 4.1 without a Xen-specific fix for CLOUDSTACK-2492?

[Outback Dingo]

On Mon, May 20, 2013 at 4:15 PM, Chip Childers wrote:

> All,
>
> As discussed on another thread [1], we identified a bug
> (CLOUDSTACK-2492) in the current 3.x system VMs, where the System VMs
> are not configured to sync their time with either the host HV or an NTP
> service.  That bug affects the system VMs for all three primary HVs (KVM,
> Xen and vSphere).  Patches have been committed addressing vSphere and
> KVM.  It appears that a correction for Xen would require the re-build of
> a system VM image and a full round of regression testing that image.
>
> Given that the discussion thread has not resulted in a consensus on this
> issue, I unfortunately believe that the only path forward is to call for
> a formal VOTE.
>
> Please respond with one of the following:
>
> +1: proceed with 4.1 without the Xen portion of CLOUDSTACK-2492 being
> resolved
> +0: don't care one way or the other
> -1: do *not* proceed with any further 4.1 release candidates until
> CLOUDSTACK-2492 has been fully resolved
>
>
-1  do *not* proceed


> -chip
>
> [1] http://markmail.org/message/rw7vciq3r33biasb
>

Re: [VOTE] Move forward with 4.1 without a Xen-specific fix for CLOUDSTACK-2492?

[Outback Dingo]

On Tue, May 21, 2013 at 10:17 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> Outback, it would be helpful to understand the harm you are facing without
> this fix.
> Are you operating a CloudStack cloud already? Have you lost Vms/ lost data
> / faced unexplained crashes, or found your cloud unavailable due to this?
> Note that this bug has been there since 2.2
>
>
It would break a current migration path to s3 storage capabilities
currently being rolled out for XEN based hypervisors
as it was mentioned in the thread. This negates our and others capabilities
to be inline with other Hypervisors, and
having to wait until a fix/patch can be applied. It also negates current
infrastructure design for commercial
and private clouds based on XEN/XCP for a more robust storage
infrastructure then is currently capable.

IMHO, aside from the technical details, your basically telling all XEN
infrastructure, too bad. no new s3 infrastructure for you, from my
perspective this is both bad practice, and again, leaves XEN/XCP users
wanting, and waiting again.


> On 5/21/13 5:59 PM, "Outback Dingo"  wrote:
>
> >On Mon, May 20, 2013 at 4:15 PM, Chip Childers
> >wrote:
> >
> >> All,
> >>
> >> As discussed on another thread [1], we identified a bug
> >> (CLOUDSTACK-2492) in the current 3.x system VMs, where the System VMs
> >> are not configured to sync their time with either the host HV or an NTP
> >> service.  That bug affects the system VMs for all three primary HVs
> >>(KVM,
> >> Xen and vSphere).  Patches have been committed addressing vSphere and
> >> KVM.  It appears that a correction for Xen would require the re-build of
> >> a system VM image and a full round of regression testing that image.
> >>
> >> Given that the discussion thread has not resulted in a consensus on this
> >> issue, I unfortunately believe that the only path forward is to call for
> >> a formal VOTE.
> >>
> >> Please respond with one of the following:
> >>
> >> +1: proceed with 4.1 without the Xen portion of CLOUDSTACK-2492 being
> >> resolved
> >> +0: don't care one way or the other
> >> -1: do *not* proceed with any further 4.1 release candidates until
> >> CLOUDSTACK-2492 has been fully resolved
> >>
> >>
> >-1  do *not* proceed
> >
> >
> >> -chip
> >>
> >> [1] http://markmail.org/message/rw7vciq3r33biasb
> >>
>
>

Re: [VOTE] Move forward with 4.1 without a Xen-specific fix for CLOUDSTACK-2492?

[Outback Dingo]

On Wed, May 22, 2013 at 12:11 PM, Joe Brockmeier  wrote:

> On Wed, May 22, 2013, at 10:51 AM, John Burwell wrote:
> > I would say that the only thing for an open source project worse than not
> > releasing is releasing a poor quality release.  A late release with high
> > quality is soon forgotten.  An on-time or late release with poor quality
> > lingers in folks memory. The KDE project made the near fatal mistake of
> > following the same logic when they release 4.0, and the reputation of KDE
> > 4.x continues to suffer from it to this day.  CloudStack is trusted to
> > run at the core our user's operations.  In my view, if we err, we should
> > err on the side of quality to avoid of erosion of that trust.  If we ever
> > lost that trust, our new features would never be evaluated.
>
> I'm not sure this issue approaches KDE 4.0 levels, but otherwise +1.
> (Note - the KDE folks are *very* touchy about 4.0 *still* being held up
> as a high-water mark of poor judgement in releases, which is in and of
> itself a cautionary tale for releasing something that's not ready...)
>
> Why are users waiting for us to officially release instead of grabbing
> artifacts from Jenkins? In large part, they're waiting for the project
> to "bless" the quality of the release by saying it's ready. Time-based
> releases are supposed to be a way of ensuring that we don't hold up
> releases indefinitely because of missing features - but I don't think
> that extends to knowingly releasing something that is a pretty serious
> bug.
>
>
The quality of software and its new feature sets, if supported should all
fall in parity with supported platforms
The fact that 1) this is a critical bug, 2) it affects the entire XEN/XCP
base, 3) has been known and not resolved

While being at a senior level management position running an R&D team, I
would always tell the CTO/CEO
If its not fully baked and QA's its not ready to come out of the oven. Push
the date. Id rather see CS as a whole
remain in feature parity and crush this last critical bug then push out a
release, and discourage any XEN/XCP
environments from looking at moving forward with the software stack as a
whole. I wouldnt do it to clients, I feel
we shouldnt do it to our users. resolve the problem, and QA it, then move
forward, dont bandaid it, dont neglect it
if others are so gung ho to user 4.1 before its released they can build
from source, there are options for moving
forward, leaving this stone unturned i feel would be detrimental to the
good reputation Cs had enjoyed. I usually
say much, until I feel strongly about an issue. But I ask, have we even
really assessed what it will take to fix,
instead of just throwing it to the wolves to vote on? will it take a week,
to resolve and test. If we cant answer
this question, then we shouldnt even be having the voting discussion, let
alone how longs it been a "known"
issue, regardless of who noticed or who it affected, the fact is someone
noticed it, otherwise there woulnt be a bug report on it. so we just
answered logically who noticed, someone did, whos it affect, well obviously
it did affect
someone. fix it, qa it, release and moved forward before we get to far down
the road and its harder to resolv.



> Best,
>
> jzb
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>

Re: 4.1 release manager

[Outback Dingo]

On Sat, May 25, 2013 at 10:06 AM, Sebastien Goasguen wrote:

> Hi folks,
>
> Some time back I offered to be RM for 4.1.x , since then I took on the
> GSoC effort and won't have time to be the RM.
>
> Therefore the position is up for grabs.
>
> Any takers ?
>

can we get a brief description of the responsibilities? I just might be
interested


>
> -Sebastien

Re: 4.1 release manager

[Outback Dingo]

On Sat, May 25, 2013 at 10:33 AM, Chip Childers
wrote:

> On May 25, 2013, at 10:16 AM, Sebastien Goasguen  wrote:
>
> >
> > On May 25, 2013, at 10:08 AM, Outback Dingo 
> wrote:
> >
> >> On Sat, May 25, 2013 at 10:06 AM, Sebastien Goasguen  >wrote:
> >>
> >>> Hi folks,
> >>>
> >>> Some time back I offered to be RM for 4.1.x , since then I took on the
> >>> GSoC effort and won't have time to be the RM.
> >>>
> >>> Therefore the position is up for grabs.
> >>>
> >>> Any takers ?
> >>
> >> can we get a brief description of the responsibilities? I just might be
> >> interested
> >
> > You would be responsible to get the 4.1.x releases out the door. Keep
> track of the JIRA bugs that need to be applied to the 4.1 branch,
> cherry-pick them, do some minimal testing and conflict resolution. Then
> prepare the source artifacts, signature, release notes. And finally start
> the [VOTE] threads.
> >
> > Basically what Joe has been doing for 4.0.x, am I sure he can elaborate
> and my one sentence description.
> >
> > I am sure, Chip, Joe, myself and others would help you out to get in the
> groove.
> >
> > -Sebastien
>
> The only requirement is that the RM needs to be a committer for the
> technical aspects of the work. However, we might be able to work
> something out if a non committer wanted to do this.
>

>From my opinion on being an RM, I dont believe the need to be a commiter
should exist.
However I have no issues being a commiter, Im not inclined to do major
works, until I shore
up the work Ive done, which is very XCP specific. In my opinion, an RM
should have some
autonomy in management. Ive run R&D shops for a decade, We always
designated a non-dev
type to manage the release, to remove the politics from the development and
build process.
And all senior development leaders would have to sign off on a release as
being ready from
their code perspective. For us it helped our developers take ownership of
issues as they arose.
Aside from that Id like to contribute, in light of responsibilities I do
have the experience. and well
some of the CS people know me and what Ive been up. :) Ill throw my hat in
the ring.  Id be more
then happy to help.




>
> >
> >
> >>
> >>
> >>>
> >>> -Sebastien
> >
> >
>

Re: 4.1 release manager

[Outback Dingo]

On Sun, May 26, 2013 at 10:24 AM, Chip Childers
wrote:

> On Sat, May 25, 2013 at 10:52:34AM -0400, Outback Dingo wrote:
> > On Sat, May 25, 2013 at 10:33 AM, Chip Childers
> > wrote:
> >
> > > On May 25, 2013, at 10:16 AM, Sebastien Goasguen 
> wrote:
> > >
> > > >
> > > > On May 25, 2013, at 10:08 AM, Outback Dingo 
> > > wrote:
> > > >
> > > >> On Sat, May 25, 2013 at 10:06 AM, Sebastien Goasguen <
> run...@gmail.com
> > > >wrote:
> > > >>
> > > >>> Hi folks,
> > > >>>
> > > >>> Some time back I offered to be RM for 4.1.x , since then I took on
> the
> > > >>> GSoC effort and won't have time to be the RM.
> > > >>>
> > > >>> Therefore the position is up for grabs.
> > > >>>
> > > >>> Any takers ?
> > > >>
> > > >> can we get a brief description of the responsibilities? I just
> might be
> > > >> interested
> > > >
> > > > You would be responsible to get the 4.1.x releases out the door. Keep
> > > track of the JIRA bugs that need to be applied to the 4.1 branch,
> > > cherry-pick them, do some minimal testing and conflict resolution. Then
> > > prepare the source artifacts, signature, release notes. And finally
> start
> > > the [VOTE] threads.
> > > >
> > > > Basically what Joe has been doing for 4.0.x, am I sure he can
> elaborate
> > > and my one sentence description.
> > > >
> > > > I am sure, Chip, Joe, myself and others would help you out to get in
> the
> > > groove.
> > > >
> > > > -Sebastien
> > >
> > > The only requirement is that the RM needs to be a committer for the
> > > technical aspects of the work. However, we might be able to work
> > > something out if a non committer wanted to do this.
> > >
> >
> > From my opinion on being an RM, I dont believe the need to be a commiter
> > should exist.
>
> It does for the technical bits - actually doing commits to the repo,
> access to the release distro area, the right to call a release VOTE, etc...
>

well, yes if the responsibilities include modification of code, you would
require access


>
> > However I have no issues being a commiter, Im not inclined to do major
> > works, until I shore
> > up the work Ive done, which is very XCP specific.
>
> Sorry - just to be clear here.  I'm not suggesting that someone offering
> to help with the release management would immediately be given commit
> rights.
>

Which is understandable, committers need time to be vetted and work
reviewed, of which I
have been working for months and object storage design specific to CS, as a
project of my
own which hopefully, one day will see light of day in CS and a plugin


>
> > In my opinion, an RM
> > should have some
> > autonomy in management.
>
> An RM within this community is a facilitator for the rest of the
> community, as we work toward a shared goal: to do a release.
>
> > Ive run R&D shops for a decade, We always
> > designated a non-dev
> > type to manage the release, to remove the politics from the development
> and
> > build process.
> > And all senior development leaders would have to sign off on a release as
> > being ready from
> > their code perspective. For us it helped our developers take ownership of
> > issues as they arose.
> > Aside from that Id like to contribute, in light of responsibilities I do
> > have the experience. and well
> > some of the CS people know me and what Ive been up. :) Ill throw my hat
> in
> > the ring.  Id be more
> > then happy to help.
>
> Glad you are willing to help!  I do think this would be easier with a
> volunteer to be the official RM that's already a committer.
>
> That being said, perhaps you want to help with identifying bugs that are
> fixed in master, and can easily be brought into 4.1 for an eventual
> 4.1.1 release?  That's actually the harder part of the maintenance
> release work.
>
> -chip
>

Re: [VOTE] List CloudStack related books on the website

[Outback Dingo]

On Mon, May 27, 2013 at 4:27 AM, Sebastien Goasguen wrote:

> Hi,
>
> After a relatively long discussion on the marketing@ list about the
> "Packt Book" [1] I would like to call a vote.
>
> Proposal:
> 
> I propose to list CloudStack related books on our website [2]. The page
> listing these books would contain the following disclaimer:
>
> "This listing does not represent official endorsement by the Apache
> CloudStack project. The Apache CloudStack project does not recommend one
> book versus another nor does it guarantee the quality of the books."
>
> Inclusion of a book in the listing would be done via a vote on the
> marketing@ list.
> 
>
> As a quick summary, alternatives to this proposal were to:
> 1-not do anything
> 2-list the books on the wiki
>
> A few of us have already expressed their opinions and discussed the
> possibilities. Check [1].
>
> Vote will be open for 96 hours (To accommodate Memorial day in the USA).
>
> Reply with:
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>

+1


>
> PS: If edits of the disclaimer are needed but that they do not change the
> meaning of it, the disclaimer will be modified but the vote will not be
> restarted.
>
> [1] http://markmail.org/thread/r4qdmbonmx6yq2uv
> [2] http://cloudstack.apache.org
>
> -Sebastien

Re: Oracle VM is becoming one of the leaders on Magic Quadrant for x86 Virtualization

[Outback Dingo]

On Mon, Jul 8, 2013 at 8:33 AM, Alexandre Sousa
wrote:

> Hi Guys,
>
> This is the last Gartner Report:
> http://www.gartner.com/technology/reprints.do?id=1-1GJA88J&ct=130628&st=sb
>
> Oracle VM is getting better year after year, so I believe that this is a
> good reason to include support for Oracle VM 3.x on CloudStack.
>

90% of what gartner claims is paid advertising. I dont believe any of
the cruft they dish out
and they dont have a very solid track record. However that doesnt mean
OracleVM itself shouldnt
be included, however I have no opinion on it. I just dont think gartner is
a reputable source for the
argument.


>
> Cheers,
> Alexandre
>

Re: [PROPOSAL] QuickCloud

[Outback Dingo]

it would be even nicer if the "virtual router" could be bare metal so as
not to use resources required on the hosts
Id much prefer to run Vyatta, or other FreeBSD pf box as the virtual
router, and just have cloudstack comunicate to it
however its probably outside the scope of this document, Im also not sure
if its feasible to have an external "virtual router"
though i know there Nicera, and other network based plugins, someone should
create a VR for baremetal based on the
CS image... isnt it FreeBSD anyway ??


On Mon, Mar 25, 2013 at 4:44 PM, Chip Childers wrote:

> On Sun, Mar 24, 2013 at 11:54:09PM -0700, Chiradeep Vittal wrote:
> > To enable a cloud to start quicker, I am proposing that system vms be
> made optional in the boot-up of a CloudStack Cloud.
> > I'm working on the 'quickcloud' branch and the detailed proposal is here:
> > https://cwiki.apache.org/confluence/x/clnVAQ
> >
>
> +1 to this proposal.  Just to confirm one thing though...  when you say
> "run alternately on baremetal", I assume you actually mean that the
> services in question would run within an OS (baremetal or virtual)
> outside the control domain of the CS management server.  Correct?
>

Re: [PROPOSAL] QuickCloud

[Outback Dingo]

On Mon, Mar 25, 2013 at 5:07 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> That facility exists already, although the only supported baremetal
> appliance is the Juniper SRX.



And thats expensive. Id prefer a viable open source solution
external on bare metal then on the hypervisors



> On 3/25/13 1:59 PM, "Outback Dingo"  wrote:
>
> >it would be even nicer if the "virtual router" could be bare metal so as
> >not to use resources required on the hosts
> >Id much prefer to run Vyatta, or other FreeBSD pf box as the virtual
> >router, and just have cloudstack comunicate to it
> >however its probably outside the scope of this document, Im also not sure
> >if its feasible to have an external "virtual router"
> >though i know there Nicera, and other network based plugins, someone
> >should
> >create a VR for baremetal based on the
> >CS image... isnt it FreeBSD anyway ??
> >
> >
> >On Mon, Mar 25, 2013 at 4:44 PM, Chip Childers
> >wrote:
> >
> >> On Sun, Mar 24, 2013 at 11:54:09PM -0700, Chiradeep Vittal wrote:
> >> > To enable a cloud to start quicker, I am proposing that system vms be
> >> made optional in the boot-up of a CloudStack Cloud.
> >> > I'm working on the 'quickcloud' branch and the detailed proposal is
> >>here:
> >> > https://cwiki.apache.org/confluence/x/clnVAQ
> >> >
> >>
> >> +1 to this proposal.  Just to confirm one thing though...  when you say
> >> "run alternately on baremetal", I assume you actually mean that the
> >> services in question would run within an OS (baremetal or virtual)
> >> outside the control domain of the CS management server.  Correct?
> >>
>
>

Re: [QuickCloud] zero to cloud in less than a minute

[Outback Dingo]

On Thu, Mar 28, 2013 at 4:51 PM, David Nalley  wrote:

> On Thu, Mar 28, 2013 at 4:43 PM, Edison Su  wrote:
> >
> >
> >> -Original Message-
> >> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> >> Sent: Thursday, March 28, 2013 1:34 PM
> >> To: dev@cloudstack.apache.org
> >> Cc: Phong Nguyen
> >> Subject: Re: [QuickCloud] zero to cloud in less than a minute
> >>
> >>
> >>
> >> On 3/28/13 1:04 PM, "Chiradeep Vittal" 
> wrote:
> >>
> >> >
> >> >>
> >> >>Wow this is awesome. Will you consider writing a blog post about this?
> >> >
> >> >Yes, sure.
> >> >
> >> >One thing that is not 'ready' is the operational / packaging side of
> >> >things.
> >> >Copying systemvm.zip around and starting daemons without some kind of
> >> >init script isn't ideal.
> >> >
> >> >Also the UI still shows "0" system vms and won't display the state of
> >> >these services.
> >>
> >> Along these lines, I would like QuickCloud to be the "default"
> >> out-of-the-box experience for CloudStack. For e.g., one downloads Apache
> >> (the Web server) and starts it and you get an index page.
> >> For CloudStack
> >>  * download & install  binaries for your hypervisor
> >>  * start the MS, SS and CP daemons
> >
> > Is it possible to remove these SS and CP daemons? Including them in MS?
> Make the packager and setup easier.
> >
>
>
> Just thinking out loud here - but if I were to do the packaging - I'd
> probably have a meta-package (perhaps the root cloudstack package)
> that would require cloudstack-sysdaemons. A person would still be able
> to 'yum install cloudstack-server and not get those dameons, but the
> 'default' install (yum install cloudstack)  would have SS/CP as a
> dependency and thus have it installed and started.
>
>
so looking at this it all seems to be vitual box based, is that correct ??
id be curious if it was possible to convert the vbox image to xen, and
create
say an Devcloud/XEN QuickCLoud since i see virtual box as overhead since im
already running XEN under my desktop


> --David
>

Re: [QuickCloud] zero to cloud in less than a minute

[Outback Dingo]

On Thu, Mar 28, 2013 at 6:11 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

>
>
> >>
> >so looking at this it all seems to be vitual box based, is that correct ??
> >id be curious if it was possible to convert the vbox image to xen, and
> >create
> >say an Devcloud/XEN QuickCLoud since i see virtual box as overhead since
> >im
> >already running XEN under my desktop
> >
>
> Absolutely. You don't even need DevCloud
> Follow the "non-Maven" flow in the wiki.
> https://cwiki.apache.org/confluence/x/clnVAQ#QuickCloud-howto2
>
>
Okay, getting back to this, essential this would/does require i install a
management server?? Basically my thoughts are

installed Kubuntu 13.04, install XEN and XCP based on the kronos work,
configure xcp kronos for ubuntu (this is all done)
so now im booting into a XEN/XCP kronos based system, with the kde ui on
top.. should i then just install the management server
on the host xen/xcp os? and then follow the quickcloud docs? or should i
follow the building a devcloud, only do it on the host OS ??

following the doc you posted, it states  find /usr/share -name systemvm.zip
... i have not deployed a management server as of yet

whats my best path to follow ??

Re: [QuickCloud] zero to cloud in less than a minute

[Outback Dingo]

On Sun, Apr 7, 2013 at 11:45 AM, Outback Dingo wrote:

>
>
>
> On Thu, Mar 28, 2013 at 6:11 PM, Chiradeep Vittal <
> chiradeep.vit...@citrix.com> wrote:
>
>>
>>
>> >>
>> >so looking at this it all seems to be vitual box based, is that correct
>> ??
>> >id be curious if it was possible to convert the vbox image to xen, and
>> >create
>> >say an Devcloud/XEN QuickCLoud since i see virtual box as overhead since
>> >im
>> >already running XEN under my desktop
>> >
>>
>> Absolutely. You don't even need DevCloud
>> Follow the "non-Maven" flow in the wiki.
>> https://cwiki.apache.org/confluence/x/clnVAQ#QuickCloud-howto2
>>
>>
> Okay, getting back to this, essential this would/does require i install a
> management server?? Basically my thoughts are
>
> installed Kubuntu 13.04, install XEN and XCP based on the kronos work,
> configure xcp kronos for ubuntu (this is all done)
> so now im booting into a XEN/XCP kronos based system, with the kde ui on
> top.. should i then just install the management server
> on the host xen/xcp os? and then follow the quickcloud docs? or should i
> follow the building a devcloud, only do it on the host OS ??
>
> following the doc you posted, it states  find /usr/share -name
> systemvm.zip ... i have not deployed a management server as of yet
>
> whats my best path to follow ??
>
>
also note while trying to build quickcloud it errored out with the
following, im on Kubuntu 13.04

Re: [QuickCloud] zero to cloud in less than a minute

[Outback Dingo]

On Mon, Apr 8, 2013 at 4:59 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> Can you post your build error on paste.cloudstack.org ?
>

Here ya go! :) didnt know it existed
 http://paste.cloudstack.org/kqi0/

Re: [QuickCloud] zero to cloud in less than a minute

[Outback Dingo]

so clone quickcloud2 ???


On Mon, Apr 8, 2013 at 5:29 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> Sorry about that. I switched to the quickcloud2 branch last Friday in
> order to get a clean patch on master. Can you try that one out?
>
>
> On 4/8/13 2:21 PM, "Outback Dingo"  wrote:
>
> >On Mon, Apr 8, 2013 at 4:59 PM, Chiradeep Vittal <
> >chiradeep.vit...@citrix.com> wrote:
> >
> >> Can you post your build error on paste.cloudstack.org ?
> >>
> >
> >Here ya go! :) didnt know it existed
> > http://paste.cloudstack.org/kqi0/
>
>

Re: [QuickCloud] zero to cloud in less than a minute

[Outback Dingo]

you did see my previous email before the one about the error correct?
or am i hunting down the right path here, or heading off into complete
and vastly unkown territory not yet explored


On Mon, Apr 8, 2013 at 5:29 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> Sorry about that. I switched to the quickcloud2 branch last Friday in
> order to get a clean patch on master. Can you try that one out?
>
>
> On 4/8/13 2:21 PM, "Outback Dingo"  wrote:
>
> >On Mon, Apr 8, 2013 at 4:59 PM, Chiradeep Vittal <
> >chiradeep.vit...@citrix.com> wrote:
> >
> >> Can you post your build error on paste.cloudstack.org ?
> >>
> >
> >Here ya go! :) didnt know it existed
> > http://paste.cloudstack.org/kqi0/
>
>

Re: [QuickCloud] zero to cloud in less than a minute

[Outback Dingo]

[INFO] Apache CloudStack DevCloud  SUCCESS [0.655s]
[INFO] Apache CloudStack DevCloud-KVM  SUCCESS [0.295s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 4:53.292s
[INFO] Finished at: Mon Apr 08 17:46:52 EDT 2013
[INFO] Final Memory: 47M/200M



On Mon, Apr 8, 2013 at 5:29 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> Sorry about that. I switched to the quickcloud2 branch last Friday in
> order to get a clean patch on master. Can you try that one out?
>
>
> On 4/8/13 2:21 PM, "Outback Dingo"  wrote:
>
> >On Mon, Apr 8, 2013 at 4:59 PM, Chiradeep Vittal <
> >chiradeep.vit...@citrix.com> wrote:
> >
> >> Can you post your build error on paste.cloudstack.org ?
> >>
> >
> >Here ya go! :) didnt know it existed
> > http://paste.cloudstack.org/kqi0/
>
>

Re: [QuickCloud] zero to cloud in less than a minute

[Outback Dingo]

Okay so apparently when i fire off cloudstack-management server it is what
appears to be eating all the available memory and causing the laptop to
swap so im not so sure this is viable at this moment unless i can get CS
management to consume considerably less memory


On Wed, Mar 27, 2013 at 8:19 PM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> This should now be usable for production use as well
> Follow instructions here
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud#QuickClou
> d-howto2
>
> From:  Ahmad Emneina 
> Reply-To:  "aemne...@gmail.com" 
> Date:  Wednesday, March 27, 2013 10:34 AM
> To:  Chiradeep Vittal 
> Cc:  "dev@cloudstack.apache.org" 
> Subject:  Re: [QuickCloud] zero to cloud in less than a minute
>
>
> +1
> so awesome!
>
>
> On Wed, Mar 27, 2013 at 10:17 AM, Chiradeep Vittal
>  wrote:
>
> Yes (actually that's what the instructions say)
>
> On 3/26/13 10:46 PM, "Ahmad Emneina"  wrote:
>
> >would someone be able to fire up all those services (say for a basic zone)
> >on one host?
> >
> >
> >On Tue, Mar 26, 2013 at 10:37 PM, Chiradeep Vittal <
> >chiradeep.vit...@citrix.com> wrote:
> >
> >> Following the discussion [1], we have QuickCloud in a rough-but-ready
> >> state for developers to try out
> >> Instructions  for developers to try it out with DevCloud2 here:
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud
> 
> >>
> >> For now only Mac / Unix developers can use this workflow since NFS
> >>mounts
> >> are required.
> >>
> >> [1] http://markmail.org/thread/ajw7b6arhluqcuv2
> >>
>
>
>
>
>
>
>
>
>

Re: What is your setup?

[Outback Dingo]

On Wed, Feb 5, 2014 at 9:24 PM, Maurice Lawler  wrote:

> Just a general question
>
> What is YOUR favorite setup? KVM? Xen? VmWare?


XEN XEN XEN.


>
>
> - Maurice
>

Re: [DISCUSS] CloudStack 4.9.3.0 (LTS)

[Outback Dingo]

On Wed, Jul 12, 2017 at 10:41 AM, Rohit Yadav  wrote:
> All,
>
>
> Please send me a list of PRs you would like to see in 4.9.3.0 so we can 
> freeze the scope for 4.9.3.0, no promises but it may be possible to have a 
> release plan as soon as next week.
>
>

Support for XenServer 7.1 would be nice


> - Rohit
>
> 
> From: Wido den Hollander 
> Sent: 12 July 2017 01:27:30
> To: Rohit Yadav; dev@cloudstack.apache.org; us...@cloudstack.apache.org
> Subject: Re: [DISCUSS] CloudStack 4.9.3.0 (LTS)
>
> Hi,
>
> I would suggest: https://github.com/apache/cloudstack/pull/2131
>
> Serious issue with Ubuntu 16.04 and statistics gathering on KVM.
>
> Wido
>
>> Op 11 juli 2017 om 11:49 schreef Rohit Yadav :
>>
>>
>> Hi Sean,
>>
>>
>> Thanks for sharing.
>>
>>
>> - Rohit
>>
>> 
>> From: Sean Lair 
>> Sent: 11 July 2017 03:41:17
>> To: dev@cloudstack.apache.org
>> Cc: us...@cloudstack.apache.org
>> Subject: RE: [DISCUSS] CloudStack 4.9.3.0 (LTS)
>>
>> Here are three issues we ran into in 4.9.2.0.  We have been running all of 
>> these fixes for several months without issues.  The code changes are all 
>> very easy/small, but had a big impact for us.
>>
>> I'd respectfully suggest they go into 4.9.3.0:
>>
>> https://github.com/apache/cloudstack/pull/2041 (VR related jobs scheduled 
>> and run twice on mgmt servers)
>> https://github.com/apache/cloudstack/pull/2040 (Bug in monitoring of S2S 
>> VPNs - also exists in 4.10)
>> https://github.com/apache/cloudstack/pull/1966 (IPSEC VPNs do not work after 
>> vRouter reboot)
>>
>> Thanks
>> Sean
>>
>> rohit.ya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>>
>> -Original Message-
>> From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
>> Sent: Friday, July 7, 2017 1:14 AM
>> To: dev@cloudstack.apache.org
>> Cc: us...@cloudstack.apache.org
>> Subject: [DISCUSS] CloudStack 4.9.3.0 (LTS)
>>
>> All,
>>
>>
>> With 4.10.0.0 voted, I would like to start some initial discussion around 
>> the next minor LTS release 4.9.3.0. At the moment I don't have a timeline, 
>> plans or dates to share but I would like to engage with the community to 
>> gather list of issues, commits, PRs that we should consider for the next LTS 
>> release 4.9.3.0.
>>
>>
>> To reduce our test and QA scope, we don't want to consider changes that are 
>> new feature, or enhancements but strictly blockers/critical/major bugfixes 
>> and security related fixes, and we can consider reverting any already 
>> committed/merged PR(s) on 4.9 branch (committed since 4.9.2.0).
>>
>>
>> Please go through list of commits since 4.9.2.0 (you can also run, git log 
>> 4.9.2.0..4.9) and let us know if there is any change we should consider 
>> reverting:
>>
>> https://github.com/apache/cloudstack/commits/4.9
>>
>>
>> I started backporting some 
>> fixes on the 4.9 branch, please go through the following PR and raise 
>> objections on changes/commits that we should not backport or revert:
>>
>> https://github.com/apache/cloudstack/pull/2052
>>
>>
>> Lastly, please also share any PRs that we should consider reviewing+merging 
>> on 4.9 branch for the 4.9.3.0 release effort.
>>
>>
>> - Rohit
>>
>> rohit.ya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>>
>>
>>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>

Re: [DISCUSS] CloudStack Future

[Outback Dingo]

Some of us would love to contribute, yet don't feel the requirement to
sign-up for "sites" to simply post their feelings.
That being said... heres mine in public.. remove the "dependency"
on NFS as primary/secondary allow
for more configurable storage options. Its one of the reasons why we
dropped cloudstack. That and certain networking
configuration requirements didn't fit our network topology.

On Wed, Sep 17, 2014 at 2:51 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi everyone,
>
> First: Thanks to Rohit and Daan for working on this.
>
> Next: Definitely feel free to e-mail ideas privately; however, I'd like to
> especially encourage people to make their ideas known publicly, if you feel
> comfortable doing this. Doing it publicly might make it easier for us as a
> community to brainstorm the ideas and play around with taking them in
> different directions.
>
> Thanks!
> Mike
>
> On Tue, Sep 16, 2014 at 3:08 AM, Rohit Yadav 
> wrote:
>
> > Hi everyone,
> >
> > Some of us are in Amsterdam and discussing various things we want to do
> > for the project. I’ve aggregated some of them on a Trello board here:
> > https://trello.com/b/nj8dDBWl/apache-cloudstack-future
> >
> > Please share your ideas, publicly or private to me; I’ll add them on the
> > board. Our main focus right now is testing, release quality and aligning
> > efforts.
> >
> > We’re now able to run simulator tests on TravisCI for 4.4 and master
> > branches:
> > https://travis-ci.org/apache/cloudstack/builds
> >
> > Some of us are also experimenting with Github pull requests and we
> already
> > see that it’s encouraging to get TravisCI verify them.
> >
> > Regards,
> > Rohit Yadav
> > Software Architect, ShapeBlue
> > M. +41 779015219 | rohit.ya...@shapeblue.com
> > Blog: bhaisaab.org | Twitter: @_bhaisaab
> >
> > Find out more about ShapeBlue and our range of CloudStack related
> services
> >
> > IaaS Cloud Design & Build<
> > http://shapeblue.com/iaas-cloud-design-and-build//>
> > CSForge – rapid IaaS deployment framework
> > CloudStack Consulting
> > CloudStack Infrastructure Support<
> > http://shapeblue.com/cloudstack-infrastructure-support/>
> > CloudStack Bootcamp Training Courses<
> > http://shapeblue.com/cloudstack-training/>
> >
> > This email and any attachments to it may be confidential and are intended
> > solely for the use of the individual to whom it is addressed. Any views
> or
> > opinions expressed are solely those of the author and do not necessarily
> > represent those of Shape Blue Ltd or related companies. If you are not
> the
> > intended recipient of this email, you must neither take any action based
> > upon its contents, nor copy or show it to anyone. Please contact the
> sender
> > if you believe you have received this email in error. Shape Blue Ltd is a
> > company incorporated in England & Wales. ShapeBlue Services India LLP is
> a
> > company incorporated in India and is operated under license from Shape
> Blue
> > Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
> Brasil
> > and is operated under license from Shape Blue Ltd. ShapeBlue 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.
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

Re: [JENKINS] Build errors

[Outback Dingo]

On Fri, Dec 13, 2013 at 8:42 AM, Hugo Trippaers  wrote:

> Hey guys,
>
> Several builds have intermittent build errors at the moment. This is
> appears to be caused by a problem in the maven system outside our control.
> Several jar files we need are not downloaded properly and cause the build
> to fail.
>
> I’m checking to see what we can do to help resolve this.
>
> Cheers,
>
> Hugo



Honestly, I think jenkins messages should be on their own list Ive got
a mailbox full of them

Re: Build failed in Jenkins: build-master #430

[Outback Dingo]

later devlist this is BS


On Thu, Jan 9, 2014 at 11:18 PM,  wrote:

> See 
>
> --
> [...truncated 672 lines...]
> Receiving objects:  89% (414381/461522), 287.56 MiB | 897 KiB/s
> Receiving objects:  89% (414381/461522), 288.25 MiB | 845 KiB/s
> Receiving objects:  89% (414381/461522), 288.87 MiB | 791 KiB/s
> Receiving objects:  89% (414381/461522), 289.57 MiB | 730 KiB/s
> Receiving objects:  89% (414381/461522), 289.99 MiB | 688 KiB/s
> Receiving objects:  89% (414382/461522), 290.43 MiB | 671 KiB/s
> Receiving objects:  89% (415038/461522), 291.39 MiB | 674 KiB/s
> Receiving objects:  90% (415370/461522), 291.39 MiB | 674 KiB/s
> Receiving objects:  90% (415889/461522), 292.12 MiB | 685 KiB/s
> Receiving objects:  90% (416143/461522), 292.39 MiB | 672 KiB/s
> Receiving objects:  90% (416510/461522), 293.01 MiB | 639 KiB/s
> Receiving objects:  90% (416886/461522), 293.35 MiB | 623 KiB/s
> Receiving objects:  90% (417411/461522), 294.39 MiB | 567 KiB/s
> Receiving objects:  90% (417411/461522), 295.14 MiB | 579 KiB/s
> Receiving objects:  90% (417412/461522), 295.60 MiB | 616 KiB/s
> Receiving objects:  90% (417472/461522), 296.83 MiB | 714 KiB/s
> Receiving objects:  90% (417472/461522), 297.23 MiB | 723 KiB/s
> Receiving objects:  90% (417542/461522), 298.18 MiB | 809 KiB/s
> Receiving objects:  90% (417660/461522), 298.62 MiB | 814 KiB/s
> Receiving objects:  90% (417795/461522), 299.43 MiB | 848 KiB/s
> Receiving objects:  90% (417909/461522), 300.26 MiB | 757 KiB/s
> Receiving objects:  90% (417951/461522), 300.55 MiB | 732 KiB/s
> Receiving objects:  90% (418605/461522), 301.17 MiB | 659 KiB/s
> Receiving objects:  91% (419986/461522), 301.17 MiB | 659 KiB/s
> Receiving objects:  91% (422781/461522), 301.89 MiB | 621 KiB/s
> Receiving objects:  92% (424601/461522), 302.25 MiB | 624 KiB/s
> Receiving objects:  92% (426503/461522), 302.61 MiB | 649 KiB/s
> Receiving objects:  93% (429216/461522), 303.05 MiB | 692 KiB/s
> Receiving objects:  93% (430966/461522), 303.45 MiB | 710 KiB/s
> Receiving objects:  93% (430969/461522), 304.64 MiB | 748 KiB/s
> Receiving objects:  93% (430969/461522), 305.17 MiB | 698 KiB/s
> Receiving objects:  93% (430969/461522), 305.50 MiB | 680 KiB/s
> Receiving objects:  93% (430969/461522), 306.12 MiB | 640 KiB/s
> Receiving objects:  93% (431042/461522), 306.41 MiB | 616 KiB/s
> Receiving objects:  93% (431262/461522), 307.46 MiB | 592 KiB/s
> Receiving objects:  93% (431263/461522), 308.28 MiB | 653 KiB/s
> Receiving objects:  93% (432413/461522), 308.71 MiB | 685 KiB/s
> Receiving objects:  93% (432925/461522), 309.55 MiB | 730 KiB/s
> Receiving objects:  94% (433831/461522), 310.02 MiB | 770 KiB/s
> Receiving objects:  94% (436187/461522), 310.52 MiB | 808 KiB/s
> Receiving objects:  94% (436187/461522), 311.31 MiB | 826 KiB/s
> Receiving objects:  94% (436187/461522), 311.62 MiB | 708 KiB/s
> Receiving objects:  94% (436187/461522), 311.97 MiB | 582 KiB/s
> Receiving objects:  94% (436187/461522), 312.20 MiB | 535 KiB/s
> Receiving objects:  94% (436187/461522), 312.72 MiB | 427 KiB/s
> Receiving objects:  94% (436187/461522), 313.32 MiB | 385 KiB/s
> Receiving objects:  94% (436187/461522), 313.84 MiB | 431 KiB/s
> Receiving objects:  94% (436187/461522), 314.21 MiB | 466 KiB/s
> Receiving objects:  94% (436187/461522), 315.00 MiB | 547 KiB/s
> Receiving objects:  94% (436187/461522), 315.76 MiB | 613 KiB/s
> Receiving objects:  94% (436187/461522), 316.46 MiB | 648 KiB/s
> Receiving objects:  94% (436187/461522), 317.34 MiB | 723 KiB/s
> Receiving objects:  94% (436187/461522), 317.75 MiB | 743 KiB/s
> Receiving objects:  94% (436187/461522), 318.71 MiB | 799 KiB/s
> Receiving objects:  94% (436187/461522), 319.61 MiB | 842 KiB/s
> Receiving objects:  94% (436187/461522), 320.69 MiB | 917 KiB/s
> Receiving objects:  94% (436187/461522), 321.57 MiB | 887 KiB/s
> Receiving objects:  94% (436187/461522), 321.94 MiB | 744 KiB/s
> Receiving objects:  94% (436187/461522), 322.14 MiB | 691 KiB/s
> Receiving objects:  94% (436187/461522), 322.56 MiB | 579 KiB/s
> Receiving objects:  94% (436187/461522), 323.04 MiB | 464 KiB/s
> Receiving objects:  94% (436187/461522), 323.48 MiB | 386 KiB/s
> Receiving objects:  94% (436187/461522), 323.86 MiB | 393 KiB/s
> Receiving objects:  94% (436187/461522), 324.01 MiB | 385 KiB/s
> Receiving objects:  94% (436187/461522), 324.46 MiB | 384 KiB/s
> Receiving objects:  94% (436187/461522), 325.00 MiB | 378 KiB/s
> Receiving objects:  94% (436187/461522), 325.31 MiB | 390 KiB/s
> Receiving objects:  94% (436187/461522), 325.89 MiB | 426 KiB/s
> Receiving objects:  94% (436187/461522), 326.52 MiB | 491 KiB/s
> Receiving objects:  94% (436187/461522), 327.13 MiB | 546 KiB/s
> Receiving objects:  94% (436187/461522), 327.87 MiB | 617 KiB/s
> Receiving objects:  94% (436187/461522), 328.38 MiB | 601 KiB/s
> Receiving objects:  94% (4