Thats incorrect, as i said in my original mail.. I am usign devstack+manila
and it wasn't very clear to me that mysql-devel needs to be installed and
it didn't get installed. I am on F20, not sure if that causes this , if
yes, then we need to debug and fix this.
Maybe its a good idea to put a
Even better, whenever ./run_tests fail... maybe put a msg stating the
following C libs needs to be installed, have the user check the
same..something like that would help too.
On Mon, Sep 22, 2014 at 11:59 AM, Deepak Shetty dpkshe...@gmail.com wrote:
Thats incorrect, as i said in my original
On 18/09/14 16:03, Thierry Carrez wrote:
Maish Saidel-Keesing wrote:
On 17/09/2014 23:12, Anita Kuno wrote:
On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote:
This looks great - but I am afraid that something might be missing.
As part of the Design summit in Atlanta there was an Ops Meetup
Hi All,
Request you all to provide inputs on below understanding:
Openstack: Group-based policy is a blueprint for Juno-3 release of
Openstack. It will extend OpenStack Networking with policy and
connectivity abstractions that enable significantly more simplified and
application-oriented
Greetings,
I'd like to announce my candidacy for the Message Program PTL position.
I've been part of this program since its inception. Along with a really
amazing team, I've been working on changing the openstack messaging
service reality for the last 2 years.
Zaqar has a set of features that I
On 09/20/2014 10:17 AM, Geoff O'Callaghan wrote:
Hi all,
I'm just trying to understand the messaging strategy in openstack.It
seems we have at least 2 messaging layers.
Oslo.messaging and zaqar, Can someone explain to me why there are
two?To quote from the zaqar faq :
-
On 21/09/14 22:55, Alex Leonhardt wrote:
Hi guys,
trying to get a devstack up and running, on a VM, but I keep getting this:
Error during template rendering
In
template
|/opt/stack/horizon/openstack_dashboard/templates/context_selection/_project_list.html|,
error at line *7*
On 09/21/2014 11:30 PM, Ian Cordasco wrote:
Hi Thomas,
Several people, many of whom are core contributors to other projects, have
asked that this discussion not be continued in this venue. Discussion of
the decisions of the core-developers of requests are not appropriate for
this list. All
No probs - done that just now.
Alex
On 22 September 2014 08:20, Matthias Runge mru...@redhat.com wrote:
On 21/09/14 22:55, Alex Leonhardt wrote:
Hi guys,
trying to get a devstack up and running, on a VM, but I keep getting
this:
Error during template rendering
In
Hi
On 22 September 2014 04:26, Robert Collins robe...@robertcollins.net
wrote:
I'm not running as PTL for the TripleO program this cycle.
As someone who's been involved in TripleO for a couple of years, I'd like
to say thank you very much for your efforts in bootstrapping and PTLing the
I would like to announce my candidacy for Horizon PTL.
I've been actively contributing to Horizon since the Grizzly cycle and
I've been a core contributor since the Havana cycle. For the last two
cycles, I have had the pleasure of serving as PTL.
Horizon is in the midst of some large transitions
On 09/22/2014 08:00 AM, Flavio Percoco wrote:
oslo messaging is highly tight to AMQP semantics whereas Zaqar is not.
The API for oslo.messaging is actually quite high level and could easily
be mapped to different messaging technologies.
There is some terminology that comes from older
Hi.
Today I encountered bug 1369627 [1] as I trolled the status of release
critical bugs, which appears to be fall out from the decision to
implement adding support for config drives stored in RBD. While I have
no problem with that being at thing we do, I'm concerned by the way it
was implemented
John Dickinson wrote:
I propose that we can get the benefits of Monty's proposal and implement all
of his concrete suggestions (which are fantastic) by slightly adjusting our
usage of the program/project concepts.
I had originally hoped that the program concept would have been a little
Hi Alex,
Thank you for doing this.
-Original Message-
From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
Sent: Friday, September 19, 2014 3:40 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Nova] Some ideas for micro-version implementation
Close to Kilo, it is
Hi all,
I need to add the option rebootTimeout when the instance boots.
If you use the*qemu-kvm*, boot parameter/|reboot-timeout|/allows a
virtual machine to retry booting if no bootable device is found:
/*# qemu-kvm --boot reboot-timeout=1000*/
Ref:
-Original Message-
From: Day, Phil [mailto:philip@hp.com]
Sent: Friday, September 19, 2014 7:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] are we going to remove the novaclient v3
shell or what?
DevStack
On 09/22/2014 11:04 AM, Gordon Sim wrote:
On 09/22/2014 08:00 AM, Flavio Percoco wrote:
oslo messaging is highly tight to AMQP semantics whereas Zaqar is not.
The API for oslo.messaging is actually quite high level and could easily
be mapped to different messaging technologies.
There is
whether following variables fit for your purpose? guess you want to
override the value through boot command?
cfg.IntOpt(reboot_timeout,
default=0,
help=Automatically hard reboot an instance if it has been
stuck in a rebooting state longer than N
On Mon, Sep 22, 2014 at 11:32:57AM +0200, Angelo Matarazzo wrote:
Hi all,
I need to add the option rebootTimeout when the instance boots.
If you use the*qemu-kvm*, boot parameter/|reboot-timeout|/allows a virtual
machine to retry booting if no bootable device is found:
What are the scenarios
Hi Nikesh,
-Original Message-
From: Nikesh Kumar Mahalka [mailto:nikeshmaha...@vedams.com]
Sent: Saturday, September 20, 2014 9:49 PM
To: openst...@lists.openstack.org; OpenStack Development Mailing List (not
for usage questions)
Subject: Re: [Openstack] No one replying on tempest
Hey
On Thu, 2014-09-18 at 11:53 -0700, Monty Taylor wrote:
Hey all,
I've recently been thinking a lot about Sean's Layers stuff. So I wrote
a blog post which Jim Blair and Devananda were kind enough to help me edit.
http://inaugust.com/post/108
Lots of great stuff here, but too much to
Hi Folks,
I'd like to get some opinions on the use of pairs of notification messages for
simple events. I get that for complex operations on an instance (create,
rebuild, etc) a start and end message are useful to help instrument progress
and how long the operations took.However we also
Great conversations here.
I'd like to echo Dean Troyer's comment on Suggestion 9, for multi-cloud
span node pooling ,we need standards. It'll make life easier when user
tools could be configured against a limit as well as standard set of rules,
instead of numerous different rules by vendors. It
On Mon, Sep 22, 2014 at 11:03:02AM +, Day, Phil wrote:
Hi Folks,
I'd like to get some opinions on the use of pairs of notification
messages for simple events. I get that for complex operations on
an instance (create, rebuild, etc) a start and end message are useful
to help instrument
Hi Daniel,
-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com]
Sent: 22 September 2014 12:24
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] - do we need .start and .end
notifications in all cases ?
On
Hey Phil, (sorry for top-post, web client)
There's no firm rule for requiring .start/.end and I think your criteria
defines it well. Long running transactions (or multi complex-step transactions).
The main motivator behind .start/.end code was .error notifications not getting
generated in many
+1, the high-level code should deal with top-level exceptions and generate
.error notifications (though it's a little spotty). Ideally we shouldn't need
three events for simple operations.
The use of .start/.end vs. logging is a bit of a blurry line. At its heart a
notification should provide
confirmed
On 22/09/14 04:59 AM, David Lyle wrote:
I would like to announce my candidacy for Horizon PTL.
I've been actively contributing to Horizon since the Grizzly cycle and
I've been a core contributor since the Havana cycle. For the last two
cycles, I have had the pleasure of serving as
confirmed
On 22/09/14 02:49 AM, Flavio Percoco wrote:
Greetings,
I'd like to announce my candidacy for the Message Program PTL position.
I've been part of this program since its inception. Along with a really
amazing team, I've been working on changing the openstack messaging
service
Hi all,
The bug on updating documentation for overview / details
https://bugs.launchpad.net/sahara/+bug/1350063 also requires the changing
of image openstack-interop.png. So is there any specific tool used for
creating the image? Since I am working on fixing this bug, I thought I
could also
On 09/22/2014 10:56 AM, Flavio Percoco wrote:
What I meant is that oslo.messaging is an rpc library and it depends on
few very specific message delivery patterns that are somehow tight/based
on AMQP semantics.
RPC at it's core is the request-response pattern which is directly
supported by
Dear Infra team,
We have set up Coraid CI system to test Coraid Cinder driver. It is located
here - http://38.111.159.9:8080/job/CoraidCI/
We have done all requirements for Third Party CI system, provided here -
http://ci.openstack.org/third_party.html#requirements
Please add voting rights to
Hello,
I used google docs to create the initial image. If you want to edit that
one, copy the doc[1] to your drive and edit it. It is not the latest
version of the image, but the only difference is that this one has the very
first project name EHO in place of Sahara.
Thanks,
Dmitry
[1]
On 09/22/2014 02:35 PM, Gordon Sim wrote:
On 09/22/2014 10:56 AM, Flavio Percoco wrote:
What I meant is that oslo.messaging is an rpc library and it depends on
few very specific message delivery patterns that are somehow tight/based
on AMQP semantics.
RPC at it's core is the
https://wiki.openstack.org/wiki/Meetings/NeutronDB
The work on healing and reorganizing Neutron DB migrations is complete, and so
we will no longer hold meetings.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
FWIW, I think this is a great approach to evolving our thinking of the projects
and ecosystem around OpenStack. I’m far too removed these days from the details
of the day-to-day running of the programs and projects to comment on details.
But, I’ve long felt a need to go beyond the simple core +
I updated the corresponding entry in https://wiki.openstack.org/wiki/Meetings .
Thanks for the great work of the team (and folks assisting them).
I believe this kind of meetings which focus on a specific topic was
really useful.
Thanks,
Akihiro
On Mon, Sep 22, 2014 at 10:26 PM, Henry Gessau
On 09/19/2014 09:13 PM, Zane Bitter wrote:
SQS offers very, very limited guarantees, and it's clear that the reason
for that is to make it massively, massively scalable in the way that
e.g. S3 is scalable while also remaining comparably durable (S3 is
supposedly designed for 11 nines, BTW).
On Thu, Aug 28, 2014 at 12:22 PM, Richard Woo richardwoo2...@gmail.com
wrote:
I have another question about incubator proposal, for CLI and GUI. Do we
imply that the incubator feature will need to branch python-neutron client,
Horizon, and or Nova ( if changes are needed)?
This is as good
So
On 22/09/2014 10:01 PM, Zane Bitter zbit...@redhat.com wrote:
On 20/09/14 04:17, Geoff O'Callaghan wrote:
Hi all,
I'm just trying to understand the messaging strategy in openstack.It
seems we have at least 2 messaging layers.
Oslo.messaging and zaqar, Can someone explain to me why
On 09/22/2014 07:24 AM, Daniel P. Berrange wrote:
On Mon, Sep 22, 2014 at 11:03:02AM +, Day, Phil wrote:
Hi Folks,
I'd like to get some opinions on the use of pairs of notification
messages for simple events. I get that for complex operations on
an instance (create, rebuild, etc) a start
On 09/22/2014 07:35 AM, Day, Phil wrote:
I'm just a tad worried that this sounds like its starting to use
notification as a replacement for logging.If we did this for
every CRUD operation on an object don't we risk flooding the
notification system.
Notifications of this sort aren't a
Dearest stackers and [key]stoners,
With the PTL candidacies officially open for Kilo, I'm going to take the
opportunity to announce that I won't be running again for the position.
I thoroughly enjoyed my time as PTL during Havana, Icehouse and Juno. There
was a perceived increase in stability
On Mon, Sep 22, 2014 at 4:29 AM, Kenichi Oomichi oomi...@mxs.nes.nec.co.jp
wrote:
Hi Alex,
Thank you for doing this.
-Original Message-
From: Alex Xu [mailto:x...@linux.vnet.ibm.com]
Sent: Friday, September 19, 2014 3:40 PM
To: OpenStack Development Mailing List
Subject:
On Sun, Sep 21, 2014 at 3:58 PM, Kevin Benton blak...@gmail.com wrote:
So based on those guidelines there would be a problem with the IBM patch
because it's storing the tenant name in a backend controller, right?
It would need to be regarded as an expiring cache if Neutron chose to go
that
On 09/22/2014 07:37 AM, Sandy Walsh wrote:
For some operations like resize, migrate, etc., the .start/.end is
good for auditing and billing. Although, we could do a better job by
simply managing the launched_at, deleted_at times better.
I'm sure I'll get no real disagreement from you or
On 09/21/2014 07:37 PM, Matt Riedemann wrote:
On 9/19/2014 8:13 AM, Sean Dague wrote:
I've spent the better part of the last 2 weeks in the Nova bug tracker
to try to turn it into something that doesn't cause people to run away
screaming. I don't remember exactly where we started at open bug
Just want to say thanks for your leadership over the years, Dolph.
All the best,
-jay
On 09/22/2014 10:47 AM, Dolph Mathews wrote:
Dearest stackers and [key]stoners,
With the PTL candidacies officially open for Kilo, I'm going to take the
opportunity to announce that I won't be running again
Hi,
In convergence, we discuss about having concurrent updates to a stack. I
wanted to know if it is safe to assume that the an update will be a
super set of it's previous updates. Understanding this is critical to
arrive at implementation of concurrent stack operations.
Assuming that an admin
Horizon's tests were recently broken by a change in the Ceilometer
client that removed a deprecated exception. The exception was deprecated
for a while already, but as it often is, nobody did the
work of removing all references to it from Horizon before it was too
late. Sure, in theory we should
Hi,
One of the steps in the direction of convergence is to enable Heat
engine to handle concurrent stack operations. The main convergence spec
talks about it. Resource versioning would be needed to handle concurrent
stack operations.
As of now, while updating a stack, a backup stack is created
+1000!!! Dolph, you did a fantastic job leading the Keystone project.
Many thanks for all of your efforts!!!
--Brad
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From: Jay Pipes
Hi Jay,
There was actually a discussion about file a blueprint for object
notification http://markmail.org/message/ztehzx2wc6dacnk2
But for patch https://review.openstack.org/#/c/107954/ , I'd like we keep
it as it is now to resolve the requirement of server group notifications
for 3rd party
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 22/09/14 17:07, Radomir Dopieralski wrote:
Horizon's tests were recently broken by a change in the Ceilometer
client that removed a deprecated exception. The exception was
deprecated for a while already, but as it often is, nobody did the
On 09/22/2014 11:24 AM, Ihar Hrachyshka wrote:
On 22/09/14 17:07, Radomir Dopieralski wrote:
Horizon's tests were recently broken by a change in the Ceilometer
client that removed a deprecated exception. The exception was
deprecated for a while already, but as it often is, nobody did the
On Sep 21, 2014, at 9:59 PM, Adam Young ayo...@redhat.com wrote:
On 09/19/2014 01:43 PM, Doug Hellmann wrote:
On Sep 19, 2014, at 6:56 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
On 18/09/2014 22:14, Doug Hellmann wrote:
On Sep 18, 2014, at 4:34 PM, David Chadwick
From: Jay Pipes [jaypi...@gmail.com]
Sent: Monday, September 22, 2014 11:51 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] - do we need .start and .end notifications
in all cases ?
On 09/22/2014 07:37 AM, Sandy Walsh wrote:
On 22/09/14 10:40, Geoff O'Callaghan wrote:
So
On 22/09/2014 10:01 PM, Zane Bitter zbit...@redhat.com wrote:
On 20/09/14 04:17, Geoff O'Callaghan wrote:
Hi all,
I'm just trying to understand the messaging strategy in openstack.It
seems we have at least 2 messaging layers.
Oslo.messaging
If you missed the inaugural OpenStack Bootstrapping Hour, it's here:
http://youtu.be/jCWtLoSEfmw . I think this is a fantastic idea and big
thanks to Sean, Jay and Dan for doing this. I liked the format, the
informal style and the content. Unfortunately I missed the live event,
but I can confirm
Regarding ceilometer client, we horizon team at least was not aware of
its deprecation.
It is not easy thta Horizon team is aware of such changes/warnings in
all integrated projects.
We might need some liaison from the integrated projects as other projects do.
Regarding client backward
On 09/22/2014 11:42 AM, Sandy Walsh wrote:
Totally agree. Though I would go one step further and say the Task state
transitions should be managed by notifications.
Then oslo.messaging is reduced to the simple notifications interface (no RPC).
Notification follow proper retry semantics and
On 09/22/2014 11:22 AM, Jay Lau wrote:
Hi Jay,
There was actually a discussion about file a blueprint for object
notification http://markmail.org/message/ztehzx2wc6dacnk2
But for patch https://review.openstack.org/#/c/107954/ , I'd like we
keep it as it is now to resolve the requirement of
On 09/22/2014 03:40 PM, Geoff O'Callaghan wrote:
That being said I'm not sure why a well constructed zaqar with an rpc
interface couldn't meet the requirements of oslo.messsaging and much more.
What Zaqar is today and what it might become may of course be different
things but as it stands
On 09/22/2014 08:58 AM, Matthew Booth wrote:
If you missed the inaugural OpenStack Bootstrapping Hour, it's here:
http://youtu.be/jCWtLoSEfmw . I think this is a fantastic idea and big
thanks to Sean, Jay and Dan for doing this. I liked the format, the
informal style and the content.
The larger problem here is that this breaks running Horizon unit tests on
all existing installs of Horizon including Havana, Icehouse and Juno if
those installations update to the newest python-ceilometerclient. I'm not
sure how to handle that type of deprecation other than forcing all existing
Hi all,
OK, so we had our inaugural OpenStack Bootstrapping Hour last Friday.
Thanks to Sean and Dan for putting up with my rambling about unittest
and mock stuff. And thanks to one of my pugs, Winnie, for, according to
Shrews, looking like she was drunk. :)
One thing we're doing today is a
Hi,
We finished deployment of 3d party CI for Сoraid Сinder driver.
Following instructions on
http://ci.openstack.org/third_party.html#requesting-a-service-account we
are asking to add gerrit CI account (coraid-ci) to the Voting Third-Party
CI Gerrit group
I'd like to throw my hat into the ring for another term as PTL of the QA
program.
The Juno cycle has been very productive with some big developments in the QA
program including: being the first cycle to implement branchless Tempest,
starting tempest-lib, and consolidating the devstack program
On 09/22/2014 12:31 PM, Mykola Grygoriev wrote:
Hi,
We finished deployment of 3d party CI for Сoraid Сinder driver.
Following instructions on
http://ci.openstack.org/third_party.html#requesting-a-service-account we
are asking to add gerrit CI account (coraid-ci) to the Voting Third-Party
confirmed
On 22/09/14 12:32 PM, Matthew Treinish wrote:
I'd like to throw my hat into the ring for another term as PTL of the QA
program.
The Juno cycle has been very productive with some big developments in the QA
program including: being the first cycle to implement branchless Tempest,
In Keystone, as Dolph says, a tenant name is not globally unique,
so IMHO tenant_id needs to be passed to a back-end controller
to ensure uniqueness of tenant (or project).
tenant_name can be an additional information.
For example it can be used in a GUI of a back-end controller,
so I think it
On 22/09/14 10:11, Gordon Sim wrote:
On 09/19/2014 09:13 PM, Zane Bitter wrote:
SQS offers very, very limited guarantees, and it's clear that the reason
for that is to make it massively, massively scalable in the way that
e.g. S3 is scalable while also remaining comparably durable (S3 is
On Mon, Sep 22, 2014 at 10:27 AM, Jay Pipes jaypi...@gmail.com wrote:
Hi all,
OK, so we had our inaugural OpenStack Bootstrapping Hour last Friday.
Thanks to Sean and Dan for putting up with my rambling about unittest and
mock stuff. And thanks to one of my pugs, Winnie, for, according to
On Mon, Sep 22, 2014 at 1:07 PM, John Griffith john.griffi...@gmail.com
wrote:
On Mon, Sep 22, 2014 at 10:27 AM, Jay Pipes jaypi...@gmail.com wrote:
Hi all,
OK, so we had our inaugural OpenStack Bootstrapping Hour last Friday.
Thanks to Sean and Dan for putting up with my rambling about
On Sep 22, 2014, at 9:26 AM, Henry Gessau ges...@cisco.com wrote:
https://wiki.openstack.org/wiki/Meetings/NeutronDB
The work on healing and reorganizing Neutron DB migrations is complete, and so
we will no longer hold meetings.
Great work by all who worked on this.
mark
On 09/21/2014 10:57 PM, Nader Lahouti wrote:
Thanks Kevin for bring it up in the ML, I was looking for a guideline or
any document to clarify issues on this subject.
I was told, even using keystone API in neutron is not permitted.
I recognize that I'm potentially without context for neutron
Greetings,
I will not be running for PTL for Glance for the Kilo release.
I want to thank all of the nice folks I've worked with--especially the
attendees and sponsors of the mid-cycle meetups, which I think were a major
success and one of the highlights of the project for me.
Cheers,
markwash
My team just ran into an issue where neutron was not passing unit tests
when run under Python 2.6. We tracked this down to a test support
function using collections.OrderedDict. This was in locally forked
code, but when I compared it to upstream code, I found that the code in
upstream neutron is
What about:
https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12
On 22 September 2014 10:23, Kevin L. Mitchell
kevin.mitch...@rackspace.com wrote:
My team just ran into an issue where neutron was not passing unit tests
when run under Python 2.6. We tracked this down to
In the patch being referred to here and in the IBM controller, the project
ID is the unique identifier used. The name is simply an additional piece of
information that may perhaps be used for debugging. The back-end
(controller) keeps a name not as a unique identifier but in addition to the
Akihiro Motoki amot...@gmail.com wrote on 09/22/2014 12:50:43 PM:
From: Akihiro Motoki amot...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 09/22/2014 12:53 PM
Subject: Re: [openstack-dev] [Neutron] - what integration
Geoff, do you expect all of our users to write all of their messaging
code in Python?
oslo.messaging is a _python_ library.
Zaqar is a service with a REST API -- accessible to any application.
As Zane's sarcastic reply implied, these are as related as sharks are
to tornados. Could they be
On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote:
What about:
https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12
Pulling in ordereddict doesn't do anything if your code doesn't use it
when OrderedDict isn't in collections, which is the case here. Further,
there's
Thanks Dolph!
On Mon, Sep 22, 2014 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com
wrote:
Dearest stackers and [key]stoners,
With the PTL candidacies officially open for Kilo, I'm going to take the
opportunity to announce that I won't be running again for the position.
I thoroughly
On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote:
On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote:
What about:
https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12
Pulling in ordereddict doesn't do anything if your code doesn't use it
when OrderedDict isn't in
Just as an update to what exactly is RHEL python 2.6...
This is the expanded source rpm:
http://paste.ubuntu.com/8405074/
The main one here appears to be:
- python-2.6.6-ordereddict-backport.patch
Full changelog @ http://paste.ubuntu.com/8405082/
Overall I'd personally like to get rid of
Thanks a lot Dolph!
2014-09-22 14:58 GMT-03:00 Nathanael Burton nathanael.i.bur...@gmail.com:
Thanks Dolph!
On Mon, Sep 22, 2014 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com
wrote:
Dearest stackers and [key]stoners,
With the PTL candidacies officially open for Kilo, I'm going to
I'm in favor of killing Python 2.6 with fire.
Honestly, I think it's hurting code readability and productivity --
You have to constantly think about whether or not some feature that
the rest of the universe is already using is supported in Python 2.6
whenever you write code.
As for readability,
Hi everyone,
The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting on Tuesday September 23rd, at 19:00 UTC in #openstack-meeting
Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)
Everyone
I suspect that the very reason underlying the existence of this thread
is that some users out there are not quite ready to pull the plug on
Python 2.6.
Any decision about stopping the support of Python 2.6 should not be
taken solely on making the developer's life easier, but maybe I am
stating
On Sep 19, 2014, at 10:37 PM, Monty Taylor mord...@inaugust.com wrote:
On 09/19/2014 03:29 AM, Thierry Carrez wrote:
Monty Taylor wrote:
I've recently been thinking a lot about Sean's Layers stuff. So I wrote
a blog post which Jim Blair and Devananda were kind enough to help me edit.
On Sep 19, 2014, at 6:29 AM, Thierry Carrez thie...@openstack.org wrote:
Monty Taylor wrote:
I've recently been thinking a lot about Sean's Layers stuff. So I wrote
a blog post which Jim Blair and Devananda were kind enough to help me edit.
http://inaugust.com/post/108
Hey Monty,
As
On Sep 18, 2014, at 2:53 PM, Monty Taylor mord...@inaugust.com wrote:
Hey all,
I've recently been thinking a lot about Sean's Layers stuff. So I wrote
a blog post which Jim Blair and Devananda were kind enough to help me edit.
http://inaugust.com/post/108
Enjoy.
I’ve read through
My general understanding is 2.6 support is deprecated for Juno, and fair
to be removed in Kilo.
So the killing it with fire should be able to happen soon.
-Sean
On 09/22/2014 02:52 PM, Armando M. wrote:
I suspect that the very reason underlying the existence of this thread
is that
The reason it was bounded was because we (the websockify upstream mantainers)
made a backwards-incompatible change (for good reasons -- it brought websockify
more inline with the Python standard library interfaces).
However, OpenStack had subclassed the WebSocketProxy code, and so the change
Monty, your messages are always super-entertaining to read.
They also generally have very good points, which is an added bonus :-P
- Original Message -
From: Monty Taylor mord...@inaugust.com
To: OpenStack Development Mailing List (not for usage questions)
Right, I understand that. However, the point is that the tenant name is
being stored outside of Keystone and it doesn't ever appear to be updated.
I had proposed a spec to cache the tenant names for the Big Switch code and
it was declined because of the duplication of information.
On Sep 22, 2014
I would like to announce my candidacy for the Infrastructure PTL.
I have developed and operated the project infrastructure for several
years and have been honored to serve as the PTL for the Juno cycle.
I was instrumental not only in creating the project gating system and
development process,
-Original Message-
From: Dolph Mathews dolph.math...@gmail.com
Reply: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: September 22, 2014 at 07:50:42
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Subject:
1 - 100 of 154 matches
Mail list logo
