Dmitry,
If you chose to use Rally framework for testing there are 3 opportunities:
- Keep Rally plugins (tests) in separated tree
- Keep Rally plugins (tests) in your project tree
- Keep Rally plugins (tests) in Rally repo
Rally plugins can be used for all kinds of testing: (perf,
On 06/10/2015 11:57 AM, Boris Pavlovic wrote:
Dmitry,
If you chose to use Rally framework for testing there are 3 opportunities:
- Keep Rally plugins (tests) in separated tree
- Keep Rally plugins (tests) in your project tree
- Keep Rally plugins (tests) in Rally repo
Rally plugins can
On 06/09/2015 08:15 PM, Robert Collins wrote:
I'm very glad folk are working on Python3 ports.
I'd like to call attention to one little wart in that process: I get
the feeling that folk are applying a massive regex to find things like
d.iteritems() and convert that to six.iteritems(d).
Hi Kirill,
+1 from my side, shellcheck + bashate can help to increase quality of CI
scripts.
On Wed, Jun 10, 2015 at 2:19 PM, Igor Yozhikov iyozhi...@mirantis.com
wrote:
Hi, I'm using shellcheck during automation scripts writing as linter and I
believe that incorporation of this tool for
Le 09/06/2015 18:31, Thierry Carrez a écrit :
We are currently exploring the option to repurpose the
openstack-announce ML to be the extensive record of release
announcements. It's part of a larger plan to streamline library
releases, about which Doug should start a discussion pretty soon now.
On 10/06/15 12:07, Robert Collins wrote:
On 10 June 2015 at 20:12, Matthias Runge mru...@redhat.com wrote:
Since our software is to be consumed by packages, shouldn't the packages
project consider itself to be responsible for global requirements? I.e.
checking, if requirements are packageable,
Hi, I'm using shellcheck during automation scripts writing as linter and I
believe that incorporation of this tool for additional verification in CI
is good idea.
Thanks,
Igor Yozhikov
Senior Deployment Engineer
at Mirantis http://www.mirantis.com
skype: igor.yozhikov
cellular: +7 901 5331200
On 10 June 2015 at 20:12, Matthias Runge mru...@redhat.com wrote:
Since our software is to be consumed by packages, shouldn't the packages
project consider itself to be responsible for global requirements? I.e.
checking, if requirements are packageable, if versions fit, etc.
I think we
Hi Derek,
I selected these 80 to move all of what RDO is currently maintaining on
gerrithub to review.openstack.org, this was perhaps too big a set and in RDO
we instead may need to go hybrid.
Yeah, In my opinion we ahve lots of repeated divergence between the
different python modules, so
+1, nice idea. Shell script are not easy to review - large files, not
covered by unit tests. Any automatic tool could be beneficial.
Regards
Filip
On 06/09/2015 09:58 PM, Kirill Zaitsev wrote:
Folks, I’ve got another proposal, mainly to the guys, who deal with CI
and test jobs daily.
What
On 10 June 2015 at 11:07, Robert Collins robe...@robertcollins.net wrote:
On 10 June 2015 at 20:12, Matthias Runge mru...@redhat.com wrote:
Since our software is to be consumed by packages, shouldn't the packages
project consider itself to be responsible for global requirements? I.e.
Dmitry,
We introduced recently dsvm rally ironic job:
https://review.openstack.org/#/c/187997/
Now we are working on Rally tests for Ironic:
https://review.openstack.org/#/c/186064/
Don't hesitate to join us=)
Best regards,
Boris Pavlovic
On Wed, Jun 10, 2015 at 1:23 PM, Dmitry Tantsur
Hi, QA folks!
As ironic-inspector is joining the openstack/* crows, we're faces with
integration testing question. At the summit we discussed with Devananda
that it makes sense for inspector + ironic integration test to live in
tempest with other bare metal tests.
However, judging by
On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote:
Hi Dmitry,
2015-06-10 16:11 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:
Hi, QA folks!
As ironic-inspector is joining the openstack/* crows, we're faces with
integration testing question. At the summit we discussed with Devananda that
it makes
On Wed, Jun 10, 2015 at 08:48:36AM +0200, Andreas Scheuring wrote:
Daniel,
if I got it right, the vif script blueprint only is about plug/unplug
operations and not about generating new xml representations for vif
types. What if for a new vif type it's sufficient to have the
get_config_*
Yes, static routes can be added to the router:
https://ask.openstack.org/en/question/42529/how-to-add-extra-static-route-in-neutron-havana/
host_routes are routes advertised to the clients via DHCP, they don't apply
to the router.
I also would like to know use case of static routes of router and
2015-06-10 16:48 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:
On 06/10/2015 09:40 AM, Ken'ichi Ohmichi wrote:
To solve it, we have decided the scope of Tempest as the etherpad
mentioned.
Are there any hints now on where we can start with our integration tests?
For the other projects, we
Hi All,
this oslotest release break oslo.messaging gate - unittest fails
with ImportError, on import mox from six.moves - [0].
It caused by commit [1], which removed adding mox to six moves.
There is a fix for oslo.messaging - [2] - please, help to merge it.
[0] -
Excerpts from Matthias Runge's message of 2015-06-10 12:29:45 +0200:
On 10/06/15 12:07, Robert Collins wrote:
On 10 June 2015 at 20:12, Matthias Runge mru...@redhat.com wrote:
Since our software is to be consumed by packages, shouldn't the packages
project consider itself to be
You would need to update the KMIPSecretStore or create a new
SecretStore to handle this. The logic should be behind the SecretStore
abstraction because Barbican only allows one active secret store.
I would think that the configuration file would have a listing of
available KMIP server URLs.
The
Can you check dmesg –T to see at least if the messages are not too old?
Are you using port2 as a connection to VM?
Lenny Verkhovsky
From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
Sent: Wednesday, June 10, 2015 10:34 AM
To: OpenStack Development Mailing List (not for usage
On 06/09/2015 04:54 PM, Jeremy Stanley wrote:
On 2015-06-09 10:55:55 +0200 (+0200), Thomas Goirand wrote:
[...]
That's far from being in place. Also, while we are removing point
releases, and support for Icehouse, we still don't have a common private
Gerrit for security, which we've been told
Hi,
Can we add static routes to the router which created by #neutron
router-create command ?
What is the defference static routes of router and --host_routes of subnet
?
I also would like to know use case of static routes of router and
--host_routes of subnet ?
Regards
Saju Madhavan
+91
First of all, apologies if this belongs strictly to openstack-docs,
based on multiple discussions in Vancouver I'd like more people to be aware of
this.
As announced in April and at the summit in May, RabbitMQ
team at Pivotal would like to help with OpenStack documentation and operations
On 10 June 2015 at 21:30, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/10/2015 02:15 AM, Robert Collins wrote:
I'm very glad folk are working on Python3 ports.
I'd like to call attention to one little wart in that process: I
get the
On 10 June 2015 at 09:53, Thomas Goirand z...@debian.org wrote:
On 06/05/2015 02:46 PM, Thierry Carrez wrote:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push
Short story:
- all runs of the tempest job are failing after ~ 1,5 - 2 hrs with FATAL:
java.io.IOException: Unexpected termination of the channel and jenkins
logs SEVERE: I/O error in channel d-p-c-local_01-1655 java.io.IOException:
Unexpected termination of the channel
Long story:
- Host is 4
michael mccune wrote:
The API working group has one new guidelines that is entering the freeze
period. We would like to ask all PTLs and CPLs, and other interested
parties, to take a look at these reviews. We will use lazy consensus at
the end of the freeze to merge them if there are no
Hello Manila,
There is a HDFS driver in Manila summited by our team in Kilo, so I guess we do
own this driver in Manila for current situation.
But, CI systems are really new to us, and we heard from other teams that they
took almost one year to implement a CI for going through all the company
On 06/05/2015 02:46 PM, Thierry Carrez wrote:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push date-based tags across supported projects from time to time.
(-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/10/2015 02:15 AM, Robert Collins wrote:
I'm very glad folk are working on Python3 ports.
I'd like to call attention to one little wart in that process: I
get the feeling that folk are applying a massive regex to find
things like
Hi all,
Thanks for starting this! I'd like to join you for the kick off meeting. In
which timezone are the times in the Doodle?
Cheers,
Victoria
2015-06-09 17:28 GMT-03:00 Sousou, Imad imad.sou...@intel.com:
Stackers – We’re happy to announce the creation of a Diversity Working
Group. The
Hi Mike,
Thanks a lot for your quick reply which is very useful to me.
On 06/09/2015 07:08 PM, Mike Bayer wrote:
On 6/9/15 9:26 AM, Thomas Goirand wrote:
Hi,
The python-sqlalchemy package has been uploaded to Debian Experimental,
and is about to be uploaded to Debian Unstable. So I wonder
Hi Dmitry,
2015-06-10 16:11 GMT+09:00 Dmitry Tantsur dtant...@redhat.com:
Hi, QA folks!
As ironic-inspector is joining the openstack/* crows, we're faces with
integration testing question. At the summit we discussed with Devananda that
it makes sense for inspector + ironic integration test
On 27/05/15 10:14, Thomas Goirand wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
tl;dr:
- - We'd like to push distribution packaging of OpenStack on upstream
gerrit with reviews.
- - The intention is to better share the workload, and improve the overall
QA for packaging *and*
As a further data point, Neutron has been trying to introduce
microversioning for a while, without success so far.
Given the sheer amount of backends the management layer integrates with,
and the constant need for the various subteams to experiment with the
API, the proposal [1] has probably some
On 10 June 2015 at 17:22, gordon chung g...@live.ca wrote:
maybe the suggestion should be don't blindly apply six.iteritems or items
rather than don't apply iteritems at all. admittedly, it's a massive eyesore,
but it's a very real use case that some projects deal with large data results
Victor Stinner wrote:
Le 09/06/2015 18:31, Thierry Carrez a écrit :
We are currently exploring the option to repurpose the
openstack-announce ML to be the extensive record of release
announcements. It's part of a larger plan to streamline library
releases, about which Doug should start a
Dave Walker wrote:
On 10 June 2015 at 09:53, Thomas Goirand z...@debian.org wrote:
What would be your preferred option ?
I see no point of doing D. I already don't use tarballs, and those who
do could as well switch to generating them (how hard is it to run
python setup.py sdist or git
On 2015-06-10 13:48:26 +0200 (+0200), Filip Blaha wrote:
+1, nice idea. Shell script are not easy to review - large files, not
covered by unit tests. Any automatic tool could be beneficial.
It's worth noting that just because your shell scripts don't have
their own validation tests doesn't mean
On 06/09/2015 01:25 PM, Doug Hellmann wrote:
Until now we have encouraged project teams to prepare their own
library releases as new versions of projects were needed. We've
started running into a couple of problems with that, with releases
not coming often enough, or at a bad time in the release
On 06/10/2015 12:25 PM, Dave Walker wrote:
The initial core reviewers was seeded by representatives of distro's and
vendors to get their input on viability in distro's.
Really? James, were you made core on the requirements?
I once tried to follow the requirements repo, though it moves too
Hi Orran,
We also have a project called Tricircle that aim to solve similar problem,
but with a different approach with Mercador. You and your team are more
than welcome to join the discussion we will hold in Tricircle Meeting.
See the details at
On Tue, Jun 09, 2015 at 05:21:18PM EDT, Kevin Benton wrote:
I wasn't planning on wiping them out for now since I'm leveraging a lot of
the extension loading that exists so someone can remove the namespaces if
they want.
OK - I'll take it on if there's no objections
--
Sean M. Collins
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/06/15 15:12, Thomas Goirand wrote:
The initial core reviewers was seeded by representatives of
distro's and
vendors to get their input on viability in distro's.
Really? James, were you made core on the requirements?
Believe it or not,
On 10 June 2015 at 15:12, Thomas Goirand z...@debian.org wrote:
On 06/10/2015 12:25 PM, Dave Walker wrote:
The initial core reviewers was seeded by representatives of distro's and
vendors to get their input on viability in distro's.
Really? James, were you made core on the requirements?
I
I don't think you need an entry per driver, you need an entry per
connection type - iSCSI, FC, DRDB, CEPH being the ones I can think of off
the top of my head
On 10 Jun 2015 16:57, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:
While investigating/discussing bug 1463525 [1] I remembered how
On 6/10/15, 09:12, Thomas Goirand z...@debian.org wrote:
On 06/10/2015 12:25 PM, Dave Walker wrote:
The initial core reviewers was seeded by representatives of distro's and
vendors to get their input on viability in distro's.
Really? James, were you made core on the requirements?
I once
Dear OpenStack community,
The short version: We are proposing a new set of use cases for OpenStack and a
set of
changes to enable a multi-landlord cloud model, where multiple service
providers can cooperate (and compete) to stand up services in a single
cloud. We had great feedback from the
While investigating/discussing bug 1463525 [1] I remembered how little I
know about what can actually come out of the connection_info dict
returned from the os-initialize_connection cinder API call.
So we added some debug logging in nova and I remembered that there are
potentially credentials
Good news: your fix is already merged into oslo.messaging ;-)
oslo.messaging now uses directly mox3, on Python 2 and Python 3.
Victor
Le 10/06/2015 14:04, Victor Sergeyev a écrit :
Hi All,
this oslotest release break oslo.messaging gate - unittest fails
with ImportError, on import mox from
Paul Belanger wrote:
While I haven't participated in release management before, I'd like to
volunteer my services to help. Where is the best place (IRC) to
collaborate?
I would encourage prospective release managers to join
#openstack-relmgr-office where Doug and I discuss that sort of things,
Hi Chen,
You can ask if OpenStack Infrastructure team can set up CI for this driver.
They have set up CI's for a few Cinder drivers based on open source storage
systems.
Thanks,
Xing
From: Li, Chen [mailto:chen...@intel.com]
Sent: Wednesday, June 10, 2015 3:48 AM
To: OpenStack Development
On 6/10/15 3:26 AM, Thomas Goirand wrote:
Hi Mike,
Thanks a lot for your quick reply which is very useful to me.
On 06/09/2015 07:08 PM, Mike Bayer wrote:
On 6/9/15 9:26 AM, Thomas Goirand wrote:
Hi,
The python-sqlalchemy package has been uploaded to Debian Experimental,
and is about to
Thanks for comment and suggestion!
there is also shutil2 framework for unit testing over shell scripts. We
shall consider it whether it could bring us value for the effort. I
personally have no strong opinion about that. Little contradiction to my
previous mail:-)
Regards
Filip
On
On Wed, Jun 10, 2015 at 5:24 PM, Ian Cordasco ian.corda...@rackspace.com
wrote:
On 6/10/15, 09:12, Thomas Goirand z...@debian.org wrote:
On 06/10/2015 12:25 PM, Dave Walker wrote:
The initial core reviewers was seeded by representatives of distro's and
vendors to get their input on
Hi All:
Just a reminder to FWaaS meeting attendees, as discussed in last weeks FWaaS
IRC [1], with all the PTO’s going on and the need for time to build up on the
SG alignment discussions – it was felt that it would be good to go to an
alternate week format. So the next meeting will be on Jun
On Wed, Jun 10, 2015 at 7:54 AM, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:
While investigating/discussing bug 1463525 [1] I remembered how little I
know about what can actually come out of the connection_info dict returned
from the os-initialize_connection cinder API call.
So we added
Hi Daniel, Neil and others,
I was thinking about introducing libvirt-network as a new vif type to
nova. It can be used when Neutron prepares a libvirt network for
attaching guests.
Would you see any general concerns with such an approach? Anything that
I need to consider with libvirt networks
Hi, Dmitry,
I guess the whole idea of new release models is NOT to tie projects to each
other any more except for The Big Release twice a year :) So I think no, we
don't need to. We still can do it, if we have something to release by the
time Ironic releases, but I suggest deciding it on
Daniel,
if I got it right, the vif script blueprint only is about plug/unplug
operations and not about generating new xml representations for vif
types. What if for a new vif type it's sufficient to have the
get_config_* method updated? In this case plug/unplug would be handled
by libvirt (like
On 4 June 2015 at 12:42, John Garbutt j...@johngarbutt.com wrote:
Hi,
Following up from nova-meetings and this summit session:
https://etherpad.openstack.org/p/YVR-nova-liberty-process
snip
With that in mind, does this seem like a good idea?
June 12: spec review day (to be confirmed)
Note
If anyone needs help with the timezone conversion, I recommend
http://www.timeanddate.com/worldclock/meeting.html
Just put in Portland and your nearest city into the boxes and you'll
get an hour-by-hour breakdown :)
On 10/06/15 23:39, Barrett, Carol L wrote:
The Doodle time zone doesn’t seem
On 10 June 2015 at 17:06, Fox, Kevin M kevin@pnnl.gov wrote:
So... as an op, without release notes, how am I supposed to figure out the
proper upgrade procedure's when you often have to lockstep, in the right
order, nova+neutron upgrades (or other project combinations)?
Thanks,
Kevin
The Doodle time zone doesn't seem to be appearing in the local timebased upon
the viewer.
Sorry - The time zone is US/Pacific time (UTC-7), you'll need to do your own
conversion.
Thanks
Carol
From: Sousou, Imad [mailto:imad.sou...@intel.com]
Sent: Tuesday, June 09, 2015 11:34 AM
To:
On Wed, Jun 10, 2015 at 10:40:02AM -0500, Matt Riedemann wrote:
This is a follow-on to the thread [1] asking about modeling the
connection_info dict returned from the os-initialize_connection API.
The more I think about modeling that in Nova, the more I think it should
really be modeled in
So... as an op, without release notes, how am I supposed to figure out the
proper upgrade procedure's when you often have to lockstep, in the right order,
nova+neutron upgrades (or other project combinations)?
Thanks,
Kevin
From: Thomas Goirand
Hello folks,
Thanks for the consideration of this feature. Does it seem realistic for a
Liberty release of Keystone middleware to expose X-Group-Ids, or would this be
an M and beyond sort of thing?
Thanks,
John
From: Henry Nash henryna...@mac.commailto:henryna...@mac.com
Reply-To: OpenStack
This is a follow-on to the thread [1] asking about modeling the
connection_info dict returned from the os-initialize_connection API.
The more I think about modeling that in Nova, the more I think it should
really be modeled in Cinder with an oslo.versionedobject since it is an
API contract
We're aiming for a Spec Proposal Freeze deadline for Liberty of June
23rd, but are requiring that specs are approved by our spec reviewers by
that date. The spec [1] is currently pretty straightforward and provides us
several benefits, so I don't expect it to be a complicated process, but is
On Tue, Jun 9, 2015 at 3:37 PM Robert Collins robe...@robertcollins.net
wrote:
On 10 June 2015 at 04:01, Michael Krotscheck krotsch...@gmail.com wrote:
Well, it looks like everyone has disqualified jslint and jshint, so let's
just make a decision there and remove them from the running.
On 2015-06-10 14:39:46 + (+), yang, xing wrote:
You can ask if OpenStack Infrastructure team can set up CI for
this driver. They have set up CI's for a few Cinder drivers based
on open source storage systems.
To be fair, the Infra team hasn't really written the jobs to test
those, but
Announcing Gertty 1.2.0
===
Gertty is a console-based interface to the Gerrit Code Review system.
Gertty is designed to support a workflow similar to reading network
news or mail. It syncs information from Gerrit to local storage to
support disconnected operation and easy
Hi all. I’ve been looking through the bugs/fixes we’ve made during kilo cycle.
Some of them are worthy of being backported to stable/juno. And some of the
fixes we’ve already made in liberty are worthy of being backported to
stable/kilo.
Since we’ve agreed on using tags for bugs I’ve marked
On 10/06/15 15:47, Andreas Scheuring wrote:
Hi Daniel, Neil and others,
I was thinking about introducing libvirt-network as a new vif type to
nova. It can be used when Neutron prepares a libvirt network for
attaching guests.
Would you see any general concerns with such an approach? Anything
On Wed, Jun 10, 2015 at 2:11 PM, Carl Baldwin c...@ecbaldwin.net wrote:
Folks,
As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to
propose Brian Haley as a member of the Neutron L3 core reviewer team.
Brian has been a long time contributor in Neutron showing expertise
+1
- Original Message -
Folks,
As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to
propose Brian Haley as a member of the Neutron L3 core reviewer team.
Brian has been a long time contributor in Neutron showing expertise
particularly in IPv6, iptables, and Linux
Oslo folks, everyone,
mox3 needs to be maintained since some of our projects use it and we
have it in our global requirements.
Here's the proposal from Doug - https://review.openstack.org/#/c/190330/
Any objections? Please chime in here or on the review.
thanks,
dims
--
Davanum Srinivas ::
On Jun 4, 2015, at 6:12 PM, JJ Asghar jasg...@chef.io wrote:
I have cut a new release of the knife-openstack[1] gem today. We have a
couple new features[2] which has been asked for a while.
I have pushed another pre-release (1.2.0.rc2) of knife-openstack.
The main change is support for
Hi Ian,
Thanks for your reply!
On 10/06/15 21:07, Ian Wells wrote:
I don't see a problem with this, though I think you do want plug/unplug
calls to be passed on to Neutron so that has the opportunity to set up
the binding from its side (usage 0) and tear it down when you're done
with it (usage
Doodle does this automatically. At least it presented me with what
appeared to be US East times. There is a box on the upper right that
tells you the time zone and lets you change it.
Pete
On Wed, 2015-06-10 at 23:43 +0800, Tom Fifield wrote:
If anyone needs help with the timezone conversion,
Folks,
As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to
propose Brian Haley as a member of the Neutron L3 core reviewer team.
Brian has been a long time contributor in Neutron showing expertise
particularly in IPv6, iptables, and Linux kernel matters. His
knowledge and
All,
I am taking over work on https://review.openstack.org/#/c/154521/ from
Johanness and have spent some time today discussing the current patchset and
what is remaining with Dan and Johannes.
I wanted to broach the topic of the remaining development with the lists to
make sure we go in the
+1 Brian will be a great addition for L3
On Wed, Jun 10, 2015, Carl Baldwin c...@ecbaldwin.net wrote:
Folks,
As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to
propose Brian Haley as a member of the Neutron L3 core reviewer team.
Brian has been a long time contributor in
I like the idea of having a named condition, but the issue is how to maintain
and control multiple of these conditions in a system that will use model
against current schema to determine changes.
I also agree that we should get the current patch in as soon as possible and
can move my -1 as a
On Wed, Jun 10, 2015 at 2:25 PM, Neil Jerram neil.jer...@metaswitch.com
wrote:
On 08/06/15 22:02, Kevin Benton wrote:
This depends on what initialize is supposed to be doing. If it's just a
one-time sync with a back-end, then I think calling it once in each
child process might not be what
The remaining work is to have a way of preventing database contracts
from running until data migrations that the column interacts with are
complete, this is not an easy problem to solve as the goal of the
online migrations is to do pure model based schema migrations and
there is no way of
On 08/06/15 22:02, Kevin Benton wrote:
This depends on what initialize is supposed to be doing. If it's just a
one-time sync with a back-end, then I think calling it once in each
child process might not be what we want.
I left a comment on Terry's patch. I think we should just use the
Forgive the top posting.
Thank you Jay for your clarification and apology.
I wrote the piece below **before** you sent out your email this
afternoon, so again this is nothing personal and not targeted at any
**specific** person.
With that said, I still think that what I have to say is still
I don't see a problem with this, though I think you do want plug/unplug
calls to be passed on to Neutron so that has the opportunity to set up the
binding from its side (usage 0) and tear it down when you're done with it
(usage 1).
There may be a set of races you need to deal with, too - what
The python-glanceclient release management team is pleased to announce:
Release of python-glanceclient version 0.19.0
Please find the details related to the release at:
https://launchpad.net/python-glanceclient/liberty/0.19.0https://launchpad.net/python-glanceclient/+milestone/v0.17.0
Cross-posting to -operators and -dev because this involves *packagers*
of OpenStack, as well as operators who use those packages.
Hello Operators,
First, let me start out by saying if you were offended by my snarky
comments at yesterday's TC meeting [1] regarding the direction of the
Ops
Thanks Jeremy. I assume Chen could follow this example to add a job for the
HDFS driver?
https://review.openstack.org/#/c/188744/
Thanks,
Xing
-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org]
Sent: Wednesday, June 10, 2015 11:40 AM
To: OpenStack Development
On Tue, Jun 09, 2015 at 04:33:41PM -0400, Ruby Loo wrote:
Hi,
I noticed (from reading the logs[1]) that there weren't many folks in this
week's weekly meeting. And no cores attended. And the sub-team reports (in
our etherpad[2]) were woefully lacking. I guess that means only driver
On 11 June 2015 at 03:29, Michael Krotscheck krotsch...@gmail.com wrote:
On Tue, Jun 9, 2015 at 3:37 PM Robert Collins robe...@robertcollins.net
wrote:
There are two package managers in the JavaScript world right now, one that
focuses on node.js/server dependencies (karma, lint, express,
On Tue, 9 Jun 2015, Luo Gangyi wrote:
In current, ceilometer load pollsters by agent namespace, So do you
mean you want load pollsters one by one through their name(maybe
defined in pipeline.yaml)?
If loading all pollsters in one time do not cost much, I think your
change is bit unnecessary.
On 2015-06-10 18:20:24 + (+), yang, xing wrote:
Thanks Jeremy. I assume Chen could follow this example to add a
job for the HDFS driver?
https://review.openstack.org/#/c/188744/
That's a fine short-form answer. The longer answer is to solicit
input from some of the people who have
On Tue, 9 Jun 2015, gordon chung wrote:
i still like the idea of splitting polling and processing task.
pros:
- it moves load off poll agents and onto notificaiton agent
- we essentially get free healthcheck events by doing this
con:
to play devil's advocate. the one down side is that now
After some upstream discussion, moving the meeting from 1600 to 1700 UTC does
not seem very popular.
It was brought up that changing the time to 16:30 UTC could accommodate more
people.
For the people that attend the 1600 UTC meeting time slot can you post further
feedback to address this?
Hi Adam,
Do you have any more information on the Boston University dorm situation?
On Tue, Jun 9, 2015 at 1:25 PM, Adam Young ayo...@redhat.com wrote:
Keystone Liberty Midcycle Meetup
Time and Location
When: July 15-17 (Wed-Fri)
Where: Boston University, Boston, MA, USA
Keystone
1 - 100 of 150 matches
Mail list logo
