The NS FW will be on a centralized node for sure. For the DVR + FWaaS
solution is really for EW traffic. If you are interested on the topic,
please propose your preferred meeting time and join the meeting so that
we can discuss about it.
Yi
On 7/2/14, 7:05 PM, joehuang wrote:
Hello,
It's
On Thu, Jul 3, 2014 at 5:00 AM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-07-02 22:19:29 +0400 (+0400), Yuriy Taraday wrote:
[...]
It looks like mirrors will have to bear having a number of dead branches
in
them - one for each release.
A release manager will delete proposed/juno
Can anyone kindly help me here? When the volume type is created and I try
starting volume service via coverage, I get coverage_manager not found
error.
On Wed, Jul 2, 2014 at 6:57 AM, iKhan ik.ibadk...@gmail.com wrote:
I have manually deployed cinder and it is up and running. Now I wanted to
Although the SNAT DVR has some trade off, I still think it is
necessary. Here is pros and cons for consideration:
pros:
save W-E bandwidth
high availability (distributed, no single point failure)
cons:
waste public ips (one ip per compute node vs one ip per l3-agent, if
double-SNAT
Hi,
As announced:
http://lists.openstack.org/pipermail/openstack-dev/2014-June/038475.html
The nova-specs dates:
* all juno nova-specs ready for review by the end of today, 3rd July
(in local time for you)
* all blueprints we can take for juno (yes juno-2 and juno-3) approved
by 10th July
We
Thanks Scott, that is a nice topic
In theory, I would prefer to have both owner_tenant and owner_user to be
persisted with an image, and to have a policy rule which allows to specify
if the users of a tenant have access to images owned by or shared with
other users of their tenant. But this will
Looks like many are in Paris midcycle meet-up. Do we have the weekly IRC
meeting today?
Hi Lianhao,
We'll do a very short meeeting just to review juno-2 status, and remind
folks about the upcoming spec deadlines for Juno. Shouldn't take more
than a few minutes.
Cheers,
Eoghan
FWIW, I've just registered
https://blueprints.launchpad.net/tripleo/+spec/re-assert-system-state and I'm
about to start work on the spec.
Matt
-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com]
Sent: 27 June 2014 17:01
To: openstack-dev
Subject: Re: [openstack-dev]
-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info]
Sent: 01 July 2014 14:42
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [third-party-ci][neutron] What is Success
exactly?
On 06/30/2014 09:13 PM, Jay Pipes wrote:
On 06/30/2014 07:08 PM, Anita
Hi,
Just a reminder that the weekly Nova API meeting is being held tomorrow
Friday UTC .
We encourage cloud operators and those who use the REST API such as
SDK developers and others who and are interested in the future of the
API to participate.
In other timezones the meeting is at:
EST
I would just add that if I'm not mistaken the DVR work would also include
the features currently offered by nova network's 'multi-host' capability.
While DVR clearly does a lot more than multi host, keeping SNAT centralized
only might not fully satisfy this requirement.
Indeed nova-network offers
Apologies for quoting again the top post of the thread.
Comments inline (mostly thinking aloud)
Salvatore
On 30 June 2014 22:22, Jay Pipes jaypi...@gmail.com wrote:
Hi Stackers,
Some recent ML threads [1] and a hot IRC meeting today [2] brought up some
legitimate questions around how a
I have created a separate spec for the RPC part.
https://review.openstack.org/104522
On 07/02/2014 05:52 PM, Kyle Mestery wrote:
On Wed, Jul 2, 2014 at 3:43 AM, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 02/07/14 10:12, Miguel Angel Ajo
And the spec is now up at https://review.openstack.org/104524 for everyone to
pull apart... ;)
Matt
-Original Message-
From: Macdonald-Wallace, Matthew
Sent: 03 July 2014 11:18
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [TripleO]
Hi,
As you surely now, in Juno oslo.db will graduate [1]
I am currently working on the port. It's been already cleared that making
alembic migrations idempotent and healing the DB schema is a requirement
for this task.
These two activities are tracked by the blueprints [2] and [3].
I think we've
Hi,
Due to maintenance reasons, our CI results server has been moved to a new
machine.
As we didn't use a dns name before, previous links posted on the
review.openstack.org will appear as broken but they're still available
changing the previous hardcoded ip: 119.15.112.63 by the new dns name:
On 2014-07-03 11:20:43 +0400 (+0400), Yuriy Taraday wrote:
I mean other mirrors like we have in our local net. Given not so
good connection to upstream repos (the reason we have this mirror
in the first place) I can't think of reliable way to clean them
up. Where can I find scripts that
On 07/02/2014 09:11 PM, Doug Hellmann wrote:
The Oslo team is pleased to announce the first release of oslo.i18n,
the library that replaces the gettextutils module from oslo-incubator.
The new library has been uploaded to PyPI, and there is a changeset in
the queue update the global
On 3 July 2014 02:44, Michael Still mi...@stillhq.com wrote:
The main purpose is to let change reviewers know that a change might
be problematic for a piece of code not well tested by the gate
Just a thought:
A sampling approach could be a reasonable way to stay responsive under
heavy load
So, our releases will have following versions of releases on UI:
5.0) 2014.1
5.0.1) 2014.1.1-5.0.1
5.1) 2014.1.1-5.1
And if someone install 5.0, upgrade it to 5.0.1 and then upgrade to 5.1, he
will have three releases for each OS. I think we should allow user to
delete unneeded releases. It also
On 07/03/2014 06:22 AM, Sullivan, Jon Paul wrote:
-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info]
Sent: 01 July 2014 14:42
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [third-party-ci][neutron] What is Success
exactly?
On 06/30/2014 09:13 PM,
On 07/03/2014 07:12 AM, Salvatore Orlando wrote:
Apologies for quoting again the top post of the thread.
Comments inline (mostly thinking aloud)
Salvatore
On 30 June 2014 22:22, Jay Pipes jaypi...@gmail.com wrote:
Hi Stackers,
Some recent ML threads [1] and a hot IRC meeting today
-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info]
Sent: 03 July 2014 13:53
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [third-party-ci][neutron] What is Success
exactly?
On 07/03/2014 06:22 AM, Sullivan, Jon Paul wrote:
-Original
+1
On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery mest...@noironetworks.com
wrote:
We're coming down to the wire here with regards to Neutron BPs in
Juno, and I wanted to bring up the topic of the flavor framework BP.
This is a critical BP for things like LBaaS, FWaaS, etc. We need this
work
On Thu, Jul 3, 2014 at 2:59 AM, Anant Patil anant.tec...@gmail.com wrote:
If we did move from screen to tmux.
We aren't moving away... I have emphasized this enough. One should be
able just choose tmux explicitly otherwise things will run in screen
by default, as usual.
And I am saying due
On 07/03/2014 09:52 AM, Sullivan, Jon Paul wrote:
-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info]
Sent: 03 July 2014 13:53
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [third-party-ci][neutron] What is Success
exactly?
On 07/03/2014 06:22 AM,
Hi,
I think we should allow user to delete unneeded releases.
In this case user won't be able to add new nodes to the existing
environments of the same version. So we should check and warn user about
it, or simply not allow to delete releases if there are live envs with the
same version.
On
Salvatore,
There is FIP distribution at the agent level, in the sense the N/S of FIP for a
VM will be hosted on the same compute node. We centralized SNAT from feedback
by others. The current design and code only supports centralized SNAT for DVR
routers. The design could be modified to
I'm on Paris mid-cycle sprint, so, Alex Ignatov and Dmitry
Mescheryakov will chair the meeting today.
On Wed, Jul 2, 2014 at 4:35 PM, Sergey Lukjanov slukja...@mirantis.com wrote:
Hi folks,
We'll be having the Sahara team meeting as usual in
#openstack-meeting-alt channel.
Agenda:
I¹m seeing similar. Instances launch, they show as having Ips in
`neutron list` but I cannot access them via IP.
Other thing I¹ve notices is that doing a `neutron agent-list` gives me an
empty list, I would assume it should at least show the dhcp agent ?
On 7/1/14, 12:00 PM, Kyle Mestery
Hey
This is an attempt to summarize a really useful discussion that Victor,
Flavio and I have been having today. At the bottom are some background
links - basically what I have open in my browser right now thinking
through all of this.
We're attempting to take baby-steps towards moving
With the new API and object model refactor there have been some issues
arising dealing with the status of entities. The main issue is that
Listener, Pool, Member, and Health Monitor can exist independent of a
Load Balancer. The Load Balancer is the entity that will contain the
information about
Hi,
Mark and me has spent some time today discussing existing proposals and I
think we got to a consensus.
Initially I had two concerns about Mark's proposal which are
- extension list attribute on the flavor
- driver entry point on the service profile
The first idea (ext list) need to be
If the objects remain in 'PENDING_CREATE' until provisioned it would seem
that the process got stuck in that status and may be in a bad state from
user perspective. I like the idea of QUEUED or similar to reference that
the object has been accepted but not provisioned.
Phil
On 7/3/14 10:28 AM,
Hi, All!
As far as I know, there are some requirements, which virt driver must meet to
use Openstack 'label'. For example, it's not allowed to mount cinder volumes
inside host OS.
Are there any documents, describing all such things? How can I determine, if
my virtualization driver for nova
On 07/03/2014 10:31 AM, Sullivan, Jon Paul wrote:
-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info]
Sent: 03 July 2014 15:06
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [third-party-ci][neutron] What is Success
exactly?
I guess you missed
On 07/03/2014 10:48 AM, Derek Higgins wrote:
If your like me, launchpads wrapping of paragraphs in comment boxes gets
under your skin, making it very difficult to follow tracebacks, logs,
etc see
https://bugs.launchpad.net/launchpad/+bug/545125
I finally got motivated to try and do
On 07/03/2014 03:49 AM, Luke Gorrie wrote:
On 3 July 2014 02:44, Michael Still mi...@stillhq.com
mailto:mi...@stillhq.com wrote:
I have seen both. Normally there's a failure, reviewers notice, and
then the developer spins trying out fixes by uploading new patch sets.
Interesting. Yes,
On 1 July 2014 19:12, Luke Gorrie l...@tail-f.com wrote:
It does not yet run devstack/tempest and I hope to reuse that part from
somebody else's efforts.
shellci is happily voting on the sandbox with the Snabb NFV CI account so
far: http://egg.snabb.co:81/shellci/shellci.log
Time to make it
On 07/03/2014 08:42 AM, Luke Gorrie wrote:
On 3 July 2014 02:44, Michael Still mi...@stillhq.com
mailto:mi...@stillhq.com wrote:
The main purpose is to let change reviewers know that a change might
be problematic for a piece of code not well tested by the gate
Just a thought:
A
+27, -2401
Wow, that's pretty painless. Were there earlier patches to Neutron to
prepare for the transition or was it really that easy?
On 07/03/2014 07:34 AM, Salvatore Orlando wrote:
No I was missing everything and kept wasting time because of alembic.
This will teach me to keep my mouth
On Thu, Jul 3, 2014 at 11:27 AM, Mark McLoughlin mar...@redhat.com wrote:
Hey
This is an attempt to summarize a really useful discussion that Victor,
Flavio and I have been having today. At the bottom are some background
links - basically what I have open in my browser right now thinking
Ben,
As I know the API of oslo.db and oslo-incubator/db are almost the same.
So why it should be complicated?
Best regards,
Boris Pavlovic
On Thu, Jul 3, 2014 at 9:10 PM, Ben Nemec openst...@nemebean.com wrote:
+27, -2401
Wow, that's pretty painless. Were there earlier patches to
Hi All and Ihar,
As part of blueprint oslo-messaging the neutron/openstack/common/rpc tree
is removed. I was using impl_kombu module to process notification from
keystone with this following code sample:
...
from neutron.openstack.common.rpc import impl_kombu
try:
conf =
You'll find the documentation for using oslo.messaging at
http://docs.openstack.org/developer/oslo.messaging/
Based on the fact that you mention listening for notifications, you
probably want to look at the notification listener documentation in
particular
On Mon, Jun 30, 2014 at 9:00 AM, Sean Dague s...@dague.net wrote:
Every time I crack open a nova logs in detail, at least 2 new olso
incubator log issues have been introduced.
The current ones is clearly someone is over exploding arrays, as we're
getting things like:
2014-06-29 13:36:41.403
On 30/06/14 13:02 -0400, Jordan OMara wrote:
On 25/06/14 14:32 -0400, Jordan OMara wrote:
On 25/06/14 18:20 +, Carlino, Chuck (OpenStack TripleO, Neutron) wrote:
Is $179/day the expected rate?
Thanks,
Chuck
Yes, that's the best rate available from both of the downtown
(walkable) hotels.
Hi,
==
tl; dr: A decision has been made to split out the scheduler to a
separate project not on a feature parity basis with nova-scheduler, your
comments are welcome.
==
As it has been agreed now a cycle ago, the nova-scheduler will be ported
to a separate OpenStack project, called Gantt [1].
Hi,
You can use /oslo.messaging._drivers.impl_rabbit/ instead of impl_kombu
It was renamed and slightly change but I think it will work as you expect.
Regards,
Alexei Kornienko
On 07/03/2014 08:47 PM, Nader Lahouti wrote:
Hi All and Ihar,
As part of blueprint oslo-messaging the
On 07/03/2014 01:27 PM, Kevin Benton wrote:
This allows the viewer to see categories of reviews based upon their
divergence from OpenStack's Jenkins results. I think evaluating
divergence from Jenkins might be a metric worth consideration.
I think the only thing this really reflects though
The reason I thought it changed was that this is the first cycle where I
have encountered scenarios where my unit tests for the patch run fine
locally, but then they fail when they are checked by Jenkins (caused by a
change after the parent of my patch). I suppose I was just lucky before and
never
In short, you need to test every single proposed patch to the system fully
and consistently, otherwise there's simply no point in running any tests at
all, as you will spend an inordinate amount of time tracking down what
broke what.
I agree that every patch should be tested. However, since third
On 07/03/2014 02:10 PM, Kevin Benton wrote:
The reason I thought it changed was that this is the first cycle where I
have encountered scenarios where my unit tests for the patch run fine
locally, but then they fail when they are checked by Jenkins (caused by
a change after the parent of my
Maybe we can require period checks against the head of the master
branch (which should always pass) and build statistics based on the results
of that. Otherwise it seems like we have to take a CI system's word for it
that a particular patch indeed broke that system.
--
Kevin Benton
On Thu, Jul
Hey German,
We have similar statuses. I have been wanting to add a 'QUEUED' status
however. The reason is that we currently use 'BUILD' which indicates
active provisioning when in reality it is actually queued first and then
provisioned. Thus, there are potential issues when trying to determine
+1 to QUEUED status.
For entities that have the concept of being attached/detached why not have
a 'DETACHED' status to indicate that the entity is not provisioned at all
(i.e. The config is just stored in the DB). When it is attached during
provisioning then we can set it to 'ACTIVE' or any of
On Thu, Jul 3, 2014 at 1:58 PM, Alexei Kornienko
alexei.kornie...@gmail.com wrote:
Hi,
You can use oslo.messaging._drivers.impl_rabbit instead of impl_kombu
It was renamed and slightly change but I think it will work as you expect.
You should not depend on using any API defined in that
Again, thanks everyone who have joined Sahara meeting. Below are the
logs from the meeting.
Minutes:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.html
Logs:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.log.html
Thanks,
Dmitry
At yesterday's Trove team meeting [1] there was significant discussion around
the Capabilities [2] feature. While the community previously approved a BP and
some of the initial implementation, it is apparent now that there is no
agreement in the community around the requirements, use cases or
On 07/03/2014 01:53 PM, Sylvain Bauza wrote:
Hi,
==
tl; dr: A decision has been made to split out the scheduler to a
separate project not on a feature parity basis with nova-scheduler, your
comments are welcome.
==
...
During the last Gantt meeting held Tuesday, we discussed about the
Matthew Treinish mtrein...@kortar.org writes:
Hi Everyone,
Just a quick update, we have to close registration for the Infra/QA mid-cycle
meet-up. Based on the number of people who have signed up on the wiki page [1]
we are basically at the maximum capacity for the rooms we reserved. So if
On Thu, Jul 3, 2014 at 7:05 AM, Aleksandr Didenko adide...@mirantis.com wrote:
I think we should allow user to delete unneeded releases.
In this case user won't be able to add new nodes to the existing
environments of the same version. So we should check and warn user about it,
or simply not
Hey Doug,
Thank you so much for putting this together. I have some
questions/clarifications(inline) which would be useful to be addressed in the
spec.
From: Doug Shelley d...@tesora.commailto:d...@tesora.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
I also don't think it is fair for certain drivers to hold other drivers
hostage
For some time there was a policy (openstack-wide) that public API should
have a free open source implementation.
In this sense open source driver may hold other drivers as hostages.
Eugene.
On Thu, Jul 3, 2014 at
Are these zuul refs publicly accessible so that the third party CI systems
could reference then to guarantee they are testing the same thing?
On Thu, Jul 3, 2014 at 11:31 AM, Jay Pipes jaypi...@gmail.com wrote:
On 07/03/2014 02:10 PM, Kevin Benton wrote:
The reason I thought it changed was
Yes, I can propose a spec for that. It probably won't be until Monday.
Is that okay?
On Thu, Jul 3, 2014 at 11:42 AM, Anita Kuno ante...@anteaya.info wrote:
On 07/03/2014 02:33 PM, Kevin Benton wrote:
Maybe we can require period checks against the head of the master
branch (which should
The most challenge part for me for the past few days is understanding the
how SDN can reduce the burden on Neutron.
A single SDN plugin consider OpenDayLight controller plugin deployed on
neutron. I have physical and virtual switches which support open flow. I
know OpenFlow will install the flow
While moving success response code checking in tempest to the client, I
noticed that exactly one of the calls to list users for a tenant checked
for 200 or 203. Looking at
http://docs.openstack.org/api/openstack-identity-service/2.0/content/,
it seems that most of the list apis can return 203.
Hi,
This is very similar to an issue I encountered with Glance. For some
unknown reason, we were adding a Location header for 200 responses.
When served behind apache+mod_fcgid, the module saw the Location
header and has a hard coded conversion to 302 Redirect. This caused
glanceclient to
Hi Folks - I have taken a script from the infra folks and jogo, made some
tweaks and have put it into a web page. Please see it here
http://54.201.139.117/demo.html
This is all of the new, confirmed, triaged, and in progress bugs that we have
in nova as of a couple of hours ago. I have
Awesome, thanks for working on this Eugene and Mark! I'll still leave
an item on Monday's meeting agenda to discuss this, hopefully it can
be brief.
Thanks,
Kyle
On Thu, Jul 3, 2014 at 10:32 AM, Eugene Nikanorov
enikano...@mirantis.com wrote:
Hi,
Mark and me has spent some time today
On Thu, Jul 3, 2014 at 10:14 AM, Paul Czarkowski
paul.czarkow...@rackspace.com wrote:
I¹m seeing similar. Instances launch, they show as having Ips in
`neutron list` but I cannot access them via IP.
Other thing I¹ve notices is that doing a `neutron agent-list` gives me an
empty list, I
On Thu, Jul 3, 2014 at 3:48 PM, David Kranz dkr...@redhat.com wrote:
While moving success response code checking in tempest to the client, I
noticed that exactly one of the calls to list users for a tenant checked
for 200 or 203. Looking at http://docs.openstack.org/api/
I was implying that it applies to all drivers.
Cheers,
--Jorge
From: Eugene Nikanorov enikano...@mirantis.commailto:enikano...@mirantis.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/07/14 19:47, Nader Lahouti wrote:
Hi All and Ihar,
As part of blueprint oslo-messaging the
neutron/openstack/common/rpc tree is removed. I was using
impl_kombu module to process notification from keystone with this
following code
Is this still the right repo for this:
https://github.com/openstack/neutron-specs
The latest commit on the master branch shows June 25th timestamp, but
we have had a lots of patches merging after that. Where are those
going?
Thanks,
~Sumit.
___
Iccha,
Thanks for the feedback. I guess I should have been more specific - my intent
here was to layout use cases and requirements and not talk about specific
implementations. I believe that if we can get agreement on the requirements, it
will be easier to review/discuss design/implementation
Thanks a lot Doug and Alexei for your prompt response.
I used what Doug suggested and worked.
Thanks again for the help.
Nader.
On Thu, Jul 3, 2014 at 12:04 PM, Doug Hellmann doug.hellm...@dreamhost.com
wrote:
On Thu, Jul 3, 2014 at 1:58 PM, Alexei Kornienko
alexei.kornie...@gmail.com wrote:
Thanks Nader for the extra effort and I am glad you made progress here.
Milton
From: Nader Lahouti [mailto:nader.laho...@gmail.com]
Sent: Thursday, July 03, 2014 3:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][oslo.messaging]
Hi Jorge,
+1 for QUEUED and DETACHED
I would suggest to make the time how long we keep entities in DELETED state
configurable. We use something like 30 days, too, but we have made it
configurable to adapt to changes...
German
-Original Message-
From: Jorge Miramontes
I am actually a bit bummed that Extensions are postponed. In LBaaS we are
working hard on L7 and TLS extensions which we (the operators) like to switch
on and off with different flavors...
German
-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com]
Sent:
git.openstack.org has an up-to-date log:
http://git.openstack.org/cgit/openstack/neutron-specs/log/
Unfortunately I don't know what the policy is for syncing repos with github.
Salvatore
On 4 July 2014 00:34, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:
Is this still the right repo for
On Thu, Jul 3, 2014 at 4:18 PM, Brant Knudson b...@acm.org wrote:
On Thu, Jul 3, 2014 at 3:48 PM, David Kranz dkr...@redhat.com wrote:
While moving success response code checking in tempest to the client, I
noticed that exactly one of the calls to list users for a tenant checked
for 200 or
On 07/03/2014 04:48 PM, David Kranz wrote:
While moving success response code checking in tempest to the client,
I noticed that exactly one of the calls to list users for a tenant
checked for 200 or 203. Looking at
http://docs.openstack.org/api/openstack-identity-service/2.0/content/,
it
I've recently been looking into using dracut to build the
deploy-ramdisks that we use for TripleO. There are a few reasons for
this: 1) dracut is a fairly standard way to generate a ramdisk, so users
are more likely to know how to debug problems with it. 2) If we build
with dracut, we get a lot
On 07/04/2014 01:30 AM, Salvatore Orlando wrote:
git.openstack.org http://git.openstack.org has an up-to-date
log: http://git.openstack.org/cgit/openstack/neutron-specs/log/
Unfortunately I don't know what the policy is for syncing repos with github.
they should sync automatically, something
Steven Hardy sha...@redhat.com wrote on 07/02/2014 06:16:21 AM:
On Wed, Jul 02, 2014 at 02:41:19AM +, Adrian Otto wrote:
Zane,
If you happen to have a link to this blueprint, could you replywith
it? ...
I believe Zane was referring to:
German,
First of all extension list looks lbaas-centric right now.
Secondly, TLS and L7 are such APIs which objects should not require
loadbalancer or flavor to be created (like pool or healthmonitor that are
pure db objects).
Only when you associate those objects with loadbalancer (or its child
To add to the growing pains of keystone-specs,
one thing I've noticed is, there is inconsistency in the 'REST API Impact'
section.
To be clear here, I don't mean we shouldn't
include what new APIs will be created, I think that is essential. But rather,
remove the need to specifically spell out
89 matches
Mail list logo
