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 those cases internally make every SDK, App
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 th
lly 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
___
OpenStack
em?
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://lis
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
___
OpenStack-operators
On 03/08/2017 07:12 AM, Tim Bell wrote:
On 7 Mar 2017, at 11:52, Sean Dague <s...@dague.net> 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. M
cles 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
OpenStack
misses key details about what'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 me
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
-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.openstack.org/cgi
On 05/27/2016 04:23 AM, Dario Vianello wrote:
>
>> On 25 May 2016, at 17:31, Tim Bell <tim.b...@cern.ch
>> <mailto:tim.b...@cern.ch>> wrote:
>>
>>
>> On 25/05/16 17:36, "Sean Dague" <s...@dague.net
>> <mailto:s.
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 to figure
On 05/23/2016 11:56 AM, Tim Bell wrote:
> On 23/05/16 17:02, "Sean Dague" <s...@dague.net> 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"
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" <s...@dague.net> wrote:
>>>
>>>> On 05/23/2016 10
On 05/23/2016 11:56 AM, Tim Bell wrote:
> On 23/05/16 17:02, "Sean Dague" <s...@dague.net> 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"
ll 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
et 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 before pushing forward on
this.
-Sean
--
Sea
ght 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.openstack.org/#/c/309629/
natives 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
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/mailman/listinfo/openstack
t
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
___
OpenStack
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/listinfo
. It's one of the reasons I think the Ops meetups have been very
successful, as they provide really great forums to do that.
We don't do it with a max 5 minute submit process.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-operators mailing
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
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
signature.asc
Description
25 matches
Mail list logo
