Just to add to what Naryan said, I think that unless the developers experience
the pain points of a production-style deployment, they generally aren't going
to be aware of what these pain points are. We need to both:
- Make it easy as possible for developers to get up and running so they can
ma
Narayan, I completely agree with you. Developers are our "first line of
defense", but they are not the only one. I would love to have different
environments (development, SMB deployments, large scale deployments), where
all of them have the same behavior, but i'm afraid there is already a long
road
On 03/21/2012 08:48 PM, Narayan Desai wrote:
> Ghe, while you're right that these two workloads are different,
> deployers need developers to use a representative environment during
> development, or the code doesn't work when it hits real deployments.
> We've now been bitten during our initial dep
Ghe, while you're right that these two workloads are different, deployers
need developers to use a representative environment during development, or
the code doesn't work when it hits real deployments. We've now been bitten
during our initial deployment of cactus, our upgrade to diablo, and our
rec
Hi,
we are facing two differents problems here. We have developers and
final users, and both of them with different expectations about what to get
from OpenStack. Developers wants an easy way to test "untested" code, new
cool-probably-broken features and be able to change immediately - devstack
Another idea:
http://meego.gitorious.org/meego-developer-tools/spectacle
That python code seems to be able to take a yaml defintion and generate either
rpm specfiles or debian pkg files.
It might be forked or extended (or both) and used to generate the initial set
of package definitions for op
* Duncan McGreggor (dun...@dreamhost.com) wrote:
> But, perhaps you just meant: "let's get some consensus from project
> leaders on the recommended way for now" -- and that sounds great to me
> ;-)
Yup, nothing ominous, just community concensus
___
Mai
On Tue, Mar 20, 2012 at 3:14 PM, Chris Wright wrote:
> * Joshua Harlow (harlo...@yahoo-inc.com) wrote:
>> https://github.com/yahoo/Openstack-DevstackPy
>>
>> Its our chance to make it right :-)
>
> Hopefully your session, or a joint session will make the Common
> development track so we can at lea
This is, indeed, the crux of the matter. The release cycle, for both
diablo and essex, has been that all kinds of incompatible changes are
made right until
the end. During the critical month before release when we need as many
people ad possible to deploy and test real clusters, documentation i
On Tue, Mar 20, 2012 at 1:57 PM, Michael Pittaro wrote:
>
> Install and configuration documentation is an area we need to focus
> on more, and it will need much more community involvement to really
> make a difference. The situation is currently much better than it
> was back in September 2011,
Yours might make sense to be added on to devstackPY.
We have a concept of a persona (thanks! to dreamhost pep's) that might be what
you want/use for this also:
Features:
Supports more than one distribution
Currently RHEL 6.2 (with epel), Ubuntu 11.10 (12 WIP), Fedora 16 (WIP)
Supports dry-ru
* Joshua Harlow (harlo...@yahoo-inc.com) wrote:
> https://github.com/yahoo/Openstack-DevstackPy
>
> Its our chance to make it right :-)
Hopefully your session, or a joint session will make the Common
development track so we can at least put to rest the best way
to handle distro agnostic devstack.
On Tue, Mar 20, 2012 at 9:40 AM, Thomas Goirand wrote:
> Hi!
>
> I'm again and again always told that I should use Devstack. I don't
> agree, and I'd like to share why. The use of devstack, IMO, has gone out
> of proportions, and it shouldn't have go more far than a Jenkins job.
>
> I'm trying to
On 03/21/2012 01:35 AM, Mark McLoughlin wrote:
> However, I do think devstack is seriously useful for upstream developers
I have never denied that fact. :)
Thomas
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpa
Hi Thomas,
I think devstack has done a lot for the developer's use-case, but I believe
we should also have a official / semi-official project that does some sort
of packaging to help the production use-case. I've proposed a summit
discussion: http://summit.openstack.org/sessions/view/26
The back
Hi Thomas,
On Wed, 2012-03-21 at 00:40 +0800, Thomas Goirand wrote:
> I'm again and again always told that I should use Devstack. I don't
> agree, and I'd like to share why.
I'd summarize your points as:
- devstack is only tested for a specific version of Ubuntu
- you're working on making
Hi Thomas,
On Tue, Mar 20, 2012 at 4:40 PM, Thomas Goirand wrote:
> The same mess applies in the devstack not-for-XenServer. In some cases,
> some tools are apt-get installed. I can see for example 'apt-get install
> sudo'. But stack.sh assumes (god knows why) that "screen" is already
screen is
Try:
https://github.com/yahoo/Openstack-DevstackPy
Its our chance to make it right :-)
Contributions welcome ;-)
See features @ https://github.com/yahoo/Openstack-DevstackPy/wiki
And a beginner guide @
https://github.com/yahoo/Openstack-DevstackPy/wiki/Simple-Setup
Let the revolution begin!
Hi!
I'm again and again always told that I should use Devstack. I don't
agree, and I'd like to share why. The use of devstack, IMO, has gone out
of proportions, and it shouldn't have go more far than a Jenkins job.
I'm trying to be constructive and point out issues, hoping it will be
taken the co
19 matches
Mail list logo
