Hi All,
I was terribly SAD indeed that our spec proposal to add gw-mode
extension[1] to the midonet plugin was not accepted last Sunday, and I am
sending out this email to see if the core reviewers could accept this as
SFE.
It was originally rejected because the upstream plugin was not working
Greetings,
I'm trying to figure out if Keystone can support more granular role
management or if there is any plan to do that in the future. Currently,
AWS can support adding a role and assigning the capability from 3
different level/perspective: service, function and resource[1]. Keystone
can
Hi Jay,
Thank you for your response.
I will soon submit patch for the same.
Thanks,
Rajesh Tailor
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Tuesday, July 22, 2014 8:07 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] Use
Le 23/07/2014 01:11, Michael Still a écrit :
This spec freeze exception only has one core signed up. Are there any
other cores interested in working with Sylvain on this one?
Michael
By looking at
https://etherpad.openstack.org/p/nova-juno-spec-priorities, I can see
ndipanov as volunteer for
On Tue, Jul 22, 2014 at 9:18 PM, Jay Dobies jason.dob...@redhat.com wrote:
At the meetup today, the topic of our spec process came up. The general
sentiment is that the process is still young and the hiccups are expected,
but we do need to get better about making sure we're staying on top of
Maybe we can implement this goal by another way, adding new API
'confirm_before_migration' that's similar with 'confirm_resize'. This
also can resolve Chris Friesen's concern.
On 2014年07月23日 00:13, Jay Pipes wrote:
On 07/21/2014 11:16 PM, Jay Lau wrote:
Hi Jay,
There are indeed some China
Thanks Alex and Jay Pipes.
@Alex, I want a common interface for all VM operations to get target host
list, seems only adding a new API 'confirm_before_migration' not enough to
handle this? ;-)
@Jay Pipes, I will try to see if we can export this in K or L via Gantt
Thanks.
2014-07-23 17:14
(Resending to properly start new thread.)
Hi,
I'm running a HA overcloud configuration and as far as I'm aware, there is
currently no mechanism in place for restarting failed nodes in the cluster.
Originally, I had been wondering if we would use a corosync/pacemaker cluster
across the
Answers to some of your concerns
Why can't ESXi hosts not run the nova-compute service? Is it like the
XenServer driver that has a pitifully old version of Python (2.4) that
constrains the code that is possible to run on it? If so, then I don't
really think the poor constraints of the
Hi,
The Debian maintainer of python-django would like to upgrade to version
1.7. He asked, in multiple bug reports, to check for Django 1.7
compatibility. I have the following python modules and bug reports:
https://bugs.debian.org/755613 python-django-appconf
https://bugs.debian.org/755622
Hi,
I'm working on TLS integration with loadbalancer v2 extension and db.
Basing on Brandon's patches https://review.openstack.org/#/c/105609 ,
https://review.openstack.org/#/c/105331/ ,
https://review.openstack.org/#/c/105610/
I will abandon previous 2 patches for TLS which are
Oh sorry... I thought it was about Ironic not TripleO (morning issues)
Anyway, it could be something that we could adopt in Ironic as well :)
On Wed, Jul 23, 2014 at 9:40 AM, Lucas Alvares Gomes
lucasago...@gmail.com wrote:
On Tue, Jul 22, 2014 at 9:18 PM, Jay Dobies jason.dob...@redhat.com
I was having a bit of a browse through the ceilometer code and
noticed there are a fair few instances (sixty-some) of
`except Exception` scattered about.
While not as evil as a bare except, my Python elders always pointed
out that doing `except Exception` is a bit like using a sledgehammer
Hi Thomas,
On Wed, Jul 23, 2014 at 06:56:51PM +0800, Thomas Goirand wrote:
First, does anyone know if Django 1.7 is an issue with any of the above
packages? If there are effectively issues, is there currently any plan
to fix it?
Ideally, I would like all of the above packages to be able to
Hi folks,
I'm planning to fix bug/1330095[1], which aims to solve the invalid suffix uri
as follow, but I hit a problem of cisco n1kv plugin testing case[2].
[1] https://bugs.launchpad.net/neutron/+bug/1330095
When submitting a REST request as follow:
POST
I'm sure it is not news to anyone that we already have approved a too many
specifications for Juno-3. The PTL made clear indeed that Low priority
blueprints are considered best effort.
However, this already leaves us with 23 medium to high specifications to
merge in Juno-3. This is already quite
Hello, Stackers.
I’d like to discuss guestagent prepare call polling mechanism issue (see
[1]).
Let me first describe why this is actually an issue and why it should be
fixed. For those of you who is familiar with Trove knows that Trove can
provision instances through Nova API and Heat API (see
Hello, Stackers.
For those of you who’s interested in Trove just letting you know, that for
now Trove can work with Neutron (hooray!!)
instead of Nova-network, see [1] and [2]. It’s a huge step forward on the
road of advanced OpenStack integration.
But let’s admit it’s not the end, we should
Andrew,
thanks for pointing this out. Engineering in Europe has code review in
priority #1 after fixing critical issues which block us from further
testing.
Overall, I think it should be simple. If developer didn't push the crowd to
review the patch linked to Low/Medium bug, and it didn't get
Here I am again bothering you with the state of the full job for Neutron.
The patch for fixing an issue in nova's server external events extension
merged yesterday [1]
We do not have yet enough data points to make a reliable assessment, but of
out 37 runs since the patch merged, we had only 5
We are currently working to support Barbican for Cinder volume encryption. Some
links to our work are as follows:
Blueprint:
https://blueprints.launchpad.net/cinder/+spec/encryption-with-barbican
Specification: https://review.openstack.org/#/c/106437/ (needs approval from
another Cinder core)
Thanks. It really help. Thanks a lot.
At 2014-07-23 02:45:40, Vishvananda Ishaya vishvana...@gmail.com wrote:
Workers can consume more than one message at a time due to
eventlet/greenthreads. The conf option rpc_thread_pool_size determines how many
messages can theoretically be handled at
At 2014-07-23 00:09:09, Lingxian Kong anlin.k...@gmail.com wrote:
Maybe you are using local storage for your vm system volume backend,
accroding to the 'resize' implementation, 'rsync' and 'scp' will be
executed during the resize process, which will be the bottleneck
No, i use nfs. I found
On Wed, Jul 23, 2014 at 02:40:02PM +0200, Salvatore Orlando wrote:
Here I am again bothering you with the state of the full job for Neutron.
The patch for fixing an issue in nova's server external events extension
merged yesterday [1]
We do not have yet enough data points to make a reliable
On Tue, Jul 22, 2014 at 9:18 PM, Jay Dobies jason.dob...@redhat.com wrote:
What are everyone's feelings on adding a 1 spec review per week requirement
for cores?
Averaged over the standard 90d period I presume?
+1 here.
Alexis
--
Nova Engineer, HP Cloud. AKA lealexis, lxsli.
On Wed, Jul 23, 2014 at 7:28 AM, Salvatore Orlando sorla...@nicira.com wrote:
I'm sure it is not news to anyone that we already have approved a too many
specifications for Juno-3. The PTL made clear indeed that Low priority
blueprints are considered best effort.
However, this already leaves
For everyone's reference, the tripleo-specs stats can be found here:
http://www.nemebean.com/reviewstats/tripleo-specs-30.txt
Note that looking at the stats, over 30 days 1 review per week is only
4, which most of our cores are already doing anyway. I'm not sure
codifying a requirement to do at
During this cycle we introduced migrations based on Alembic
https://bitbucket.org/zzzeek/alembic framework that are incompatible with
previous set of migrations based on sqlalchemy-migrate
https://github.com/stackforge/sqlalchemy-migrate. This changes are going
to be included to MOS with release
On Wed, Jul 23, 2014 at 1:03 AM, Fei Long Wang feil...@catalyst.net.nz
wrote:
Greetings,
I'm trying to figure out if Keystone can support more granular role
management or if there is any plan to do that in the future. Currently,
AWS can support adding a role and assigning the capability from
Hi Serg,
what needs to be done in order to include Alembic-related stuff into 5.1?
The thing is that we are just a day before Soft Code Freeze.
If this is trivial operation, such as adding a new package and updating
configuration file, then we could consider it to be included.
Thanks,
On Wed,
On 18/07/14 08:35, Matt Riedemann wrote:
On 7/17/2014 5:48 PM, Steve Baker wrote:
On 18/07/14 00:44, Joe Gordon wrote:
On Wed, Jul 16, 2014 at 11:28 PM, Steve Baker sba...@redhat.com
mailto:sba...@redhat.com wrote:
On 12/07/14 09:25, Joe Gordon wrote:
On Fri, Jul 11, 2014 at
Hi, Mike,
I can't be specific about implementation details due to lack of expertise
in Fuel, but to properly handle update of Murano from previous version to
MOS 5.1 we need to:
1. show warning to the user about deleting all resources managed by
Murano (all VMs, networks, etc.. created as
It looks like the switch to requests in python-glanceclient
(https://review.openstack.org/#/c/78269/) has broken nova when SSL is
enabled.
I think it is related to the custom object that the glanceclient uses.
If another connection gets pushed into the pool then things fail because
the object
Andrew
AFAIK, extended tests on full HA envs failed due to errors in deployment of
secondary controllers. There is new patchset on review, but I am not sure
that this code is passing extended tests. If it does, then we can consider
merge of your code if it is working with NSX and Mellanox code. I
So given the increased complexity of a spec, why not make it 2 specs per week?
Matt
-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com]
Sent: 23 July 2014 14:21
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO]
Serg,
as of 5.1, we do not have an ability to upgrade OpenStack.
Your case falls into upgrades capabilities. We plan to start working on
OpenStack upgrades in 6.0. As of 5.1, we will have an ability to patch
environments in terms of maintenance releases, i.e. to lay some patches on
your Icehouse
Django 1.7 drops support for python 2.6 [1], so until OpenStack drops
support for 2.6 which is slated for Kilo, Horizon is unfortunately capped
at 1.7.
David
[1]
https://docs.djangoproject.com/en/dev/releases/1.7/#python-compatibility
On 7/23/14, 4:56 AM, Thomas Goirand z...@debian.org
Just a note... This is huge!! Great news!! Nevertheless, if Juno comes only
with SLAAC, I'll be very, very happy!;-)
Nice job guys!
On 23 July 2014 01:06, Xu Han Peng pengxu...@gmail.com wrote:
I would like to request one Juno Spec freeze exception for Support
Stateful and Stateless
On 7/23/14, 7:51 AM, Steve Baker sba...@redhat.com wrote:
On 18/07/14 08:35, Matt Riedemann wrote:
On 7/17/2014 5:48 PM, Steve Baker wrote:
On 18/07/14 00:44, Joe Gordon wrote:
On Wed, Jul 16, 2014 at 11:28 PM, Steve Baker sba...@redhat.com
mailto:sba...@redhat.com wrote:
On
Do you have any idea as to how we can split up the work?
On Jul 23, 2014, at 6:01 AM, Evgeny Fedoruk evge...@radware.com
wrote:
Hi,
I'm working on TLS integration with loadbalancer v2 extension and db.
Basing on Brandon's patches https://review.openstack.org/#/c/105609 ,
On 22 July 2014 11:06, Luke Gorrie l...@tail-f.com wrote:
End of Part One.
Let's skip Part Two. That is just more frustration.
Let's talk about Part Three in which we all do awesome CI hacking in Juno
together :-).
Here is what I want to achieve in Juno:
NFV CI: Myself and my colleagues are
The PHP SDK Meetings for 7/23 and 7/30 are canceled. The next meeting will
be 8/6.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
For those interested in the progress of this particular task, meeting
minutes are available at the below:
http://eavesdrop.openstack.org/meetings/neutron_nova_network_parity/2014/
Thanks to all who attended!
Kyle
___
OpenStack-dev mailing list
I would also suggest to look at Graffiti
https://wiki.openstack.org/wiki/Graffiti project, I think Graffiti is
designed to solve problems related to our with images however I don't know
how well it is fit for us. They work very hard to make project
functionality available as part
I'm just do not suppor the idea that Nova needs to change its
fundamental design in order to support the *design* of other host
management platforms.
The current implementation doesn't make nova change its design, the
scheduling decisions are still done by nova.
Nova's design is not
Hi Carlos,
As I understand you are working on common module for Barbican interactions.
I will commit my code later today and I will appreciate if you and anybody else
who is interested will review this change.
There is one specific spot for the common Barbican interactions module API
Using hostnames instead of IPs is, as mentioned above, something under
consideration in that patch.
However, note that until now, we've intentionally kept it as just IP addresses
since using hostnames adds a lot of operational complexity and burden. I
realize that hostnames may be preferred in
Rob Crittenden wrote:
It looks like the switch to requests in python-glanceclient
(https://review.openstack.org/#/c/78269/) has broken nova when SSL is
enabled.
I think it is related to the custom object that the glanceclient uses.
If another connection gets pushed into the pool then things
OK, I just checked and 1400 and 1500 are already taken, unless we want to
move our meetings to #openstack-meeting-3. If we want to stick with
#openstack-meeting-alt, it will have to be 1300 UTC.
On 7/22/14, 5:28 PM, Flavio Percoco fla...@redhat.com wrote:
On 07/22/2014 06:08 PM, Kurt Griffiths
Hi all,
Please find the summaries and full logs for today's NFV sub team meeting at
these locations:
Summary (HTML):
http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-07-23-14.00.html
Full Log (HTML):
http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-07-23-14.00.log.html
I'm not against creating bugs initially with such a title to make visual
search easier.
However I think that re-titling existing bugs is not needed, as at leads to
spam.
Mike Scherbakov
#mihgen
On Jul 23, 2014 4:24 AM, Dmitry Borodaenko dborodae...@mirantis.com
wrote:
+1
To provide some more
Hi,
I see that the option to specify vif_driver in nova.conf for libvirt is
deprecated for Juno release.
What is the way to use an external VIF driver (i.e. that is out of the
tree)?
Itzik
___
OpenStack-dev mailing list
To summarize, this is a conversation about the following LaunchPad bug:
https://launchpad.net/bugs/1325512
and Gerrit review: https://review.openstack.org/#/c/97194/6
You are saying the function _service_is_active in addition to polling the
datastore service status also polls the status of the
Hi all,
I was wondering if someone could point me to a doc describing the
threading model for nova.
I know that we use greenthreads to map multiple threads of execution
onto a single native OS thread. And the python GIL results in
limitations as well.
According to the description at
On Wed, Jul 23, 2014 at 07:38:05PM +0300, Itzik Brown wrote:
Hi,
I see that the option to specify vif_driver in nova.conf for libvirt is
deprecated for Juno release.
Hmm, that is not right. There's no intention to remove the vif_driver
parameter itself. We were supposed to merely deprecate
On Wed, Jul 23, 2014 at 10:41:06AM -0600, Chris Friesen wrote:
Hi all,
I was wondering if someone could point me to a doc describing the threading
model for nova.
I know that we use greenthreads to map multiple threads of execution onto a
single native OS thread. And the python GIL
I left a comment on one of the commits, but in general here are my
thoughts:
1) I would prefer not to do things like switch to oslo.i18n outside of
Gerrit. I realize we don't have a specific existing policy for this, but
doing that significant work outside of Gerrit is not desirable IMHO. It
My code is here:
https://review.openstack.org/#/c/109035/1
-Original Message-
From: Evgeny Fedoruk
Sent: Wednesday, July 23, 2014 6:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - work division
Hi
Hmm, that is not right. There's no intention to remove the vif_driver
parameter itself. We were supposed to merely deprecate the various
legacy VIF driver implementations in Nova, not remove the ability
to use 3rd party ones.
I'm pretty sure it was deprecated specifically for that reason.
On Wed, Jul 23, 2014 at 09:53:55AM -0700, Dan Smith wrote:
Hmm, that is not right. There's no intention to remove the vif_driver
parameter itself. We were supposed to merely deprecate the various
legacy VIF driver implementations in Nova, not remove the ability
to use 3rd party ones.
Do we want any driver interface changes for this? At one level, with the
current interface, conforming drivers could just reference
listener.sni_containers, with no changes. But, do we want something in
place so that the API can return an unsupported error for non-TLS v2
drivers? Or must all v2
Hi everyone,
Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, July 24th at 22:00 UTC in the #openstack-meeting channel.
The agenda for tomorrow's meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to
Thank you Serg,
Yes, what you are discussing in this thread is actually directly related to
many of the original reasons we worked on the Graffiti concept POC and then
revised into the metadata definitions catalog we are working on for Glance.
Basically, you can define objects and
Hi all,
I am working on API endpoints for Tuskar according to
https://github.com/openstack/tripleo-specs/blob/master/specs/juno/tripleo-juno-tuskar-rest-api.rst
and I found some inconsistencies.
On following lines I will present what I think are mistakes or I do not
understand
well. Please,
I don't see an issue with allowing people to configure 3rd party impl
for the VIF driver, provided we don't claim that the VIF driver API
contract is stable, same way we don't claim virt driver API is stable.
It lets users have a solution to enable custom NIC functionality while
waiting for
On Wed, Jul 23, 2014 at 7:28 AM, Denis Makogon dmako...@mirantis.com wrote:
Hello, Stackers.
For those of you who’s interested in Trove just letting you know, that for
now Trove can work with Neutron (hooray!!)
instead of Nova-network, see [1] and [2]. It’s a huge step forward on the
road
I left a comment on one of the commits, but in general here are my thoughts:
1) I would prefer not to do things like switch to oslo.i18n outside of
Gerrit. I realize we don't have a specific existing policy for this, but
doing that significant
work outside of Gerrit is not desirable IMHO.
On Wed, Jul 23, 2014 at 10:09:37AM -0700, Dan Smith wrote:
I don't see an issue with allowing people to configure 3rd party impl
for the VIF driver, provided we don't claim that the VIF driver API
contract is stable, same way we don't claim virt driver API is stable.
It lets users have a
On 07/23/2014 10:46 PM, Lyle, David wrote:
Django 1.7 drops support for python 2.6 [1], so until OpenStack drops
support for 2.6 which is slated for Kilo, Horizon is unfortunately capped
at 1.7.
David
[1]
https://docs.djangoproject.com/en/dev/releases/1.7/#python-compatibility
Having
Hi all,
I was reading over a IMHO insightful hacker news thread last night:
https://news.ycombinator.com/item?id=8068547
Labeled/titled: 'I made a patch for Mozilla, and you can do it too'
It made me wonder what kind of mentoring support are we as a community offering
to newbies (a random
If we're going to do that, then we should be consistent. eg there is
a volume_drivers parameter that serves the same purpose as
vif_driver
There are lots of them. We've had a bit of a background task running to
remove them when possible/convenient and try to avoid adding new ones.
I'm not
Hi Folks,
I'd like to propose the following as an exception to the spec freeze, on the
basis that it addresses a potential data corruption issues in the Guest.
https://review.openstack.org/#/c/89650
We were pretty close to getting acceptance on this before, apart from a debate
over whether
On 07/23/2014 01:02 PM, Anne Gentle wrote:
On Wed, Jul 23, 2014 at 12:29 PM, Joshua Harlow harlo...@outlook.com
wrote:
Hi all,
I was reading over a IMHO insightful hacker news thread last night:
https://news.ycombinator.com/item?id=8068547
Labeled/titled: 'I made a patch for Mozilla,
Hi
The third iteration of the specs are now available for review at the links below
https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost
https://blueprints.launchpad.net/neutron/+spec/ml2-use-dpdkvhost
thanks for the feedback given so far.
Hopefully the current iteration addresses
On Wed, Jul 23, 2014 at 12:29 PM, Joshua Harlow harlo...@outlook.com
wrote:
Hi all,
I was reading over a IMHO insightful hacker news thread last night:
https://news.ycombinator.com/item?id=8068547
Labeled/titled: 'I made a patch for Mozilla, and you can do it too'
It made me wonder what
@Evgeny: Did you intend on adding another patchset in the reviews I've
been working on? If so I don't really see any changes, so if they're are
some changes you needed in there let me know.
@Doug: I think if the drivers see the TERMINATED_HTTPS protocol then
they can throw an exception. I don't
Hi kyle
Thanks for your provisional support.
I would agree that unless the nova spec is also granted an exception both specs
should be moved
To Kilo.
I have now uploaded the most recent version of the specs.
They are available to review here:
On Wed, Jul 23, 2014 at 06:08:52PM +, Day, Phil wrote:
Hi Folks,
I'd like to propose the following as an exception to the spec freeze, on the
basis that it addresses a potential data corruption issues in the Guest.
https://review.openstack.org/#/c/89650
We were pretty close to
@Doug: I think if the drivers see the TERMINATED_HTTPS protocol then
they can throw an exception. I don't think a driver interface change is
needed.
They¹d have to know to throw it, which could be problematic. But A
completely new protocol will probably result in some kind of exception, so
it¹s
On 07/23/2014 02:16 PM, Cindy Pallares wrote:
On 07/23/2014 01:02 PM, Anne Gentle wrote:
On Wed, Jul 23, 2014 at 12:29 PM, Joshua Harlow harlo...@outlook.com
wrote:
Hi all,
I was reading over a IMHO insightful hacker news thread last night:
https://news.ycombinator.com/item?id=8068547
On Jul 23, 2014, at 7:13 AM, Chris Dent chd...@redhat.com wrote:
I was having a bit of a browse through the ceilometer code and
noticed there are a fair few instances (sixty-some) of
`except Exception` scattered about.
While not as evil as a bare except, my Python elders always pointed
Hi all,
We have had a few last-minute registrations for the mid-cycle, and are now
up to 20 attendees. I am going to close registration at this point and look
forward to seeing you all on Monday (or Sunday, if you're getting pizza
with me)!
Cheers,
-Devananda
Speaking as someone who was reviewing both specs, I would personally
recommend you grant both exceptions. The code changes are very limited in
scope - particularly the Nova one - which makes the code review simple, and
they're highly unlikely to affect anyone who isn't actually using DPDK OVS
On Wed, Jul 23, 2014 at 10:52:54AM -0700, Dan Smith wrote:
If we're going to do that, then we should be consistent. eg there is
a volume_drivers parameter that serves the same purpose as
vif_driver
There are lots of them. We've had a bit of a background task running to
remove them when
On 23 July 2014 10:52, Dan Smith d...@danplanet.com wrote:
What is our story for people who are developing new network or
storage drivers for Neutron / Cinder and wish to test Nova ? Removing
vif_driver and volume_drivers config parameters would mean that they
would have to directly
FWIW, I do actually agree with not exposing plugin points to things
that are not stable APIs and if they didn't already exist, I'd not
approve adding them. I'd actually go further and say not even the
virt driver API should be a plugin point, since we arbitrarily change
it during development
Doug Wiegley do...@a10networks.com wrote on 07/16/2014 04:58:52 PM:
You do recall correctly, and there are currently no mechanisms for
notifying anything outside of the load balancer backend when the health
monitor/member state changes.
But there *is* a mechanism for some outside thing to
But there *is* a mechanism for some outside thing to query the load balancer
for the health of a pool member, right? I am thinking specifically of
http://docs.openstack.org/api/openstack-network/2.0/content/GET_showMember__v2.0_pools__pool_id__members__member_id__lbaas_ext_ops_member.html
On 2014-07-23 13:25, gordon chung wrote:
I left a comment on one of the commits, but in general here are my thoughts:
1) I would prefer not to do things like switch to oslo.i18n outside of
Gerrit. I realize we don't have a specific existing policy for this, but
doing that significant
Doug Wiegley do...@a10networks.com wrote on 07/23/2014 03:43:02 PM:
From: Doug Wiegley do...@a10networks.com
...
The state of the world today: ‘status’ in the neutron database is
configuration/provisioning status, not operational status. Neutron-
wide thing. We were discussing adding
On 07/23/2014 03:04 PM, Dan Smith wrote:
FWIW, I do actually agree with not exposing plugin points to
things that are not stable APIs and if they didn't already exist,
I'd not approve adding them. I'd actually go further and say not
even the virt driver API should be a plugin point, since we
Great question, and to my knowledge, not at present. There is an ongoing
discussion about a common usage framework for ceilometer, for all the various
*aaS things, but status I not included (yet!). I think that spec is in gerrit.
Thanks,
Doug
From: Mike Spreitzer
Hi
I'm looking for a maintainer email address for the cinder coraid
driver. http://stackalytics.com/report/driverlog?project_id=openstack%2Fcinder
just lists it as Alyseo team with no contact details.
Thanks
--
Duncan Thomas
___
OpenStack-dev
Hey LBaaS folks,
This is you friendly reminder to provide any agenda items for tomorrow's weekly
IRC meeting. The agenda currently has two items:
* Review Updates
* TLS work division
Cheers,
--Jorge
P.S. Please don't forget to update the weekly standup ==
I agree with Ben. ( I don't want to set a precedent where we make a
bunch of changes on Github and then import that code )
-- dims
On Wed, Jul 23, 2014 at 3:49 PM, Ben Nemec openst...@nemebean.com wrote:
On 2014-07-23 13:25, gordon chung wrote:
I left a comment on one of the commits, but in
On Jul 23, 2014, at 3:49 PM, Ben Nemec openst...@nemebean.com wrote:
On 2014-07-23 13:25, gordon chung wrote:
I left a comment on one of the commits, but in general here are my
thoughts:
1) I would prefer not to do things like switch to oslo.i18n outside of
Gerrit. I realize we
On 07/23/2014 03:04 PM, Dan Smith wrote:
FWIW, I do actually agree with not exposing plugin points to things
that are not stable APIs and if they didn't already exist, I'd not
approve adding them. I'd actually go further and say not even the
virt driver API should be a plugin point, since we
On 07/23/2014 03:04 PM, Dan Smith wrote:
FWIW, I do actually agree with not exposing plugin points to things
that are not stable APIs and if they didn't already exist, I'd not
approve adding them. I'd actually go further and say not even the
virt driver API should be a plugin point, since we
Hi,
I'd like some help with $SUBJECT. I've got a WIP patch up for review:
https://review.openstack.org/#/c/109118/
My goal is to have an RPC backend that I can use to test the new AMQP
1.0 oslo.messaging driver against. I suspect this new backend would
initially only be used by tests
On 07/22/2014 11:00 PM, Nathan Kinder wrote:
On 07/22/2014 06:55 PM, Steven Hardy wrote:
On Tue, Jul 22, 2014 at 05:20:44PM -0700, Nathan Kinder wrote:
Hi,
I've had a few discussions recently related to Keystone trusts with
regards to imposing restrictions on trusts at a deployment
1 - 100 of 138 matches
Mail list logo
