> At the same time we are really close to freeze, this potentially blocks the
> work of others; and while it should be mostly innocuous, it is still a large
> amount of disruption, for what appears to me to be > precious little benefit
> for the project or the 4.1 release.
> So why are we push
> We also need for people who have signed up for the conference to register *in
> the room block* for the event.
> (I know we have some folks who are also attending the AWS event and may have
> just signed up for the whole
> week under that block - that won't work, as we're committed to a certain
>About the links on the side... I appreciate them. The wiki is in need
>of TLC, and until we get the ok for themes and content templates, the
>wiki is not the first place people will go for info.
I agree the wiki is in need of TLC, but it still has the most accurate
information and the most up-
The site looks great. Thanks for all the hard work that has gone into it to
make it happen. Can't wait to see a new streamlined content in production.
I have one comment though. It seems to me that most of links on the left
navigation really belong to the wiki. The landing page should ideally co
Windows
Looks like incorrect path to ca-bundle, should be something like c:\\
http://lostechies.com/keithdahlby/2010/09/26/msysgit-error-setting-certificate-verify-locations/
From: Sheng Liang [sheng.li...@citrix.com]
Sent: Saturday, October 27, 2012 2:28
I wonder if we could add an automatic check in the build script to detect new
dependencies and check them against the legal documentation.
Sheng
-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: Tuesday, October 09, 2012 7:30 PM
To: cloudstack-dev@incubator
AWS API support is not related to Citrix CloudBridge product. Can you remove
that reference?
Sheng
- Reply message -
From: "Chip Childers"
To: "cloudstack-dev@incubator.apache.org"
Subject: [ASFCS40] CHANGES file
Date: Mon, Oct 8, 2012 11:56 am
All,
Below is a copy of my first draf
I think HDFS could be an option for object storage. It certainly cannot be a
requirement for CloudStack. There are many great implementations of object
storage already in the market. An object storage API front-end on NAS is also a
perfectly good option for small-scale deployments.
I hope to be
> Let's take the Netscaler AutoScale feature currently being implemented. I'm
> sure they must be at least touching the API,
> UI, some Resources layer and DAO layer. If they were committers, do they
> have to have been invited to all 4 of those subprojects?
This is precisely the type of probl
+1
I also feel the project is already too big to have a single list of committers.
Sheng
-Original Message-
From: Alex Huang [mailto:alex.hu...@citrix.com]
Sent: Wednesday, August 15, 2012 2:42 PM
To: cloudstack-dev@incubator.apache.org
Subject: [PROPOSAL] Breaking CloudStack into subpr
> That could be ultimate goal, and it's totally reflects "unix way" - don't use
> one huge universal tool, rather - set of small,
> but dedicated to particular task tools. As for now i see that CS is big
> monolithic complex, with tons internal, non-exposed dependencies.
I agree. Making the co
CloudStack snapshots are true backups. Snapshots are automatically copied to
secondary storage. After the snapshot is copied out, it is then deleted from
primary storage.
Sheng
-Original Message-
From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
Sent: Friday, July 20, 2012 8:06 P
> In short, I see three options (please comment if you see more) 1. Rip out
> hibernate and replace with some other ORM 2. Make the AWS API bits an
> optional non-default part of the build.
3. Declare that hibernate is a system requirement for CloudStack
I prefer option #1. It is the cleanest. I
13 matches
Mail list logo
