Hi there,
The alarm code split blueprint¹ has been approved, and I finished the
split of the code base. It's available online at:
https://github.com/jd/aodh
tox -e pep8,py27,docs passes.
To me the next step is to:
1. Someone cares and review what I've done in the repository
2. import the
Adding -dev because of the reference to the Neutron Get me a network
spec. Also adding [nova] and [neutron] subject markers.
Comments inline, Kris.
On 05/22/2015 09:28 PM, Kris G. Lindgren wrote:
During the Openstack summit this week I got to talk to a number of other
operators of large
On 06/16/2015 08:00 AM, Dmitry Tantsur wrote:
16 июня 2015 г. 13:52 пользователь Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com написал:
On 06/16/2015 04:36 AM, Alex Xu wrote:
So if our min_version is 2.1 and the max_version is 2.50. That means
alternative implementations need
Andrew,
I've also noticed that incompatible changes are being introduced in JSON
schemas for different objects in almost every release. I hope that explicit
reference that lists and explains all parameters will discourage such
modifications, or at least will increase their visibility and allow to
The patch has been merged: https://review.openstack.org/#/c/190395
These plugins are now deleted from puppet-neutron:
* monolithic OVS (replaced in favor of ML2 with openvswitch mechanism
driver)
* monolithic Linux Bridge (replaced in favor of ML2 with linuxbridge
mechanism driver)
On 06/12/2015
On Tue, Jun 16, 2015 at 08:56:37AM +0200, Dmitry Tantsur wrote:
On 06/04/2015 08:58 AM, Xu, Hejie wrote:
Hi, guys,
I’m working on adding Microversion into the API-WG’s guideline which
make sure we have consistent Microversion behavior in the API for user.
The Nova and Ironic already have
Hi,
I forgot to attach some relevant config files:
/etc/neutron/plugins/ml2/ml2_conf.ini :
[ml2]
type_drivers = gre
tenant_network_types = gre
mechanism_drivers = openvswitch
[ml2_type_flat]
[ml2_type_vlan]
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vxlan]
[securitygroup]
Excerpts from Timur Nurlygayanov's message of 2015-06-16 12:49:02 +0300:
Hi Doug,
I suggest to use some version for neutron-*aas plugins, probably, 1.0.0
just to have one pattern for all components. If we will not use numbers for
the first releases (or release candidates) it will be hard to
FYI,
One of the things that came out of the summit for Devstack plans going
forward is to trim it back to something more opinionated and remove a
bunch of low use optionality in the process.
One of those branches to be trimmed is all the support for things beyond
RabbitMQ in the rpc layer.
+1 Sean.
-- dims
On Tue, Jun 16, 2015 at 9:22 AM, Sean Dague s...@dague.net wrote:
FYI,
One of the things that came out of the summit for Devstack plans going
forward is to trim it back to something more opinionated and remove a
bunch of low use optionality in the process.
One of those
On 06/16/2015 03:47 PM, Jim Rollenhagen wrote:
On Tue, Jun 16, 2015 at 08:56:37AM +0200, Dmitry Tantsur wrote:
On 06/04/2015 08:58 AM, Xu, Hejie wrote:
Hi, guys,
I’m working on adding Microversion into the API-WG’s guideline which
make sure we have consistent Microversion behavior in the API
On 06/16/2015 04:12 AM, Ken'ichi Ohmichi wrote:
2015-06-16 2:07 GMT+09:00 Jay Pipes jaypi...@gmail.com:
It has come to my attention in [1] that the microversion spec for Nova [2]
and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead
of the name of the API -- i.e.
Hi
So if our min_version is 2.1 and the max_version is 2.50. That means
alternative implementations need implement all the 50 versions
api...that sounds pain...
Yes, it's pain, but it's no different than someone who is following the
Amazon EC2 API, which cuts releases at a regular
On 06/16/2015 08:56 AM, Dmitry Tantsur wrote:
On 06/04/2015 08:58 AM, Xu, Hejie wrote:
Hi, guys,
I’m working on adding Microversion into the API-WG’s guideline which
make sure we have consistent Microversion behavior in the API for user.
The Nova and Ironic already have Microversion
On 16 June 2015 at 14:38, Lucas Alvares Gomes lucasago...@gmail.com wrote:
Hi
So if our min_version is 2.1 and the max_version is 2.50. That means
alternative implementations need implement all the 50 versions
api...that sounds pain...
Yes, it's pain, but it's no different than
On 6/15/15 8:34 PM, Philip Schwartz wrote:
I discussed this a bit earlier with John and we came up with a thought that I
was going to present after getting a little bit more documentation and spec
around. With out going into too much detail, here is the basics of the idea.
Add a new column
Excerpts from Thierry Carrez's message of 2015-06-16 11:45:51 +0200:
Doug Hellmann wrote:
[...]
I put together a little script [1] to try to count the previous
releases for projects, to use that as the basis for their first
SemVer-based version number. I pasted the output into an etherpad
Hi
after a migration of Havana to IceHouse (using controller and network
services/agents on the same physical node, and using OVS/GRE) we started
facing some network-related problems (the internal tag of the element
shown by ovs-vsctl show was set to 4095, which is wrong AFAIK). At the
On Thu, Apr 9, 2015 at 6:10 PM, Eric Blake ebl...@redhat.com wrote:
On 04/08/2015 11:22 PM, Deepak Shetty wrote:
+ [Cinder] and [Tempest] in the $subject since this affects them too
On Thu, Apr 9, 2015 at 4:22 AM, Eric Blake ebl...@redhat.com wrote:
On 04/08/2015 12:01 PM, Deepak
Hi,
I forgot to attach some relevant config files:
/etc/neutron/plugins/ml2/ml2_conf.ini :
[ml2]
type_drivers = gre
tenant_network_types = gre
mechanism_drivers = openvswitch
[ml2_type_flat]
[ml2_type_vlan]
[ml2_type_gre]
tunnel_id_ranges = 1:1000
[ml2_type_vxlan]
[securitygroup]
So I need to point out that the openstack-qa list isn't used anymore. We only
keep it around so we have a place to send for periodic test results. In the
future you should just send things to the openstack-dev ML with a [QA] tag
in the subject.
On Tue, Jun 16, 2015 at 05:25:30AM +, Tikkanen,
Stan, +100500
On Fri, Jun 12, 2015 at 3:13 PM, Stan Lagun sla...@mirantis.com wrote:
I'd rather go with Heat approach (job first) because it makes easier to track
what is left to port to Py34 and track progress in this area
Sincerely yours,
Stan Lagun
Principal Software Engineer @
16 июня 2015 г. 13:52 пользователь Jay Pipes jaypi...@gmail.com написал:
On 06/16/2015 04:36 AM, Alex Xu wrote:
So if our min_version is 2.1 and the max_version is 2.50. That means
alternative implementations need implement all the 50 versions
api...that sounds pain...
Yes, it's pain, but
Timur,
If old jQuery code (not AngularJS) is still used for processing 'Create
Image' form, then the spinner is shown just before submitting the form
contents [1] and hidden right after the request completes [2] in case the
form is being redrawn or the whole page is redrawn in case of redirect -
Out of the box, vms usually can contact the controllers though the routers nat,
but not visa versa. So its preferable for guest agents to make the connection,
not the controller connect to the guest agents. No floating ips, security group
rules or special networks are needed then.
Thanks,
Excerpts from Robert Collins's message of 2015-06-16 11:18:55 +1200:
At the moment we copy the global-requirements lines verbatim.
So if we have two lines in global-requirements.txt:
oslotest=1.5.1 # Apache-2.0
PyECLib=1.0.7 # BSD
with very different layouts
Most
On 06/16/2015 07:38 AM, Alex Xu wrote:
2015-06-16 18:57 GMT+08:00 Sean Dague s...@dague.net
mailto:s...@dague.net:
On 06/15/2015 03:45 PM, Kevin L. Mitchell wrote:
On Mon, 2015-06-15 at 13:07 -0400, Jay Pipes wrote:
The original spec said that the HTTP header should
On 06/16/2015 08:38 AM, Lucas Alvares Gomes wrote:
Hi
So if our min_version is 2.1 and the max_version is 2.50. That means
alternative implementations need implement all the 50 versions
api...that sounds pain...
Yes, it's pain, but it's no different than someone who is following the
Hi everyone,
Release announcements in OpenStack come in various forms and shapes. So
far we had:
- Integrated release service components being announced on
openstack-announce and openstack general lists.
- Other service components sometimes being announced on openstack-dev
- Oslo libraries
On Jun 15, 2015, at 02:48, Steven Dake (stdake)
std...@cisco.commailto:std...@cisco.com wrote:
I am proposing Harm Waites for the Kolla core team.
+1
Harm did excellent work on the designate container and does very thorough
reviews, the cinder container review being just one example among
On Tue, 16 Jun 2015, Julien Danjou wrote:
To me the next step is to:
1. Someone cares and review what I've done in the repository
2. import the code into openstack/aodh
Assuming that we'll do whatever is required to finish things after
moving it under openstack/ then whatever you've done in
Dulko, Michal wrote:
-Original Message-
From: Joshua Harlow [mailto:harlo...@outlook.com]
Sent: Friday, June 12, 2015 5:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [taskflow] Returning information from reverted
flow
Dulko, Michal
Hi all,
Steve suggested adding a new table to the Kolla wiki to help us keep
track of who's actively working on Kolla along with relevant info such
as timezones and IRC names.
I'm missing lots of names and timezones so if you'd like to be on this
please feel free to update it at
On 11.06.2015 18:52, Andreas Scheuring wrote:
Maybe this helps (taken from [1])
Actually there is one way that the MAC address of the tap device
affects
proper operation of guest networking - if you happen to set the tap
device's MAC identical to the MAC used by the guest, you will get errors
Here is a draft spec for this: https://review.openstack.org/#/c/192250/
Nikolay Starodubtsev
Software Engineer
Mirantis Inc.
Skype: dark_harlequine1
2015-06-16 13:11 GMT+03:00 Nikolay Starodubtsev nstarodubt...@mirantis.com
:
Hi all,
I've started a work on bp:
Doug Hellmann wrote:
Excerpts from Thierry Carrez's message of 2015-06-16 11:45:51 +0200:
We also traditionally managed the previously-incubated projects. That
would add the following to the mix:
barbican 1.0.0
designate 1.0.0
manila 1.0.0
zaqar 1.0.0
Those didn't have the
Hi all,
We have planned a fast track development for Glance Artifacts; also it
would be our v3 API. To balance pace, knowledge sharing, synchronous
discussion on ideas and opinions as well as seeing this great feature
through in Liberty:
We hereby propose a non-mandatory, open to all, sub-team
I was just looking at the patches that put Nova under apache wsgi for
the API, and there are a few things that I think are going in the wrong
direction. Largely I think because they were copied from the
lib/keystone code, which we've learned is kind of the wrong direction.
The first is the fact
Just for the sake of clarity- did the Horizon team discuss the tool
selection for JSCS with the greater community? I can't find anything on the
dev list. Furthermore, there've been situations before (karma) where a
patch was landed without appropriate upstream notifications and/or
discussion,
Hi folks!
I was reviewing one of specs for Fuel 7.0 and realized the information there is
messed up and it’s pretty hard to put it all together. The reason for that is
basically that Fuel is a multicomponent project but the template does not
consider that — there is a Proposed change section
On 06/15/2015 08:06 PM, Emilien Macchi wrote:
Hi everyone,
Here's an initial agenda for our weekly meeting tomorrow at 1500 UTC in
#openstack-meeting-4:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150616
Please add additional items you'd like to discuss
Hi,
I haven't paid any attention to ironic-lib; I just knew that we wanted to
have a library of common code so that we didn't cut/paste. I just took a
look[1] and there are files there from 2 months ago. So far, everything is
under ironic_lib (ie, no subdirectories to group things). Going
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi neutron folks,
I'd like to discuss a plan on getting support for online db schema
upgrades in neutron.
*What is it even about?*
Currently, any major version upgrade, or master-to-master upgrade,
requires neutron-server shutdown. After
Its unanimous! Welcome to the core reviewer team Harm!
Regards
-steve
From: Steven Dake std...@cisco.commailto:std...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Sunday, June
On Tue, Jun 16 2015, Chris Dent wrote:
5. anything in tempest to worry about?
Yes, we need to adapt and reenable tempest after.
6. what's that stuff in the ceilometer dir?
6.1. Looks like migration artifacts, what about migration in
general?
That's a rest of one of the many
Hi,
Some of our modules have stable/grizzly and stable/havana branches. Some
of them have the CI broken due to rspec issues that would require some
investigation and time if we wanted to fix it.
We would like to know who plan to backport some patches in these branches?
If nobody plans to do
Hello fellow stackers,
The Oslo team came up with a handful of requests to the projects that
use Oslo-*. Here they are:
0. Check if your project has a Oslo Liaison
Please see https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo
and volunteer for your project. We meet once a week to go over
On 6/16/15 11:41 AM, Ihar Hrachyshka wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
- - instead of migrating data with alembic rules, migrate it in runtime.
There should be a abstraction layer that will make sure that data is
migrated into new schema fields and objects, while
On 16 June 2015 at 03:12, Dmitry Tantsur dtant...@redhat.com wrote:
On 06/16/2015 08:58 AM, Ramakrishnan G wrote:
Hi All,
Some time back we created a new repository[1] to move all the reusable
code components of Ironic to a separate library. The branched out code
has changed and there
Doug Hellmann wrote:
Excerpts from Robert Collins's message of 2015-06-16 11:18:55 +1200:
At the moment we copy the global-requirements lines verbatim.
So if we have two lines in global-requirements.txt:
oslotest=1.5.1 # Apache-2.0
PyECLib=1.0.7 # BSD
with very
+1 Murali. AFIAK, there is no precedent for what Keith proposes, but that
doesn't mean its a bad thing.
On Jun 16, 2015, at 12:21 AM, Murali Allada murali.all...@rackspace.com wrote:
I agree, users should have a mechanism to keep logs around.
I implemented the logs deletion feature after we
Hi,
I haven't paid any attention to ironic-lib; I just knew that we wanted to
have a library of common code so that we didn't cut/paste. I just took a
look[1] and there are files there from 2 months ago. So far, everything is
under ironic_lib (ie, no subdirectories to group things). Going
On 06/16/2015 12:41 PM, Allison Randal wrote:
On 06/15/2015 01:43 PM, Paul Belanger wrote:
While I agree those points are valid, and going to be helpful, moving
under OpenStack (even Stackforge) does also offer the chance to get more
test integration upstream (not saying this was the original
What was the command you used? What was the output? Can you try running it
with --debug? More information is needed here.
It would also probably be quicker to jump on IRC and ask around.
Thanks,
Steve Martinelli
OpenStack Keystone Core
Ali Reza Zamani alireza.zam...@cs.rutgers.edu wrote on
On Thu, 11 Jun 2015 11:08:55 +0300
Duncan Thomas duncan.tho...@gmail.com wrote:
There's only one cinder driver using it (nimble storage), and it seems to
be using only very basic features. There are half a dozen suds forks on
pipi, or there's pisimplesoap that the debian maintainer recommends.
Right now I'm leaning toward parent always does nothing + PluginWorker.
Everything is forked, no special case for workers==0, and explicit
designation of the only one case. Of course, it's still early in the day
and I haven't had any coffee.
I have updated the patch
Hi all,
I have a problem in creating the instances. When I create the instances
using GUI web interface everything is fine. But when I do it using CLI
after spawning it says Error.
And the error is: ne
__
OpenStack
+1 from me for deprecation.
I'd also like to know or have an official policy for future deprecations,
such as when will we deprecate Icehouse?
On Tue, Jun 16, 2015 at 9:50 AM, Emilien Macchi emil...@redhat.com wrote:
Hi,
Some of our modules have stable/grizzly and stable/havana branches.
FYI, We will be closing the vote on Friday, June 19 at 1700 UTC.
On 6/15/15 7:41 PM, Nikhil Komawar wrote:
Hi,
As per the discussion during the last weekly Glance meeting (14:51:42at
http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-06-11-14.00.log.html
), we will begin a short
+1 great write-up Winson,
I propose we move the discussion to an etherpad, and flash out details there so
it won’t get lost in a long thread.
Winson would you care to create one and post here?
Re: ‘error state’: I think it’s not absolutely necessary: pause/resume can be
done without enabling
Here's the etherpad link. I replied to the comments/feedbacks there.
Please feel free to continue the conversation there.
https://etherpad.openstack.org/p/mistral-resume
__
OpenStack Development Mailing List (not for usage
Yes. I think this is possible with the HP 3PAR. I'd have to test more to be
sure, but if I understand the plan correctly, it'll work. However, there are
limited resources for doing this, so it'll only work if resources allow. I'm
thinking that the administrator config+startup/setup code
It is weired. I deleted my devstack and redo everything. I am using the
same command and everything is fine.
Thanks,
Regards,
On 06/16/2015 01:03 PM, Steve Martinelli wrote:
What was the command you used? What was the output? Can you try
running it with --debug? More information is needed
Thanks guys, both for all the nice words and the acceptance!
harmw
Op 16-06-15 om 16:32 schreef Steven Dake (stdake):
Its unanimous! Welcome to the core reviewer team Harm!
Regards
-steve
From: Steven Dake std...@cisco.com mailto:std...@cisco.com
Reply-To: OpenStack Development Mailing
Long term we want to see Keystone move to http://host/identity. However the
reason for choosing 5000/35357 for ports was compatibility and avoiding
breaking horizon. At the time we did the initial change over, sharing the root
80/443 ports with horizon was more than challenging since horizon
Matt Fischer wrote:
+1 from me for deprecation.
I'd also like to know or have an official policy for future
deprecations, such as when will we deprecate Icehouse?
On Tue, Jun 16, 2015 at 9:50 AM, Emilien Macchi emil...@redhat.com
mailto:emil...@redhat.com wrote:
Hi,
Some of our
On 06/16/2015 05:28 AM, Clark, Robert Graham wrote:
I’d like to nominate Travis for a CoreSec position as part of the
Security project. - CoreSec team members support the VMT with extended
consultation on externally reported vulnerabilities.
Travis has been an active member of the Security
On 2015-06-16 12:58:18 -0400 (-0400), Sean Dague wrote:
[...]
I think the only complexity here is the fact that grenade.sh
implicitly drives stack.sh. Which means one of:
1) devstack-gate could build the worker first, then run grenade.sh
2) we make it so grenade.sh can execute in parts
On Tue, Jun 16, 2015 at 12:33 AM, Kevin Benton blak...@gmail.com wrote:
Do these kinds of test even make sense? And are they feasible at all? I
doubt we have any framework for injecting anything in neutron code under
test.
I was thinking about this in the context of a lot of the fixes we have
On 06/16/2015 12:49 PM, Clint Byrum wrote:
Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700:
FYI,
One of the things that came out of the summit for Devstack plans going
forward is to trim it back to something more opinionated and remove a
bunch of low use optionality in the
+1 for deprecation
--
David Moreau Simard
On 2015-06-16 11:54 AM, Emilien Macchi wrote:
Hi,
Some of our modules have stable/grizzly and stable/havana branches. Some
of them have the CI broken due to rspec issues that would require some
investigation and time if we wanted to fix it.
We
Using admin token credentials with the Keystone v2.0 API and the
openstackclient, doing this:
# openstack project create bar --enable
# openstack user create foo --project bar --enable ...
The user will be added to the project.
Using admin token credentials with the Keystone v3 API and the
On Thu, Jun 11, 2015 at 2:45 PM, Salvatore Orlando sorla...@nicira.com wrote:
I have been then following a different approach. And a set of patches,
including a devref one [2], if up for review [3]. This hardly completes the
job: more work is required on the testing side, both as unit and
Excerpts from Sean Dague's message of 2015-06-16 06:22:23 -0700:
FYI,
One of the things that came out of the summit for Devstack plans going
forward is to trim it back to something more opinionated and remove a
bunch of low use optionality in the process.
One of those branches to be
On Jun 15, 2015, at 9:10 PM, Keith Bray
keith.b...@rackspace.commailto:keith.b...@rackspace.com wrote:
Regardless of what the API defaults to, could we have the CLI prompt/warn so
that the user easily knows that both options exist? Is there a precedent
within OpenStack for a similar
In Murano project we do see a positive impact of BigTent model. Since
Murano was accepted as a part of BigTent community we had a lot of
conversations with potential users. They were driven exactly by the fact
that Murano is now officially recognized in OpenStack community. It might
be a wrong
On 06/12/2015 09:41 PM, Alec Hothan (ahothan) wrote:
One long standing issue I can see is the fact that the oslo messaging API
documentation is sorely lacking details on critical areas such as API
behavior during fault conditions, load conditions and scale conditions.
I very much agree,
Hi all,
In the last couple of IRCs we've been talking about running a mid-cycle
sprint focused on enabling our message bus to span multiple processes and
multiple hosts. The message bus is what allows the Congress policy engine
to communicate with the Congress wrappers around external services
The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all
very similar.
I want to extract a common base class that abstracts some of the common
code and then let the sub-classes provide overrides where necessary.
As part of this, I'm wondering if we could just have a single
On Tue, 16 Jun 2015, Sean Dague wrote:
I was just looking at the patches that put Nova under apache wsgi for
the API, and there are a few things that I think are going in the wrong
direction. Largely I think because they were copied from the
lib/keystone code, which we've learned is kind of the
On 06/16/2015 12:06 PM, Thierry Carrez wrote:
It also removes the stupid encouragement to use all components from the
same date. With everything tagged at the same date, you kinda send the
message that those various things should be used together. With
everything tagged separately, you send te
On 06/15/2015 01:43 PM, Paul Belanger wrote:
While I agree those points are valid, and going to be helpful, moving
under OpenStack (even Stackforge) does also offer the chance to get more
test integration upstream (not saying this was the original scope).
However, this could also be achieved
Back when Nova first wanted to test partial upgrade, we did a bunch of
slightly odd conditionals inside of grenade and devstack to make it so
that if you were very careful, you could just not stop some of the old
services on a single node, upgrade everything else, and as long as the
old services
I’m copying and pasting from the other thread some info below.
I think agreeing on rules is the bigger problem here and I don’t think all
the projects should have to agree on rules. We’ve spent a good portion of
liberty 1 getting the code base cleaned up to meet the already adopted
horizon rules
On 6/16/2015 4:21 PM, Matt Riedemann wrote:
The NFS, GlusterFS, SMBFS, and Quobyte libvirt volume drivers are all
very similar.
I want to extract a common base class that abstracts some of the common
code and then let the sub-classes provide overrides where necessary.
As part of this, I'm
While I agree with what you're saying, the way the OpenStack clients are
traditionally written/designed, the CLI *is* the SDK for those users who want
to do scripting in a shell rather than in Python. If we go with your
suggestion, we'd probably also want to have the ability to suppress those
Isn't that what the SDK is for? To chip in with a Product Management type hat
on, I'd think the CLI should be primarily focused on user experience
interaction, and the SDK should be primarily targeted for developer automation
needs around programmatically interacting with the service. So, I
That makes sense Randall.. .a sort of Novice mode vs. Expert mode.
I definitely want to see OpenStack to get easier to use, and lower the
barrier to entry. If projects only cater to developers, progress will be
slower than what it could be.
-Keith
On 6/16/15 4:52 PM, Randall Burt
On 06/16/2015 12:25 PM, Sean Dague wrote:
I was just looking at the patches that put Nova under apache wsgi for
the API, and there are a few things that I think are going in the wrong
direction. Largely I think because they were copied from the
lib/keystone code, which we've learned is kind of
Excerpts from Thierry Carrez's message of 2015-06-16 11:45:51 +0200:
Doug Hellmann wrote:
[...]
I put together a little script [1] to try to count the previous
releases for projects, to use that as the basis for their first
SemVer-based version number. I pasted the output into an etherpad
I'm ok with moving to 16:30 UTC instead of staying at 16:00.
I actually prefer it in my evening schedule :) Moving to 16:30 would
already be a great improvement to the current schedule and should at
least allow me to not miss everything.
- harmw
Op 12-06-15 om 15:44 schreef Steven Dake
On 06/16/2015 12:48 PM, Morgan Fainberg wrote:
Long term we want to see Keystone move to http://host/identity. However the reason for choosing
5000/35357 for ports was compatibility and avoiding breaking horizon. At the time we did the initial
change over, sharing the root 80/443 ports with
On Tue, Jun 16, 2015 at 10:22 AM Tripp, Travis S travis.tr...@hp.com
wrote:
I think agreeing on rules is the bigger problem here and I don’t think all
the projects should have to agree on rules.
I believe we agree there, mostly. I personally feel there is some benefit
to setting some rules,
Some more comments inline.
Salvatore
On 16 June 2015 at 19:00, Carl Baldwin c...@ecbaldwin.net wrote:
On Tue, Jun 16, 2015 at 12:33 AM, Kevin Benton blak...@gmail.com wrote:
Do these kinds of test even make sense? And are they feasible at all? I
doubt we have any framework for injecting
Gordon,
These are all great points for RPC messages (also called CALL in oslo
messaging). There are similar ambiguous contracts for the other types of
messages (CAST and FANOUT).
I am worried about the general lack of interest from the community to fix
this as it looks like most people assume
On 06/15/2015 10:55 AM, James Page wrote:
We understand and have communicated from the start of this
conversation that we will need to be able to maintain deltas between
Debian and Ubuntu - for both technical reasons, in the way the
distributions work (think Ubuntu main vs universe), as well as
On 16 June 2015 at 18:49, Carl Baldwin c...@ecbaldwin.net wrote:
On Thu, Jun 11, 2015 at 2:45 PM, Salvatore Orlando sorla...@nicira.com
wrote:
I have been then following a different approach. And a set of patches,
including a devref one [2], if up for review [3]. This hardly completes
the
On 13:00 Jun 15, Jayanthi, Swaroop wrote:
Hi All,
I am trying to create a Volume for VMFS with a Volume Type (selected Volume
Type selected has extra_specs).I am receiving an error Volume creation
failed incase if the volume-type has extra-specs.
Cinder doesn't support Volume
let's release this last one (codename: Farewell ?) point release. I
can do this next week after we finish pending reviews.
Remaining stable/icehouse reviews[1] have -2 or -1 except
https://review.openstack.org/176019 which I've asked
neutron-stable-maint to review.
Matt, anything else before we
I don't think you need a spec for this (its a refactor). That said,
I'd be interested in exploring how you deprecate the old flags. Can
you have more than one deprecated name for a single flag?
Michael
On Wed, Jun 17, 2015 at 7:29 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:
On
1 - 100 of 165 matches
Mail list logo
