>>>>>>>> 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-crosspr
ROR 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 think
On 11/10/2015 01:37 PM, Armando M. wrote:
>
>
> On 10 November 2015 at 09:49, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> The neutron tempest jobs are now at a 35% failure rate:
> http://tinyurl.com/ne3ex4v (note, 35% is basically t
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
On 11/10/2015 02:24 PM, David Pursehouse wrote:
> On Tue, Nov 10, 2015 at 4:53 AM Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> <...>
>
> Is there any update on label:Code-Review<=-1,group:nova-core ? The group
> search suppo
interface, then iterate 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
___
e 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 services.
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 (not for usage questions)
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
__
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 Development Mailing List (not for
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
>>> do n
ubscribe: 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 Mailing List
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 Devel
/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)
Unsubscribe: op
On 11/06/2015 07:28 AM, John Garbutt wrote:
> On 6 November 2015 at 12:09, Sean Dague <s...@dague.net> 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,
>>&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
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.
-Sean
--
Sean Dague
On 11/06/2015 08:44 AM, Alex Xu wrote:
>
>
> 2015-11-06 20:59 GMT+08:00 Sean Dague <s...@dague.net
> <mailto:s...@dague.net>>:
>
> On 11/06/2015 07:28 AM, John Garbutt wrote:
> > On 6 November 2015 at 12:09, Sean Dague <s...@dague.net
> <
uld 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 the instance/flavor would return
a 400 BadRequest high up at the API level, much like
ou 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 t
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 concern
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:
>>>
inds 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
_
ntermediate 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:
>>
>> * untagged/master: 3 months
clude, 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
ectstorage-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
>
>
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,
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.
>>>
>>>
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
___
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
http://dague.net
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
http://d
On 11/04/2015 10:50 AM, Brant Knudson wrote:
>
>
> On Wed, Nov 4, 2015 at 6:47 AM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> I was spot checking the grenade multinode job to make sure it looks like
> it was doing the c
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 exa
On 11/04/2015 10:13 AM, John Garbutt wrote:
> On 4 November 2015 at 14:49, Jay Pipes <jaypi...@gmail.com> wrote:
>> On 11/04/2015 09:32 AM, Sean Dague wrote:
>>>
>>> On 11/04/2015 09:00 AM, Jay Pipes wrote:
>>>>
>>>> On 11/03/201
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%
>>> performanc
numpy). It seems 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.ope
ling List (not for usage questions)
> Unsubscribe:
> 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 Srinivas :: https://twitter.com/dims
&
.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 no gain.
-Sean
-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
--
Sean
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 url.
I do think the overall approach has a lot of merrit, though it
tash.
>
> 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
___
ly 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
for any functional reasons.
-Sean
--
Sea
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.
-Sean
--
l. 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
ly works.
2) openstack pool -h is 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
_
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.
>
> Than
for both Safari and Chrome - fails the
> same way.
>
> Ihar
>
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.or
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)
Unsubscribe: openstack-dev-requ...
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 Developme
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 <s...@dague.net
> <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) we
s 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
__
OpenStack Development Mailing List (not
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 to
&g
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 carefully.
I think the important thing is to focus
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: openstack-dev-r
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,
-Sean
--
Sean Dague
http://dague.net
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 made f
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 one o
pic 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 <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> Thi
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
http
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
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
here 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?subject:u
. 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
__
OpenStack
py / 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
__
OpenStack D
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 git:/
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 7.0?
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 summ
ean Troyer
> dtro...@gmail.com <mailto:dtro...@gmail.com>
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://
the devstack 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)
Unsubscribe:
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
__
rg/229669 in -W mode in 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
__
.@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> <mailto:openstack-operat...@lists.openstac
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.
>
nt, 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
-Sean
--
Sean Da
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 made me do some weird things in
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...@lists.openstack.org?subject:unsu
.
>
> 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 for it.
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 Development Mailing List
, 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://review.openstack.org/#/q/reviewer:2750,n
terested 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
_
.
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
--
Sean Dague
http://dague.net
___
wer direct APIs. 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 the patch.
t 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 users.
-Sean
--
Sean Dag
ld 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 proxy headers (which could happen early in Mitaka)
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/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
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 the service
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 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 thin
onical 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
s,
> its a glaring hole in our reliability story].
I feel like that's a bad thing to assume of people's systems. What is
the expected behavior of an installer if it discovers installing
OpenStack requires downgrading a library? Halt and catch fire?
It also means we're back to having to pin require
yurl.com/oergv7q
And as such I've proposed making them voting in the Nova check queue -
https://review.openstack.org/222573
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for
;
> [1] Incidentally, this suggests to me that live migrate should just do
> this anyway.
This is an API working group recommendation evolving here. The crux of
which is going to be a structured json error return docume
On 09/10/2015 08:23 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> Right now, they are all a bunch of files, they can be anywhere. And then
>> you have other files that have to reference these files by path, which
>> can be anywhere. We could just punt in that part
privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communicatio
the issues around clouds failing when you try to GET /v2 on
the Nova API (because we have a bunch of knobs you have to align for SSL
termination, and a bunch of deployers didn't), I don't think we should
be satisfied with "there's a config for
to fail until these land.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
On 09/10/2015 01:05 PM, Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2015-09-10 14:23:34 +0200:
>> Sean Dague wrote:
>>> Right now, they are all a bunch of files, they can be anywhere. And then
>>> you have other files that have to reference these f
701 - 800 of 1956 matches
Mail list logo
