api Traceback (most recent
> call last):
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
rough the public interface), with the user context, is
that a network path that would or could be accessible in your case?
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack
from that scenario, it should try to. The baremetal and
affinity cases are pretty good instances where Nova can catch and
recover, and not just export that complexity up.
It would make me sad to just export that complexity to users, and
instead of handing th
On 05/16/2017 12:01 PM, Sean Dague wrote:
> After the forum session on logging, we came up with what we think is an
> approach here for global request ids -
> https://review.openstack.org/#/c/464746/ - it would be great of
> interested operators would confirm this solves their concerns
or especially public cloud users, are there any
concerns that you have in letting users set Request-Id (assuming you'll
also still have a 2nd request-id that's service local and acts like
request-id today)?
-Sean
--
Sean Dague
http://dague.net
_
de them?
In a situation like this, where Cells are geographically bounded, is
there also a Region for that Cell/Glance?
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http:
implementations internally, as well as any that have started on
hierarchical limits/quotas (which I believe Cinder is the only one).
Thanks for your time, and look forward to seeing comments on this.
-Sean
--
Sean Dague
http://dague.net
___
Open
On 03/08/2017 07:12 AM, Tim Bell wrote:
On 7 Mar 2017, at 11:52, Sean Dague wrote:
One of the things that came out of the PTG was perhaps a new path
forward on hierarchical limits that involves storing of limits in
keystone doing counting on the projects. Members of the developer
community
und in circles a bit because everyone is
trying to keep everything in working memory, and paging out parts.
Diagrams hopefully ensure we all are talking about the same things.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing list
at's hard,
possible, or easy when it comes to the code and communities in question.
The operator list feedback is typically by teams that are much more
steeped in the day to days of running OpenStack, have sifted through
chunks of the code, chatted more with community members. It v
On 06/14/2016 11:02 AM, Matt Riedemann wrote:
> A question came up in the nova IRC channel this morning about the
> api_rate_limit config option in nova which was only for the v2 API.
>
> Sean Dague explained that it never really worked because it was per API
> server so if you ha
ved/api-no-more-extensions.html
This is informative for folks, please take a look if you think this will
impact you.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.op
as clouds enable v2.1.
Here is the proposed nova-spec on limited changes we're considering
bringing back in. The setup language is flowery, because I was in a
flowery mood yesterday. :)
Comments are welcomed there - https://review.openstack.org/#/c/3
On 05/27/2016 04:23 AM, Dario Vianello wrote:
>
>> On 25 May 2016, at 17:31, Tim Bell > <mailto:tim.b...@cern.ch>> wrote:
>>
>>
>> On 25/05/16 17:36, "Sean Dague" > <mailto:s...@dague.net>> wrote:
>>
>>> On 05/23/2
of
operations, it is way more likely to happen. If this grows to
"everything", it definitely won't.
It would honestly be great if people affected by this could also
prioritize top to bottom what operations are most important. Detailed
use case and priority is really needed
On 05/23/2016 11:56 AM, Tim Bell wrote:
> On 23/05/16 17:02, "Sean Dague" wrote:
>
>> On 05/23/2016 10:24 AM, Tim Bell wrote:
>>>
>>>
>>> Quick warning for those who are dependent on the "user_id:%(user_id)s"
>>> syntax for li
On 05/24/2016 02:22 AM, Jerome Pansanel wrote:
> Hi,
>
> Le 23/05/2016 18:23, Sean Dague a écrit :
>> On 05/23/2016 11:56 AM, Tim Bell wrote:
>>> On 23/05/16 17:02, "Sean Dague" wrote:
>>>
>>>> On 05/23/2016 10:24 AM, Tim Bell wrote:
>>
On 05/23/2016 11:56 AM, Tim Bell wrote:
> On 23/05/16 17:02, "Sean Dague" wrote:
>
>> On 05/23/2016 10:24 AM, Tim Bell wrote:
>>>
>>>
>>> Quick warning for those who are dependent on the "user_id:%(user_id)s"
>>> syntax for li
ect. Are they all in the same project for other
reasons?
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
and now seems to be the time to do get it rolling.
Feedback on this idea would be welcomed. We're going to deprecate the
proxy APIs regardless, however disable_deprecated_apis is it's own idea
and consequences, and we really want feedback
.
>
> This might not be an issue on newer libvirt/QEMU, we'll see when we
> start testing with Ubuntu 16.04 nodes.
Correct. I tried to build a clarifying comment in the config option here
(as I realized it wasn't described all that well in docs) -
https://review.open
n.
One of the alternatives is to propose your solution upstream.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
we know there is at least one cloud in the wild
that is different).
Comments welcomed.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailma
would it be for sites to be configured so that
internal routing is used whenever possible? Or is this a concept we need
to formalize and make user applications always need to make the decision
about which interface they should access?
-Sean
--
Sean Dague
http://dague.net
t will
make life hell for upgrading. Getting a bunch of specifics on bugs that
triggered during upgrade by anyone doing it would go a long way in
helping us figure out what's the next soft spot to tackle there.
But without that data coming back in specifics it's hard to close
whatever
next couple of hours. But
things are going to be a bit rocky until that bit lands.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/lis
community by building strong communication ties
across different points of views, reaching out across processes, and
being willing, on all parts, to invest time to move things forward
together. It's one of the reasons I think the Ops meetups have been very
succes
ng list
> > OpenStack-operators@lists.openstack.org
> <mailto:OpenStack-operators@lists.openstack.org>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
>
>
> --
> Rackspace Australia
>
>
;ve attempted to get more people engaged to
address these issues over the last 18 months, and never really had
anyone step up. Without some real maintainers of this code in Nova (and
tests somewhere in the community) it's really no longer viable.
-Sean
--
Sean Dague
http://dague.net
29 matches
Mail list logo
