ng the sphinx version.
Thank you for the patch, I just merged *4.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.or
it can also be refactored in
the future by having keystonemiddleware+oslo.context translate to the
known interface.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
On 05/26/2017 10:05 AM, Lance Bragstad wrote:
>
>
> On Fri, May 26, 2017 at 5:32 AM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 05/26/2017 03:44 AM, John Garbutt wrote:
> > +1 on not forcing Operators to transition to somethi
setting global_id for all client calls
** glance
*** TODO use oslo.middleware for request_id
*** TODO Add setting global_id for all client calls
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing
et policy files in projects to be any more
sensible in their defaults. Leaking is_admin_project all the way through
to a service and having them have to consider it for their policy (which
we do with the context today) definitely feels like a layer violation.
-
python-glanceclient patches have been failing for at least a week due to
a requests change. The fix was posted 5 days ago -
https://review.openstack.org/#/c/466385
It would be nice to get that approved so that other patches could be
considered.
-Sean
--
Sean Dague
http://dague.net
tps://review.openstack.org/467597
Yes, it is designed to be required by base services. See -
http://lists.openstack.org/pipermail/openstack-dev/2017-May/117370.html
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Deve
nks to all of them.
My hope is that we can get this working with Nova, Neutron, Cinder,
Glance this cycle, and let it be a candidate cross project goal in the
future.
-Sean
--
Sean Dague
http://dague.net
__
OpenSt
moving anything at this
point. We're mostly just signaling to people where the nice paved road
is, and where the gravel road is. It's like the signs in the spring
on the road where frost heaves are (at least in the North East US).
-Sean
--
Sean Dague
http://dag
On 05/22/2017 11:26 PM, Matt Riedemann wrote:
> On 5/22/2017 10:58 AM, Sean Dague wrote:
>> I think these are actually compatible concerns. The current proposal to
>> me actually tries to address A1 & B1, with a hint about why A2 is
>> valuable and we would want to do
eir core storage engine for their existing
users?
I do get that when building more targeted things, this might be a value,
but I don't see that as a useful design constraint for OpenStack.
-Sean
--
Sean Dague
http://dague.net
___
On 05/15/2017 07:16 AM, Sean Dague wrote:
> We had a forum session in Boston on Postgresql and out of that agreed to
> the following steps forward:
>
> 1. explicitly warn in operator facing documentation that Postgresql is
> less supported than MySQL. This was deemed better tha
main 0
made it clear that we may need some mechanism where a project is
annotated to be a root (and thus ignores usage further up). This
remains one of those areas where I think the Inside Keystone
Internals vs. Outside view is still hitting communication gaps.
--
Sean
erver uuid.
We could also put a microversion in place so that something more
specific about server list status (all sources reported) was there.
No one expects a 500 error on server list, so we definitely don't want
to give that to people.
-Sean
-
in the future.
We've had specific bug reports in Nova on this, but it's actually a lot
to dig out of because that db migration seems expensive.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing Lis
On 05/19/2017 02:34 PM, Dean Troyer wrote:
> On Fri, May 19, 2017 at 1:04 PM, Sean Dague <s...@dague.net> wrote:
>> These should be used as ways to experiment with the kinds of interfaces
>> we want cheaply, then take them back into services (which is a more
>>
saying "I
want my server to build", or "I'd like Nova to build a volume for me"
are very odd things to call PaaS. I think of PaaS as "here is a ruby on
rails app, provision me a db for it, and make it go". Heroku style.
-Sean
--
Sean Dague
http:/
is
>> very helpful. This definitely gets my support.
>
> Sweet. thanks for the feedback! I just pushed up a new rev yesterday
> based on some feedback from Anne:
>
> http://docs-draft.openstack.org/55/464255/5/check/gate-nova-api-ref-src/f02b170//api-ref/build/html/
http://docs-draft.op
On 05/19/2017 09:22 AM, Sean Dague wrote:
> If you ran a room, please post the project, what you did in the room,
> what you think worked, what you would have done differently. If you
> attended a room you didn't run, please provide feedback about which one
> it was, and what you th
forward.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin
On 05/19/2017 09:04 AM, Chris Dent wrote:
> On Fri, 19 May 2017, Duncan Thomas wrote:
>
>> On 19 May 2017 at 12:24, Sean Dague <s...@dague.net> wrote:
>>
>>> I do get the concerns of extra logic in Nova, but the decision to break
>>> up the working comp
ling on
OpenStack IaaS because that tooling needs to put everything in it's own
retry work queue, lots of folks will just give up.
I do get the concerns of extra logic in Nova, but the decision to break
up the working compute with network and storage problem space across
re we land it and start
using it.
Also, when can we delete all the zookeeper in devstack? As the push
forward here was that this was our supported backend, I'd like to not
put devstack in the business of also zookeeper management.
-Sean
--
Sean Dague
http://dague.net
_
On 05/18/2017 01:02 PM, Mike Bayer wrote:
>
>
> On 05/17/2017 02:38 PM, Sean Dague wrote:
>>
>> Some of the concerns/feedback has been "please describe things that are
>> harder by this being an abstraction", so examples are provided.
>
> so let's go t
It's
not a user interface.
The contract is "Give me an APIKey that can do what I do*" (* with the
exception of self propogating, i.e. the skynet exception).
That's iteration #1. APIKey can do what I can do.
Iteration #2 is fine grained permissions that make it so I
On 05/17/2017 09:34 PM, Adrian Turjak wrote:
>
>
> On 17/05/17 23:20, Sean Dague wrote:
>> On 05/16/2017 07:34 PM, Adrian Turjak wrote:
>>
>>> Anyway that aside, I'm sold on API keys as a concept in this case
>>> provided they are project owned rather tha
content,
> please let me know (or propose the changes).
>
> Thanks,
> Eric (efried)
>
> [1] https://review.openstack.org/#/c/465147/
> [2] https://docs.openstack.org/developer/devstack/systemd.html
Thanks for diving into this Eric, one mor
On 05/15/2017 07:16 AM, Sean Dague wrote:
> We had a forum session in Boston on Postgresql and out of that agreed to
> the following steps forward:
>
> 1. explicitly warn in operator facing documentation that Postgresql is
> less supported than MySQL. This was deemed better tha
Maybe figure out the right visual first, then work backwards on a
structure that can build it. But, like I said in IRC, I'm *so* steeped
in all of this, I definitely don't trust my judgement in what's good for
folks that don't have half the code in their head.
-Sean
--
Sean Dague
htt
t aware of cool. But if not, I think it comes off the table
pretty fast.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-req
uable that these will be separate structures in memory so when they
are exposed through structured logging like fluentd or json, there is no
guessing on the parts in question. Heuristic parsing is definitely a
thing we're trying to get away from.
Because the validation point is going to be in a si
licy today is far too complicated, and I fear
making it a new related, but very different task, way more than building
a different declarative approach that is easier for users to get right.
But... that being said, all of this part is Queens. And regardless of
how this part fal
t's desirable.
Maybe we have different ideas of what we expect to be the kinds of
discussions and asks. What do you think would be in #openstack-tc that
would not be appropriate for #openstack-dev, and why?
-Sean
--
Sean Dague
http://dague.net
_
ant because it is the thing used to talk to the API.
>>>
>>> I really hope we can avoid creating yet more special language for
>>> OpenStack. We've got an API. We want to send keys or tokens. Let's
>>> just call them that.
>>>
>>
>> +1
>
We need to not only manage artifacts, but expectations. And with all the
confusion of projects in the openstack git namespace being officially
blessed openstack projects over the past few years, I can't imagine
people not thinking that openstack infra generated content in dockerh
providers to know if they have any
issues with it?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
here for people to be able to
follow along (out to email or web), and work their way back into the
conversations.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
On 05/16/2017 10:28 AM, Chris Dent wrote:
> On Sun, 14 May 2017, Sean Dague wrote:
>
>> So, the basic idea is, services will optionally take an inbound
>> X-OpenStack-Request-ID which will be strongly validated to the format
>> (req-$uuid). They will continue to always ge
different channel. But I would say we should wait until
that's actually a problem.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
go on openstack-infra@, but no answer so far
>> (the Summit didn't help):
>>
>> http://lists.openstack.org/pipermail/openstack-infra/2017-April/005312.html
>>
>> I think that the answer to the question raised in this thread is definitely
>> going to
t;, "/servers", "GET"). Something along those lines would be
provided as the way to describe permissions from a user.
The complaint is this is a second way of describing permissions. It is.
But the alternative to teach our entire user base about policy name
points is ... far
On 05/14/2017 07:04 AM, Sean Dague wrote:
> One of the things that came up in a logging Forum session is how much
> effort operators are having to put into reconstructing flows for things
> like server boot when they go wrong, as every time we jump a service
> barrier the request
n discussions where it was
clear far more was read into various support statements than was true,
and some very large scale decisions got made with bad information, there
are worse things than not doing things for our users. It's not giving
them the correct set of expectations, and having them build out ass
o a UUID, or at least longer than a UUID?
>>
>> FWIW I don't recall ever hearing this.
>>
>> - ZB
>
> OK, maybe I'm mixing it up with some other field that we expected to be
> a UUID and wasn't. Ignore me and proceed. :-)
Given that the validation will be in a single f
ffixes, but they aren't using
the common middleware.
I've done code look throughs on nova/glance/cinder/neutron/keystone, but
beyond that folks will need to speak up as to where this might break
down. At worst failing validation just means you end up in the old
(current) behavior.
-Sean
--
On 05/15/2017 08:16 AM, Lance Bragstad wrote:
>
>
> On Mon, May 15, 2017 at 6:20 AM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 05/15/2017 05:59 AM, Andrey Volkov wrote:
> >
> >> The last time this came
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
hild flows don't have the new id.
It's also fine to *also* cross log the child/callee request idea on the
parent/caller, but it's not actually going to be sufficiently useful to
most people.
-Sean
--
Sean Dague
http://dague.net
___
ng through the detailed design.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.opensta
that makes upgrading harder than it
really should be.
This is one of those that is going to require someone to commit to
working out that migration path up front. But it would be a pretty good
chunk of debt and upgrade ease.
-Sean
--
Sean Dague
http://dague.net
On 05/05/2017 10:09 AM, Chris Friesen wrote:
> On 05/05/2017 06:16 AM, Sean Dague wrote:
>> On 05/04/2017 11:08 AM, Alex Schultz wrote:
>
>>> Probably because they are still on Kilo. Not sure how much they could
>>> be contributing to the current when
On 05/05/2017 12:36 PM, Alex Schultz wrote:
> On Fri, May 5, 2017 at 6:16 AM, Sean Dague <s...@dague.net> wrote:
>> On 05/04/2017 11:08 AM, Alex Schultz wrote:
>>
>> The general statement of "people care more about features than
>> usability/stability&qu
On 05/05/2017 08:50 AM, Dean Troyer wrote:
> On Fri, May 5, 2017 at 7:16 AM, Sean Dague <s...@dague.net> wrote:
>> The general statement of "people care more about features than
>> usability/stability" gets thrown around a lot. And gets lots of head
>> nod
ause we will know that we need the meeting less (or
less often) when we're regularly ending in 45 minutes, or 30 minutes,
instead of slamming up against the wall with people feeling they had
more to say.
-Sean
--
Sean Dague
http://dague.net
__
the problem as the upstream can
> tend to outpace anyone else in terms of features or anything else. I
> think the the bigger question could be what's the benefit of
> continuing to press forward and add yet more features when consumers
> cannot keep up to consume these? Personally I th
e see what is
required to actually keep the ship afloat.
You could always drop all the hard parts of CI, actually testing the
trees build a full running cloud. But at that point, it becomes very odd
to call it a stable branch, as it is far less rigorous in validation
than master.
At any rate, this basically
ld use a powow in Boston to figure out the
concerns here. Because, honestly we can get compatibility without
keystoneauth1 by going wide here, and just asking folks to add all the
new entries (and making some validation system for people's service
catalog so they can see any changes that mi
tion in devstack/devstack-gate that takes care
> of the log collection so it’ll be the same for all jobs/projects?
>
>
>
> On 3 May 2017 at 13:17:14, Sean Dague (s...@dague.net
> <mailto:s...@dague.net>) wrote:
>
>> As a follow up, there are definitely a few edge condi
doc/source)
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi
uld argue that it is better to keep both screen and systemd, and let users
> choose one of them based on their preference.
>
> Best regards,
> Hongbin
>
>> -Original Message-
>> From: Sean Dague [mailto:s...@dague.net]
>> Sent: May-03-17 6:10 AM
>>
s
it will cover. A lot of times the agenda items are cryptic enough unless
you are knee deep in things.
That would help people collect their thoughts even more and break away
from the few minutes of delay in introducing the subject (the
introduction of the subject would be in the agenda).
On 05/02/2017 08:30 AM, Sean Dague wrote:
> We started running systemd for devstack in the gate yesterday, so far so
> good.
>
> The following patch (which will hopefully land soon), will convert the
> default local use of devstack to systemd as well -
> https://review.openst
le to read, as it
shows how the standard development workflows will change (for the
better) with systemd.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
U
>> dashed format only.
>>
>> -Sean
>>
>
> Sure, that's definitely another option, and again a new function
> would be the way to do it and maintain backwards compatibility.
>
> It sounds like there's a chance there's already bad data in the
> databas
ink so?
I'm not sure why it's believed it would break compatibility, however
format_canonical_uuid() isn't what Nova needs here.
Nova actually wants to stop bad UUIDs ever getting past our API layer,
and just spin back to the user that they handed us corrupt data. Because
it will matter later if t
in advance of this change, do
a Depends-On with that devstack change.
You can also test things locally by using that change, and setting
USE_SCREEN to False.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development
On 04/24/2017 01:58 PM, Sean Dague wrote:
> On 04/24/2017 12:23 PM, Matt Riedemann wrote:
>
>>
>> Is "-----" actually getting past the
>> jsonschema validation check when attaching a volume to a server? Because
>> that's look
_uuid_like was strict enough for
param validation. It is apparently not.
Either it needs to be fixed to be so, or some other function needs to be
created that is, that people can cut over to.
-Sean
--
Sean Dague
http://dague.net
This is all merged now. If you run into any issues with real WSGI
running, please poke up in #openstack-qa and we'll see what we can to to
get things ironned out.
-Sean
On 04/18/2017 07:19 AM, Sean Dague wrote:
> Ok, the patch series has come together now, and
>
ices as real wsgi applications.
-Sean
On 04/13/2017 08:01 AM, Sean Dague wrote:
> One of the many reasons for getting all our API services running wsgi
> under a real webserver is to get out of the custom ports for all
> services game. However, because of some of the limits of apache
> m
for a set of users. But it would be good to be explicit about what's
wrong with instance actions for the original assumption (that past
events should only be exposed there) to not be true. Or if there should
be more of a concerned push to polish the instance_actions API.
-Sean
--
Sean
he 2 year horizon, and other parts that
are more like 5 year ones. Or is that the whole picture to you feels
like it's only a 5 year view? The more specifics the better.
And as Jeremy said, feedback is welcomed in any forum (gerrit, ML, the
survey, direct conversations with folks working on i
it's going to be worth following that patch.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
.
Just to provide a different though related perspective.
This is what success looks like. Lots of different people writing
different stuff, in different ways, talking to your API (which is the
REST API, not a library). Everyone implementing the slices that are
important for the
e for people to be
> using because like it or not, nova-network is going away. We did the
> fallback thing in the CLI in newton as a way to soften that blow for CLI
> users, but really at some point this just needs to be broken and people
> either stay on old tools or upgrade to
eliminates one major
difference between the two. I'm also hoping that we'll be able to keep
and archive the journals from the runs, so you can download and query
those directly. Especially once the oslo.log enhancements are there to
add the additional structured data.
-Sean
--
Sean Dague
write a vision for OpenStack itself.
>
> Members of the Technical Committee met in person around a Board+TC
> meeting in Boston last month, to start building this vision. Then over
> the last month we refined this document with the TC members that could
> not make it in person in Bosto
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Sean Dague
http://dague.net
___
https://review.openstack.org/#/c/452264
>
+1000
It still causes confusion in folks.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ.
The near final draft of the unified limits spec is up now -
https://review.openstack.org/#/c/440815/
If you have not yet wandered in, now is the time, we're going to make
the final go / no go the end of this week.
-Sean
On 03/17/2017 06:36 AM, Sean Dague wrote:
> Backgro
able.
>>
>
> Do we still use _LE() or just _() for marking API error messages for
> translation?
>
All of _L* no longer have any message backings, so using them just means
it's not translated at all. _() is the thing you have to u
et/nova/+bug/1426241
> [6]
> https://docs.openstack.org/developer/nova/policies.html?highlight=metrics#metrics-gathering
>
> [7] https://review.openstack.org/#/c/51135/
>
Yes... with fire.
Realistically this was about the pinnacle of the extensions on
extensions API ch
On 03/17/2017 09:24 AM, Jordan Pittier wrote:
>
>
> On Fri, Mar 17, 2017 at 1:58 PM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 03/17/2017 08:27 AM, Jordan Pittier wrote:
> > The patch that reduced the number of Tempest S
On 03/17/2017 09:39 AM, Andrea Frittoli wrote:
>
>
> On Fri, Mar 17, 2017 at 1:03 PM Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 03/17/2017 08:27 AM, Jordan Pittier wrote:
> > The patch that reduced the number of Tempest S
On 03/17/2017 08:45 AM, Ihar Hrachyshka wrote:
> I had some patches to collect more stats about mlocks
> here: https://review.openstack.org/#/q/topic:collect-mlock-stats-in-gate
> but they need reviews.
Done, sorry I hadn't seen those earlier.
--
Sean Dague
http://
wonder about redoing the change with everything except it and seeing
how that impacts the neutron-api job.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
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
ellmann wrote on 3/9/2017 9:24 PM:
>>>>> Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:
>>>>>> On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:
>>>>>>> On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
>>>>
at of having people there in the room.
Something like that almost seems better done by recording / producing 60
second video spots with PTLs about what each group does, and getting
those run either at the venue or part of collateral on openstac
hanical, and can go under very fast and bulk review.
Guidelines for better tracing are great, work to contribute that in even
better, but that's something that's a lot more work, and different work.
-Sean
--
Sean Dague
http://dague.net
_
cific job -
> gate-tempest-dsvm-neutron-src-oslo.db-ubuntu-xenial-ocata - to test a
> change to the library master branch with stable releases (i.e. Ocata)
> - of all other components?
>
> On Wed, Mar 15, 2017 at 5:20 PM, Sean Dague <s...@dague.net> wrote:
>> On 0
On 03/15/2017 10:38 AM, Mike Bayer wrote:
>
>
> On 03/15/2017 07:30 AM, Sean Dague wrote:
>>
>> The problem was the original patch kept a cap on SQLA, just moved it up
>> to the next pre-release, not realizing the caps in general are the
>> concern by the requir
things easier. However, from an operational point of
view I would be concerned about the idea of services restarting
themselves in a non orchestrated manner. Or that a single key set in the
registry triggers a complete r
same thing from Google when
you have services that can't do the entire oauth/2factor path. Fastmail
rolled out something similar recently as well.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development M
On 03/15/2017 08:10 AM, John Garbutt wrote:
> On 15 March 2017 at 11:58, Jay Pipes <jaypi...@gmail.com> wrote:
>> On 03/15/2017 07:44 AM, Sean Dague wrote:
>>>
>>> On 03/14/2017 11:00 PM, Monty Taylor wrote:
>>>
>>>>
>>>> a) awe
of OpenStack (which puts some real weight on the etcd front)
4) The containers ecosystem, which etcd came out of, has matured
dramatically
I do think this is enough change to when that decision was made to
revisit. As was said elsewhere in this thread, you have to run etcd for
kubernetes, so pick
e get newer SQLA into the system?
The problem was the original patch kept a cap on SQLA, just moved it up
to the next pre-release, not realizing the caps in general are the
concern by the requirements team. So instead of upping the cap, I just
removed it entirely. (It also didn't help o
to it's usage, work better as a dedicated
core team, or inside of Nova. My gut says Queens is the right time to
make that split, and to start planning for it now.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development
we already have a good priority for
> placement in Nova, so I don't think it's a problem to still have it in Nova.
Given that the design was always to split (eventually), and part of that
means that we get to start building up a dedicated core team, I'm not
sure why waiting 3 or 4 additional cycles makes s
and Sean Dague in
#openstack-dev about this, and I think it'll be fine for us to keep the current
INI file approach. I've reached out to Ankur to hopefully restore and continue
this effort.
What do Designate and Cinder folks think of this approach?
The only thing I'd suggest is not to wrap
101 - 200 of 1956 matches
Mail list logo
