g…
>
>
>
> Regards,
>
> Artur
>
> *From:*Armando M. [mailto:arma...@gmail.com]
> *Sent:* Friday, November 13, 2015 9:37 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova][neutron][upgrade] Grenade
>
this.
Servers talking to other servers through clients should use the system
CA for sure.
That will have a knock on effect about using it for python clients
directly, but that seems like the right option.
What's the expected way that
On 11/13/2015 01:16 PM, Sean M. Collins wrote:
> On Fri, Nov 13, 2015 at 07:42:12AM EST, Sean Dague wrote:
>> Ok, I top responded with the details of the job, honestly I think it's
>> just a project-config change to get up and running, and then hacking at
>> the bugs
events, so this is a thing we should definitely decide over ML instead.
Please express your feelings here and lets make it happen. :)
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not fo
b set is making
>> neutron own
>> > its grenade future, by migrating to grenade plugin maintained in
>> neutron
>> > tree.
>>
>> I'd like to see what Sean Dague thinks of this - my worry is that if we
>> start pulling things into Neutron we lose valuabl
eady has #1 and #2 because of existing
jobs, so getting a multinode grenade job should just be a matter of a
project-config stanza. No additional code needs to be written. I'm sure
there might be some bugs (there always are), but getting rolling
shouldn't be
On 11/10/2015 02:24 PM, David Pursehouse wrote:
> On Tue, Nov 10, 2015 at 4:53 AM Sean Dague <mailto:s...@dague.net>> wrote:
>
> <...>
>
> Is there any update on label:Code-Review<=-1,group:nova-core ? The group
> search support is documented, b
On 11/10/2015 01:37 PM, Armando M. wrote:
>
>
> On 10 November 2015 at 09:49, Sean Dague <mailto:s...@dague.net>> wrote:
>
> The neutron tempest jobs are now at a 35% failure rate:
> http://tinyurl.com/ne3ex4v (note, 35% is basically the worst possible
&g
ASAP. There is less than
a month now before these will no longer work.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
at ERROR is thrown a lot in
neutron, and 60% of the times the tempest run is successful.
This issue is currently stuck and needs neutron folks to engage to get
us somewhere. Reverting the tempest patch which does the early
verification might make this class of fail go away, but I
> Learning how to debug the gate was identified as a theme at the
>>>>>>>>>> "Establish Key Themes for the Mitaka Cycle" cross-project session:
>>>>>>>>>> https://etherpad.openstack.org/p/mitaka-crossproject-themes
>>>>>>
mpute workers coming / going. That's been used to build a
lot of HA orchestration bits outside of Nova by a bunch of folks in the
NFV space.
So it's also not just theory that Zookeeper is keeping up here, many
OpenStack deploys already are using it quite heavily.
-Sean
--
Sean Dagu
ervice clients.
The service clients are *always* going to have to exist in some form.
Either as libraries that services produce, or by services deciding they
don't want to consume the libraries of other clients and just put a
targeted bit of rest code in their own tree to talk to other serv
t's not really worth building a new library for
especially because we don't actually want to encourage people to do this
any more.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (
te with specialists to improve the UX.
This would be really incredible. The challenges in approaching
improvements with the Gerrit UI do to GWT are really massive. I can't
wait to see this work play out.
-Sean
--
Sean Dague
http://dague.net
_
On 11/09/2015 05:30 AM, Hugh Blemings wrote:
> Hiya,
>
> On 7/11/2015 06:42, Sean Dague wrote:
>> On 11/06/2015 01:15 AM, Tony Breeds wrote:
>>> Hello all,
>>>
>>> I'll start by acknowledging that this is a big and complex issue and I
>>>
ke openjdk. Because it doesn't help us make decisions long
term if we're basing that on long standing biases that may or may not
still be supported by data.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Dev
nstack.org/242891
> [2] https://review.openstack.org/242894
> [3] https://review.openstack.org/242895
> [4] https://review.openstack.org/242895
> [5] https://review.openstack.org/242536
--
Sean Dague
http://dague.net
__
s been make upgrades unexciting, and then folks
can move forward easily.
I would really like to unpack what those various reasons are that people
are trapped. Because figuring out why they feel that way is important
data in what needs to be done better on upgrade support and testing.
-
ing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
+1
--
Sean Dague
http://dague.net
_
t for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
+1
--
Sean Dague
http://dague.net
__
OpenStack Development
On 11/06/2015 08:44 AM, Alex Xu wrote:
>
>
> 2015-11-06 20:59 GMT+08:00 Sean Dague <mailto:s...@dague.net>>:
>
> On 11/06/2015 07:28 AM, John Garbutt wrote:
> > On 6 November 2015 at 12:09, Sean Dague <mailto:s...@dague.net>> wrote:
&g
On 11/06/2015 07:46 AM, Daniel P. Berrange wrote:
> On Fri, Nov 06, 2015 at 07:09:59AM -0500, Sean Dague wrote:
>> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
>>>
>>> I think that exposing hypervisor_type is very much the *wrong* approach
>>> to this
On 11/06/2015 07:28 AM, John Garbutt wrote:
> On 6 November 2015 at 12:09, Sean Dague wrote:
>> On 11/06/2015 04:49 AM, Daniel P. Berrange wrote:
>>> On Fri, Nov 06, 2015 at 05:08:59PM +1100, Tony Breeds wrote:
>>>> Hello all,
>>>> I came across [1]
ack/api-wg/guidelines/pagination_filter_sort.html
The pagination part is just a TODO in there.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsub
may be features beyond that we'd like
to classify as capabilities, but actions would be a very concrete and
attainable starting point. With microversions we don't have to solve
this all at once, start with a concrete thing and move forward.
Sending an action that was "False" for
up partitioning in active-active HA setups
> and shared locks. Again the standard deploy for that has been to use
> redis because of availability. It's fairly understood that zookeeper
> would be more correct but there are packaging concerns.
What are the packaging co
you get a critical mass of operators
running similar configs, and they can build and share knowledge. For all
of the issues with Rabbit, it has demonstrably been good to have
collaboration in the field between operators that have shared patterns
and fed back the issues. So we should really say Zooke
later
once we see some kinds of jobs running on the zookeeper base for what
the semantics would make sense to plug more stuff in.
Kind of like the MQ path in devstack right now. One default, and a plug
point for people trying other stuff.
-Sean
--
Sean Dague
http://dague.net
_
On 11/04/2015 03:27 PM, Clark Boylan wrote:
> On Wed, Nov 4, 2015, at 09:14 AM, Sean Dague wrote:
>> On 11/04/2015 12:10 PM, Jeremy Stanley wrote:
>>> On 2015-11-04 08:43:27 -0600 (-0600), Matthew Thode wrote:
>>>> On 11/04/2015 06:47 AM, Sean Dague wrote:
>>>
Ironic; one
>>> that deploys intermediate releases. I think if we give them at least one
>>> release and three months, they're okay, so the general standard
>>> deprecation rule covers them.)
>>>
>>> // jim
>>
>> So, summarizing that:
ems like a reasonable trade off for not much complexity.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?
On 11/04/2015 12:10 PM, Jeremy Stanley wrote:
> On 2015-11-04 08:43:27 -0600 (-0600), Matthew Thode wrote:
>> On 11/04/2015 06:47 AM, Sean Dague wrote:
> [...]
>>> Is there a nodepool cache strategy where we could pre build these? A 25%
>>> performance win comes ou
On 11/04/2015 07:47 AM, Sean Dague wrote:
> I was spot checking the grenade multinode job to make sure it looks like
> it was doing the correct thing. In doing so I found that ~15minutes of
> it's hour long build time is compiling lxml and numpy 3 times each.
>
> Due to our e
On 11/04/2015 10:50 AM, Brant Knudson wrote:
>
>
> On Wed, Nov 4, 2015 at 6:47 AM, Sean Dague <mailto:s...@dague.net>> wrote:
>
> I was spot checking the grenade multinode job to make sure it looks like
> it was doing the correct thing. In doing so I found th
On 11/04/2015 10:13 AM, John Garbutt wrote:
> On 4 November 2015 at 14:49, Jay Pipes wrote:
>> On 11/04/2015 09:32 AM, Sean Dague wrote:
>>>
>>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
>>>>
>>>> On 11/03/2015 05:20 PM, Boris Pavlovic wrote
On 11/04/2015 09:49 AM, Jay Pipes wrote:
> On 11/04/2015 09:32 AM, Sean Dague wrote:
>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
>>> On 11/03/2015 05:20 PM, Boris Pavlovic wrote:
>>>> Hi stackers,
>>>>
>>>> Usually such projects like Heat,
pi-ref-objectstorage-v1.html#showAccountMeta
>
>
> containers:
>
> http://developer.openstack.org/api-ref-objectstorage-v1.html#showContainerMeta
>
>
> and objects:
>
> http://developer.openstack.org/api-ref-objectstorage-v1.html#showObjectMeta
&
right version of each of those in old & new & subnode (old).
Is there a nodepool cache strategy where we could pre build these? A 25%
performance win comes out the other side if there is a strategy here.
-Sean
--
Sean Dague
htt
g #openstack-dev, instead of a new meeting
room? #openstack-dev is mostly a ghost town at this point, and deciding
that instead it would be the dedicated cross project space, including
meetings support, might be interesting.
-Sean
--
Sean Dague
http://dague.net
___
fine to include, however it's a
pretty edge case. Super small disks (I didn't even realize they made SSD
that small, I thought 120 was about the floor), and running devstack for
long times without rebuild.
-Sean
--
Sean Dague
http://dague.net
interested, I can try to move that forward eagerly.
I guess I wonder what the expected interaction with things like
Searchlight is? Searchlight was largely created for providing this kind
of fast access to subsets of resources based on arbitrary attribute search.
-Sean
--
Sean Dague
ht
t;>> - gating functional tests that use dsvm
>>> Test drivers in-tree will need:
>>> - clear identification that the driver is a test driver - in the
>>> module name at minimum
>>>
>>> All hail our new abstraction overlords.
>>>
>>
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Davanum Srin
s
Agreed. Including .po files is a pretty standard pattern for open source
projects that want i18n support. Packagers are free to slice these up so
default installs don't support all locales, but doing that in multiple
git repos would just be a bunch of extra complexity for
he latest set of projects in
> a given community, publish them to permalinks, and share those
> permalinks with code reviewers.
One of the challenges you run into is url length limits in browsers,
given that we're encoding the whole thing in the
gate-rally-dsvm-designate-designate
gate-designate-dsvm-bind9
gate-cue-integration-dsvm-rabbitmq
gate-congress-dsvm-api
gate-solum-devstack-dsvm-centos7
You can search for jobs with the following logstash query:
message:"extras.d support is being removed in Mitaka-1"
-Sean
--
gstash.
>
> Hey!
>
> Thanks for notification!
> Murano team is on track to drop support usage of extras.d. [0]
>
> [0] https://review.openstack.org/#/c/235868/
Thanks for keeping up on this. +2 on that review from me.
-Sean
--
Sean Dague
http://dague.net
r projects
So a dozen library releases could easily be triggered by fixing one cap
or pin in one low level library, that were no functional changes, they
were just requirements changes. The only reason M could use the old
version of A is because pip wouldn't let you install the 2 together. Not
f
#x27;s 3 weeks until the next TC meeting because so
many folks are going to .jp early and then there is summit. So if you
don't get feedback right away, realize it's the schedule, and not
anything about your proposal.
e screen as
well. The css selector is weird, but seems to work fine:
/* css attribute selector to make -1s show up red in new screen */
[title="This patch needs further work before it can be merged"] {
color: red;
}
-Sean
--
Sean Dague
http://dague.net
__
ecked it for both Safari and Chrome - fails the
> same way.
>
> Ihar
>
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.ope
, I flipped to CS2 around Paris time for the related
changes stack view. Honestly, after a month, the old view turns out to
be hard to use because related changes means you never strand patches by
not going down the whole stack
-Sean
--
Sean Dague
http://dague.net
_
ack.org. If you are very opposed to CS2 then
> you may like Gertty (https://pypi.python.org/pypi/gertty) instead. If
> neither option works for you then maybe you can help us create a new
> alternative :)
>
> We are soliciting feedback so please let us know what you think.
>
an error. That's massively surprising. openstack
help pool (no such command!).
So while I realize this has been the pattern in the past, it's never
really worked well for me at least.
-Sean
--
Sean Dague
http://dague.net
es. We had
some kilo content bogging down the gate today because of this kind of
failure. Better to time this as close as possible with the tag setting.
-Sean
-
Sean Dague
http://dague.net
__
OpenStack Development Ma
backport situation, you
need to carefully do your backports so they don't share a UUID with master.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsu
th the tests in novaclient. Anyone have any insights as
> to how to address the problem?
Do you have a link to failed jobs? Or a bug to start accumulating that in?
-Sean
--
Sean Dague
http://dague.net
__
OpenSt
On 10/12/2015 12:03 PM, Jesse Pretorius wrote:
> On 15 June 2015 at 12:30, Sean Dague <mailto:s...@dague.net>> wrote:
>
>
> As a heads up for where we stand. The switch was flipped, but a lot of
> neutron jobs (rally & tempest) went into a pretty high fai
he UX, and let backends
match once we get better interaction. That also lets you see whether or
not you are getting any uptake on the new approach before you go and
spend a ton of time retooling the backend.
-Sean
--
Sean Dague
http://dague.net
On 10/12/2015 07:12 AM, Dmitry Tantsur wrote:
> On 10/09/2015 05:41 PM, Dmitry Tantsur wrote:
>> On 10/09/2015 12:58 PM, Dmitry Tantsur wrote:
>>> On 10/09/2015 12:35 PM, Sean Dague wrote:
>>>> From now until the removal of devstack extras.d support I'm going
dded in the Token, which causes toke
bloat, and has led to other features to try to shrink the catalog by
filtering it by what a user is allowed. Which in turn ended up being
used by Horizon to populate the feature matrix users see.
So we're pulling on a thread, and we have to do that really ca
few cycles. annegentle, stevemar, and I have been pushing on
that ball so far, however I'd like to know who else is willing to commit
a chunk of time over this cycle to this. Once we know that we can try to
figure out when a reasonable weekly meeting point would be.
Thanks,
should end up with other less frequently run jobs popping up in
future weeks.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: opens
anks for bringing this topic to TC meeting.
>
> Regards,
> Ivan Kolodyazhny,
> Web Developer,
> http://blog.e0ne.info/,
> http://notacash.com/,
> http://kharkivpy.org.ua/
>
> On Thu, Oct 1, 2015 at 1:43 PM, Sean Dague <mailto:s...@dague.net>> wrote:
On 10/08/2015 06:59 AM, Daniel P. Berrange wrote:
> On Wed, Oct 07, 2015 at 02:57:59PM +0200, Thierry Carrez wrote:
>> Sean Dague wrote:
>>> We're starting to make plans for the next cycle. Long term plans are
>>> getting made for details that would happen in
On 10/07/2015 06:22 PM, Monty Taylor wrote:
> On 10/07/2015 09:24 AM, Sean Dague wrote:
>> On 10/07/2015 08:57 AM, Thierry Carrez wrote:
>>> Sean Dague wrote:
>>>> We're starting to make plans for the next cycle. Long term plans are
>>>> getting m
>
> Dean Troyer
> dtro...@gmail.com <mailto:dtro...@gmail.com>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openst
On 10/07/2015 08:57 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> We're starting to make plans for the next cycle. Long term plans are
>> getting made for details that would happen in one or two cycles.
>>
>> As we already have the locations for the N and O sum
tters. It's pretty minor but it doesn't seem like
there is any real reason to wait and have everyone come up with working
names that turn out to be confusing later.
-Sean
--
Sean Dague
http://dague.net
_
why there is a heads up now to get things fixed.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
On 10/07/2015 07:17 AM, Neil Jerram wrote:
> On 07/10/15 12:12, Sean Dague wrote:
>> We've had devstack plugins for about 10 months. They provide a very "pro
>> user" experience by letting you enable arbitrary plugins with:
>>
>> enable_plugin $name
On 10/07/2015 07:02 AM, Daniel P. Berrange wrote:
> On Wed, Oct 07, 2015 at 06:55:44AM -0400, Sean Dague wrote:
>> On 10/07/2015 06:46 AM, Daniel P. Berrange wrote:
>>> In the Liberty version of OpenStack we had a min libvirt of 0.9.11 and
>>> printed a warning on star
ed. The copy / paste method was never supported, and now it will
explicitly break. Now would be a great time for teams to prioritize
getting to the real plugin architecture.
-Sean
--
Sean Dague
http://dague.net
__
O
On 10/07/2015 06:51 AM, Daniel P. Berrange wrote:
> On Wed, Oct 07, 2015 at 06:32:53AM -0400, Sean Dague wrote:
>> The following review https://review.openstack.org/#/c/171098 attempts to
>> raise the minimum libvirt version to 1.0.3.
>>
>> In May that was c
stay on Wheezy
>
> The min distros required would thus be Fedora 21, RHEL 7.0, OpenSUSE 13
> SLES 12, Debian Wheezy and Ubuntu 14.04 (Trusty LTS)
>
> Regards,
> Daniel
>
> [1] https://review.openstack.org/#/c/231917/
Isn't RHEL 7.1 just an update stream on RHEL
we're
regularly testing with. It would also allow some cleaning out of a lot
of conditional pathing, which is getting pretty deep in ifdefs -
https://github.com/openstack/nova/blob/251e09ab69e5dd1ba2c917175bb408c708843f6e/nova/virt/libvirt/driver.py#L359-L424
-Sean
--
Sean Dague
ack usage into that. It
would help spread the word about it, and be a bit easier to understand.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscr
ntry than I think we want for
docs contributions.
There was only 1 use of this in all of Nova, and I think we're better
off removing it and coming up with other ways of addressing it.
-Sean
--
Sean Dague
http://dague.net
__
This is now queued up for discussion this week -
https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda
On 10/01/2015 06:22 AM, Sean Dague wrote:
> Some of us are actively watching the thread / participating. I'll make
> sure it gets on the TC agenda in the near future.
&
bscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
>
n case
> we decide to go that route.
>
> -melanie
As the concensus is for item #1, I'm fine with that. +2 on
https://review.openstack.org/229669.
Let's get that landed and cut a new release today.
-Sean
--
Sean Dague
http://dague.net
_
tibility front, but it's a chunk of
change at this point in the cycle, so I don't think there is a clear win
path. It would be good to collect opinions here. The bug tracking this
is - https://bugs.launchpad.net/python-openstackclient/+bug/1501435
ust putting it out there and watching fallout isn't the
right approach.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@li
ack change that turns off v1. It looks like it wasn't just one
client that got caught in this, but most of them.
This feels like this transition has been too much stick, and not enough
carrot. IIRC openstack client wouldn't work with cinder v2 until a
couple of months ago, as that mad
> that.
>
> Feel free to ping the Release management team members on
> #openstack-relmgr-office if you have any question.
Seems reasonable. Though I miss your sleepy guy icon for the week of
christmas. :) I do see that milestone 2 is 7 weeks to account
and is interested in being more involved. The usual practice is to
> wait a few days for feedback before adding someone new, so I will wait a
> few days before adding dims.
All seems reasonable, +1.
-Sean
--
Sean Dague
http://dague.net
___
tion that could be related to it.
So, it should mostly all be flowers and unicorns. But, keep an eye out
in case a troll shows up under a bridge somewhere.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Developme
to expand OpenStack's
reach, on the TC.
-Sean
--
Sean Dague
irc: sdague
1. https://dague.net/2014/08/26/openstack-as-layers/
2. http://governance.openstack.org/reference/tags/compute_starter_kit.html
3. https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/
Review history: https://
ve me a working VM" should exist in Nova.
It is also fine if there are lower level calls that tweak parts of that,
but nova boot shouldn't have to be a multi step API process for the
user. Building one working VM you can do something with is really the
entire point of Nova.
-Sean
--
is. Defcore is a wider contract that we're trying
to get even more people to write to because that cross section should be
widely deployed. So deprecating something in Defcore is something I
think most teams, Nova included, would be very reluctant to do. It's
just asking for breaking your user
More carrot
than stick.
Just pulling APIs that work for people is a good way to make people mad
at you. But giving a gentle nudge because we're never adding new
goodness here is fine.
-Sean
--
Sean Dague
http://dague.net
__
> application, with no need of additional configuration.
>
> If that suits everyone, I'll then propose deprecation of the
> oslo_middleware.ssl middleware in favor of this one.
Great, thanks, Julien, that looks like a good ball to move forward here
in Mitaka. My +1 added to th
suming that all the client code
out there would work with relative code is a really big assumption.
That's a major API bump for sure.
And it seems like we have enough pieces here to get something better
with the
On 09/23/2015 07:36 AM, Julien Danjou wrote:
> On Wed, Sep 23 2015, Sean Dague wrote:
>
>> Does that solution work in the HA Proxy case where there is one
>> terminating address for multiple backend servers?
>
> Yep.
Ok, how exactly does that work? Because it seems lik
On 09/22/2015 05:30 PM, Mathieu Gagné wrote:
> On 2015-09-22 4:52 PM, Sean Dague wrote:
>> On 09/22/2015 03:16 PM, Mathieu Gagné wrote:
>>>
>>> The oslo_middleware.ssl middleware looks to offer little overhead and
>>> offer the maximum flexibility. I app
On 09/22/2015 03:16 PM, Mathieu Gagné wrote:
> On 2015-09-22 1:46 PM, Sean Dague wrote:
>> On 09/22/2015 12:12 PM, Mathieu Gagné wrote:
>>> On 2015-09-22 7:00 AM, Sean Dague wrote:
>>>>
>>>> My feeling on this one is that we've got this thi
On 09/22/2015 12:12 PM, Mathieu Gagné wrote:
> On 2015-09-22 7:00 AM, Sean Dague wrote:
>>
>> My feeling on this one is that we've got this thing in OpenStack... the
>> Service Catalog. It definitively tells the world what the service
>> addresses are.
>>
On 09/22/2015 11:34 AM, Ben Nemec wrote:
> On 09/22/2015 06:00 AM, Sean Dague wrote:
>> On 09/18/2015 02:30 PM, Ben Nemec wrote:
>>> I've been dealing with this issue lately myself, so here's my two cents:
>>>
>>> It seems to me that solving this at t
hemselves to reflect back their
canonical addresses. Doing point solution rewriting of urls seems odd
when we could just have Nova/Cinder/etc return documents with URLs that
match what's in the service catalog for that service.
-Sean
--
Sean Dague
http://dague.net
701 - 800 of 2095 matches
Mail list logo
