On Tue, Aug 28, 2012 at 3:14 PM, Brian Schott <
brian.sch...@nimbisservices.com> wrote:
> At the risk of getting bad e-karma for cross posting to
> openstack-operators, that might be the place to post that question. I for
> one disagree that we should merge the openstack general list into
> opens
On Tue, Aug 28, 2012 at 11:59 AM, Francis J. Lacoste <
francis.laco...@canonical.com> wrote:
> On 12-08-27 08:32 PM, Andrew Clay Shafer wrote:
> > For exporting from Launchpad, surely someone at Canonical would be able
> > and willing to get that list of emails.
> >
>
There are at least end users, operators and developers in the OpenStack
technical ecosystem.
There are also 'OpenStack' related discussions that aren't technical in
nature.
It doesn't seem right to make the operators list a catchall.
For exporting from Launchpad, surely someone at Canonical woul
Cisco - Lew Tucker
> Cloudscaling - Randy Bias
> Dell - John Igoe
> Dreamhost - Simon Anderson
> ITRI/CCAT - Dr. Tzi-cker Chiueh
> Mirantis - Boris Renski
> Piston - Joshua McKenty
> Yahoo! - Sean Roberts
>
Congratulations to the newly elected board members.
Do we have an oath of office?
First you fill out that form, then you have to have a Redhat login, so
either make one or login, then you have to fill out another form, then you
get on a wait list, then you get an email that the subscription is active.
I received that email.
You can't do anything unless you have running Redhat l
> These are important and difficult questions. As you say, OpenStack is
> many different things to different people. So far we survived while
> avoiding to answer clearly, mostly because we had no good way of coming
> up with answers. That ultimately creates tension between participants in
> our co
What is OpenStack?
Clearly, OpenStack is many things to many people and organizations.
What does it mean to contribute to OpenStack? What does it mean to deploy
OpenStack? What does it mean to operate OpenStack?
What do we mean when we say compatible? interoperable? community? branded?
Is OpenS
Thanks for sharing.
On Fri, Aug 10, 2012 at 12:31 PM, John Dickinson wrote:
> In a standard swift deployment, the proxy server is running behind a load
> balancer and/or an SSL terminator. At SwiftStack, we discovered an issue
> that may arise from some config parameters in this layer, and we'
Is there a good reason NOT to do this?
On Wed, Aug 8, 2012 at 4:35 PM, Eric Windisch wrote:
> I believe that the RPC backend should no longer have any default.
>
>
>
> Historically, it seems that the Kombu driver is default only because it
> existed before all others and before there was an abs
I disagree with your last point, it is true if we look only into this
> particular problem, but if you look into the whole ecosystem you'll realize
> that the code removal of nova-volumes is not the only change from essex to
> folsom.. if we had deprecated all other changes, this particular one wou
hings. We can do better. The issues and emotions raised
in this thread should not be dismissed. Doing that is to put the potential
of OpenStack in peril.
Regards,
Andrew Clay Shafer
___
Mailing list: https://launchpad.net/~openstack
Post to
One vote for option 1.
Remove Volumes
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
+1
On Wed, May 16, 2012 at 2:00 PM, Francis J. Lacoste <
francis.laco...@canonical.com> wrote:
> Hi,
>
> The whole API discussion made me wondered if this part of the
> architecture is worth keeping.
>
> The main use case for the metering API is so that billing systems can be
> integrated in Open
I would vote for 0 or 1 on the cost versus benefit. Option 0 is the least
overhead, but option 1 would be nice for a lot of reasons.
The downside to i18n of the logs and errors in the dilution of information
available to find solutions can be higher than the benefit of providing
messages in a nati
>
>
> It would be better if all OpenStack core components agreed on unified
> interfaces / messages for metering that would be easy to harvest without
> installing agents on nodes. This is also true for many services outside of
> the OpenStack eco-system. However, much in the same way munin and nag
I'm glad to see people championing the effort to implement metering. Is
there someway to refocus the enthusiasm for solving the metering problem
into engineering a general solution in OpenStack?
I'm just going to apologize in advance, but I don't think this project is
headed in the right direction
In nova.conf, what is instances_path being set to?
It's blowing up trying to find the path
'/usr/lib/python2.7/dist-packages/instances', which is getting set as the
value of FLAGS.instances_path.
On Fri, Apr 27, 2012 at 12:00 PM, Leander Bessa wrote:
> Hello,
>
> I'm clueless as how to solve
Justin,
I'm a fan of veewee.
https://github.com/jedi4ever/veewee
Probably some work to support Xen, but should work for building KVM images.
These docs should give a bit better idea.
https://github.com/jedi4ever/veewee/blob/master/doc/definition.md
https://github.com/jedi4ever/veewee/blob/master
Interested in devops.
Off the top of my head.
live upgrades
api queryable indications of cluster health
api queryable cluster version and configuration info
enabling monitoring as a first class concern in OpenStack (either as a
cross cutting concern, or as it's own project)
a framework for gather
Pete,
There is clearly something interesting going on with scope. 'options',
which appears to really be 'parser' get passed in as a variable, but are
then gets over written before being used by the call using the global
'parser'.
(options, args) = parse_args(parser, args)
The history of the comma
>
>
> *This link shows the integration of NexentaStor (a NAS/SAN integrated
>> storage solution) with Openstack Nova:
>> http://mirantis.blogspot.com/2011/11/converging-openstack-with-nexenta.html
>> *
>
>
>
> That's Nova, not Swift..
> In case of Nova, a NAS or SAN approach makes very much sense.
>
>
> >
> > If your SAIO/test diverge from production deployments, what are you
> really
> > testing?
>
> there's a big difference, imho, between testing code integration and
> production deployments.
> e.g. if you're trying to write a functional test for swift, that
> requires the proxy server to
some response inline followed by general comments on the topic
On Sat, Mar 10, 2012 at 9:30 AM, andi abes wrote:
> I like where this discussion is going. So
> I'd like to throw a couple more sticks into the fire, around test/SAIO
> vs production deployments..
>
I think there are some misconcept
+1
On Wed, Mar 7, 2012 at 7:59 PM, Alexey Eromenko wrote:
> There are several blocker bugs in manuals. (they prevent new users
> from installing or configuring OpenStack)
>
> But I doubt they are marked as such.
>
> What to do ?
> Can I up priority for docs on L-pad, if a broken docs prevent new
The way run_tests.sh works right now, you can run all tests, all tests in a
file, a module or an individual test depending on what args you run with.
The default with no args will run all the tests.
You can run one file passing in the name of the file minus .py (if it is a
sub-directory, replace
+1
Don't deprecate, until the bass drops... lesson learned.
On Wed, Feb 15, 2012 at 11:22 PM, Soren Hansen wrote:
> 2012/2/14 Jesse Andrews :
> > The major lessons of keystone:
>
> Now that we're verbalising lessons learnt from Keystone, I'd like to add
> another thing from back in the Diab
the names for the recipes into your system? Is that
sync with what is on the puppet master somehow or you are going to do data
entry and it's all string matching?
On 1/26/12 5:03 PM, Andrew Clay Shafer wrote:
>
>
> I'd also like to see more of a service oriented approach and avoid
I would love to see a first class puppet integration with nova instances.
I'd also like to see more of a service oriented approach and avoid adding
tables to nova if possible.
I'm not sure the best solution is to come up with a generic service for
$configuration_manager for nova core. I'd rather
+1
On Thu, Jan 5, 2012 at 11:57 AM, Lloyd Dewolf wrote:
> Having played a very minor role in this process for WordPress, and
> been an onlooking numerous times, it is always a long and involved
> process.
>
> Ever try telling the IRS that you don't want to pay taxes?
>
>
> I appreciate the passi
Do not use the ssl in the python for anything beyond noodling on a proof of
concept.
Between the python ssl and eventlet, ssl is unusably broken.
This should probably be in red in the documentation.
___
Mailing list: https://launchpad.net/~openstack
Pos
30 matches
Mail list logo
