his plumbing.
It causes quite a bit of confusion to new folks, and trips up lots of
people making changes when they forget about it (and hacking fails them).
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development M
On 03/06/2017 08:43 AM, Andreas Jaeger wrote:
> On 2017-03-06 14:03, Sean Dague wrote:
>> I'm trying to understand the implications of
>> https://review.openstack.org/#/c/439500. And the comment in the linked
>> email:
>>
>> ">> Yes, we decided some tim
ur tools aren't making us do work that the i18n
team is ignoring and throwing away.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
in a spec
> > and then projects can sort out what makes the most sense (there
> might be
> > multiple enforcement models available).
> >
> > We still have to figure out the data migration plan to get limits
> data from
>
package.
>
> To solve this, I propose install by "qemu-kvm" name, like in the patch:
> https://review.openstack.org/440353
I think that seems fine, but would like Ian to confirm it won't hurt the
centos 7 work.
-Sean
--
Sean Dague
http://dague.net
_
On 03/01/2017 08:03 AM, Andrea Frittoli wrote:
>
>
> On Wed, Mar 1, 2017 at 12:54 PM Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 03/01/2017 07:35 AM, Jordan Pittier wrote:
> >
> >
> > On Wed, Mar 1, 2
; from a git URL and therefore that wasn't protected.
So, I feel like we hit a similar issue around Vancouver with a pbr bump.
Can we stop capping pbr per rule now?
I also wonder if we can grant the release team +2 permissions on
everything in OpenStack so that fixes like this can be gotten
d and copy
pasted. So it does feel like there has to be at least a couple of
instances in the Tempest tree of how the team *wants* other projects to
write tests that they can point people to.
-Sean
--
Sean Dague
http://dague.net
__
On 02/27/2017 10:49 AM, Monty Taylor wrote:
> On 02/27/2017 09:36 AM, Morgan Fainberg wrote:
>>
>>
>> On Mon, Feb 27, 2017 at 7:26 AM, Sean Dague <s...@dague.net
>> <mailto:s...@dague.net>> wrote:
>>
>> On 02/27/2017 10:22 AM, Morgan Fain
e didn't understand, we've missed a break in the upstream
transition that will impact real clouds. :(
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions
think on the Nova side we need to go back to looking for bogus
endpoint because we don't want issues like this hidden from us.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage que
arounds
using whatever seemed to work to get their job done. Some were more
inventive than others. The hope is that with the stable ``local_conf``
stanza in project-config we're going to have something we can support
going forward even as infrastructure evolves.
--
Sean Dague
http://dague.net
with
them, like admin.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
> Same goes for clouds that swap out RadosGW for Swift. They're looking
> for an OpenStack Object Store API. They're not fuzzy matching on
> project name.
Agree.
That was the general recommendation that has come out of the service
catalog discussions in the past
g in the gate? Is this missing testing, or are there reasons
these configurations would never load that code?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: opens
On 02/09/2017 08:22 AM, Jim Rollenhagen wrote:
> On Thu, Feb 9, 2017 at 7:51 AM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 02/09/2017 07:00 AM, Jim Rollenhagen wrote:
> > Hey folks,
> >
> > Ironic plans to rele
ub.com/openstack-infra/devstack-gate/commit/9c752b02fbd57c7021a7c9295bf4d68a0d1973a8
A stable/ocata branch doesn't require a release. It's an expectation
that all the projects have one of those at this point.
I'd be -1 putting project specific branch selecti
asically run eventlet as a preforking
static worker count webserver).
The ways in which OpenStack and oslo.service uses eventlet are known to
have scaling bottle necks. The Keystone team saw substantial throughput
gains going over to apache hosting.
-Sean
--
Sean D
On 02/02/2017 03:32 PM, Armando M. wrote:
>
>
> On 2 February 2017 at 12:19, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 02/02/2017 02:28 PM, Armando M. wrote:
> >
> >
> > On 2 February 2017 at 10:08, Sean
On 02/02/2017 02:28 PM, Armando M. wrote:
>
>
> On 2 February 2017 at 10:08, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 02/02/2017 12:49 PM, Armando M. wrote:
> >
> >
> > On 2 February 2017 at 08:40, Sean
On 02/02/2017 12:49 PM, Armando M. wrote:
>
>
> On 2 February 2017 at 08:40, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 02/02/2017 11:16 AM, Matthew Treinish wrote:
>
> > <oops, forgot to finish my though>
>
the Answer was "No", with a pushback of "well Nova can't
make that decision in a vacuum", so we then escalated to "Ok, here is
the non vacuum solution".
-Sean
--
Sean Dague
http://dague.net
__
cool with someone taking that task on, but
making a decision about postgresql shouldn't be filibustered on
rewriting all the unit tests in OpenStack because of the ways we use sqlite.
-Sean
--
Sean Dague
http://dague.net
__
st shuffling around deck chairs.
I'm not familiar enough with memory profiling tools in python to know
the right approach we should take there to get this down to individual
libraries / objects that are containing all our memory. Anyone more
skilled here able to help lead the way?
-S
On 02/01/2017 12:24 PM, gordon chung wrote:
>
>
> On 01/02/17 12:15 PM, Sean Dague wrote:
>> What were you thinking about the messaging? TC resolution for
>> deprecation of postgresql as a first class backend?
>>
>> If setup tools want to support thing
On 02/01/2017 12:21 PM, Julien Danjou wrote:
> On Wed, Feb 01 2017, Sean Dague wrote:
>
>> If setup tools want to support things, that's fine, just they do need to
>> realize they are owning that support its not coming from upstream.
>
> The problem as I see it ri
essaging? TC resolution for
deprecation of postgresql as a first class backend?
If setup tools want to support things, that's fine, just they do need to
realize they are owning that support its not coming from upstream.
-Sean
--
Sean Dague
http://dague.net
___
production. I think that it's time to really retire CI on postgresql
entirely. Ad hoc fixes are fine, but all the documentation and basically
all the users are on mysql, and that should be the focus moving forward.
-Sean
--
Sean Dague
http://dague.net
__
ch, means that "export A=B" isn't going to match, when "A=B" would.
The whole strategy around merging here may need some rethinking, but at
this point in the freeze the simpler approach should just be -
https://review.openstack.org/#/c/427282/
-Sean
--
Sean Dague
http:
ntended to
surface more broadly, but until new api-ref it really wasn't possible.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-d
nue to work is
something that we need / want. I don't see any new data coming into our
community that this is less important than it was 4 years ago.
Because consumers of interfaces aren't usually doing the for
self-improvement reasons. They are doing that becau
On 01/20/2017 03:21 PM, Jay Faulkner wrote:
> On Jan 20, 2017, at 9:41 AM, Sean Dague <s...@dague.net> wrote:
>>
>> We released a new os-api-ref yesterday which includes a few
>> enhancements, including the anchor links on the website working as
>> expe
--
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
..@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> ___
On 01/17/2017 11:46 AM, Victor Stinner wrote:
> Le 17/01/2017 à 17:36, Sean Dague a écrit :
>> When putting the cli interface on it, I discovered python3's argparse
>> has subparsers built in. This makes building up the cli much easier, and
>> removes pulling in a dependency
python3 dependency on those environments. Is this an issue in the
Centos 7 land (or any other platforms)?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions
munication gaps that are there. There doesn't seem to be a ton of
natural overlap between contributors to barbican and the base IaaS
services today, which means plenty of communication gaps.
-Sean
--
Sean Dague
http://dague.net
_
s that could be easily done in one project, just
because of communication gaps.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
her hand,
> the following parameter's value is 'null' in the HTTP request body sample.
> But the parameter type is defined as 'none'.
>
> * 'trigger_crash_dump' in "Trigger Crash Dump In Server"
>
> IMO, there is inconsistency of parameter
and not a thing that I'd like us to standardize on. How do we
move forward here to not make volumev2 a required type?
Comments welcome in getting us rolling again.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development
gt; a WSGI daemon mode compared to the embedded mode that is executing calls
> to :80/placement...
>
> Thoughts ? I mean, I can do the cut and drop that, but that will
> certainly have impact for other deployers that were repro
tered office is at 5 Millington Road,
> Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be
> viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may
> contain confidential or privileged information intended for the recipient.
> Any
Hopefully we can get this closed shortly.
Thanks a bunch,
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
On 12/13/2016 01:45 PM, Monty Taylor wrote:
> On 12/13/2016 12:36 PM, Sean Dague wrote:
>> On 12/13/2016 01:29 PM, Augustina Ragwitz wrote:
>>> Previously Markus Z. did some great work in putting together a dashboard
>>> we've been using for bug queue maintenance. A
you can active
work to burn down by closing artifacts is motivating to trying to chew
through the outstanding issues.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questio
nce, a
write up to the mailing list with the notes of what about the issue, the
discussion, the resolution. This isn't only helpful for the people not
in the room, it's also really helpful even for those in the room 6 or 12
months later to try to recall why a particular course of action was taken.
timeline, I think it's pretty obvious once the
> replies roll in which way this goes.
>
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@l
.
Users of this should just change their local.conf to use test-config
instead of post-extra if they want to change TEMPEST_CONF file after
it's been configured.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
On 10/20/2016 06:09 AM, Thierry Carrez wrote:
Sean Dague wrote:
[...]
At 5 services, maybe. But at 50+ services (and growing) I think that the
idea of get an endpoint, then have custom parsing code for every service
because their version documents are different, is a really bad UX.
[...]
Bit
are very valid) here really
point to the fact that punting on that puts SDK and client authors in a
place where they are going to end up writing a ton of heuristic code to
guess url structure. Which would be sad for all of us. :(
-Sean
--
Sean Dague
http://dague.net
; fine, but that'll mean something—service catalog, an API, a new
> project, whatever—is going to have to give me the roots of each
> service.
We should really unwind where you got that information from. The point
of the service catalog is to be exactly what you want it to be. If you,
as a wri
vices are
deployed, to be able to land any patches. Because I think that will
further reduce the pool of developers that can contribute.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailin
breakout would be a good topic to fit into there (one of the
examples listed earlier). The kinds of things we know will impact a set
of projects.
On the technology/support from, it feels like it would be good to have
the equivalent of meeting bot running for every room the entire time
(maybe in pr
things that made midcycles productive for people in teams, to optimize
for track hopping, seems odd.
If there are topics that span teams, there are 2 days up front. Ensuring
there is space to expand topics into there would be good, and not just
make those h
their
successfulness as a member of the TC to help OpenStack than the
candidate email. It's easy to dismiss it as a popularity contest, but I
don't think it is. This is about evaluating the plausible promise that
individuals put forward. Not just the ideas they have, but how likely
they are to be a
s code"
checks).
Joe Gordon used to be pretty aggressive in moving these checks up into
hacking when they seemed to get enough concensus. But since he left the
community, there has been less push on this.
-Sean
--
Sean Dague
http://dague.net
e times
the cost of fixing the thing really just isn't worth the potential
breaks to operators that were operating within the old constraints fine.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack D
rward knowing we were looking at shades of the same thing.
Maybe I'm overly optimistic there, but we as a community also need to
realize the amazing thing that we've built so far. And the fact that
we've build a community that is going strong, despite many of the
found
anding the test hook model, or a common post hook
project that could have core members from multiple teams, or some
generic yaml thing (though I agree, that's a lot harder to wrap my head
around).
-Sean
--
Sean Dague
http://dague.net
_
o the replumb
later. And it mostly comes from having to connect all those pieces then
stage them back out in a non breaking way later.
If this was stuff where the execution control was also embedded in
tox.ini, so changes in callin
if chosen.
-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
dropped XML API support.
-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.opens
lenging isn't really the big
tent, it's the legacy that larger projects carry forward, which just
means the work takes more than a cycle to do.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing Lis
hen being able to go back through history is really useful. That is one
mechanism to do it on demand.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
On 09/26/2016 07:15 AM, Dmitry Tantsur wrote:
> On 09/26/2016 01:09 PM, Sean Dague wrote:
>> This should probably be set at the job level, and not buried inside
>> devstack to be different based on hypervisor. That's going to be a lot
>> more confusing to unwind later.
>
&
_
>>
>> 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
>
his. We are hoping that -
https://review.openstack.org/#/c/375080/ fixes it. But it will be a
couple hours before tests are all in on it.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (no
uld at least take the conf items at the same time (and
probably need a reno on the regard).
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
or anything.
What kind of warning do we need to do on a full table drop? Do we need
to handle the independently?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: ope
nges). Special cherry-picked library versions would be
needed to fix this without openning up a ton of risk for breaking
stable/liberty badly.
That is the bit of work that no one seems to really have picked up.
-Sean
--
Sean Dague
http://dague.net
anges, and
>> help the contributor feel that their changes are valued by the project?
>> Other more experienced PTL’s, ex-PTL’s, long time open-source-community
>> folks, I’m seriously looking for suggestions and ideas.
>>
>>
>>
>> Any and all input
On 09/20/2016 11:20 AM, Daniel P. Berrange wrote:
> On Tue, Sep 20, 2016 at 11:01:23AM -0400, Sean Dague wrote:
>> On 09/20/2016 10:38 AM, Daniel P. Berrange wrote:
>>> On Tue, Sep 20, 2016 at 09:20:15AM -0400, Sean Dague wrote:
>>>> This is a bit delayed due to the
On 09/20/2016 10:38 AM, Daniel P. Berrange wrote:
> On Tue, Sep 20, 2016 at 09:20:15AM -0400, Sean Dague wrote:
>> This is a bit delayed due to the release rush, finally getting back to
>> writing up my experiences at the Ops Meetup.
>>
>> Nova Feedback Session
>&g
On 09/20/2016 10:22 AM, Andrew Laski wrote:
> Excellent writeup, thanks. Some comments inline.
>
>
> On Tue, Sep 20, 2016, at 09:20 AM, Sean Dague wrote:
>>
>>
>> Performance Bottlenecks
>> ---
>>
>> * scheduling issues wi
areas like this.
The full list of all etherpads are here for anyone else looking to
dive in and learn more - https://etherpad.openstack.org/p/NYC-ops-meetup
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Ma
o long email threads and little
action, as we hadn't come together on the problem we were trying to solve.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage question
The last time
something seems related is back in the 4.11/4.12 space. That would be a
much risker change than just rolling back to 4.13.0 at this point in the
release, so I would not recommend it.
So I think Roman's approach of trying to just adjust the timeout seems
like the lowe
orkaround, this is really the way things
should move forward.
Nothing is harmed in the release if there is a mix of 0.7.12 / 0.7.13
minimums. Doug is even proposing that we explicitly allow situations
like that for the next cycle. Projects can merge and
ncidence rate is at that odd race rate that we'll probably have to
merge and just see if it goes away.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Uns
t and delete them? I kind of assumed it would handle all the cleanup
logic itself, including this sort of integrity issue.
The data migration would still take time, and a table lock, even though
it's just deletes, so that feels like it should be avoided.
-Sean
--
Sean Dague
http://dague.net
___
or the gate
> is simply busy at this point of the release cycle), so that we started
> to see these timeouts more often.
The migration count is definitely going to grow over time, as is the
nature of the beast. Nova hasn't had a migration collapse in quite a
while. The higher patch
up with TimeoutException up the
> stack).
Yes, by default testr runs with the number of workers matching the # of
cpus on the target. I think all our cloud providers are now 8 cpu
guests. So unit / functional tests are running 8 way. That's been true
for quite a while IIRC.
-Sean
-
On 09/14/2016 11:23 AM, Thomas Goirand wrote:
> On 09/14/2016 03:15 PM, Sean Dague wrote:
>> I noticed the following issues happening quite often now in the
>> opportunistic db tests for nova -
>> http://logstash.openstack.org/#dashboard/file/logstash.jso
--
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
On 09/08/2016 09:04 AM, Andrew Laski wrote:
>
>
> On Thu, Sep 8, 2016, at 07:18 AM, Sean Dague wrote:
>> On 09/07/2016 07:34 PM, Andrew Laski wrote:
>>>
>>>
>>> On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote:
>>>> On Thu, 2016-09
On 09/08/2016 05:00 AM, Thierry Carrez wrote:
> Sean Dague wrote:
> So... the difference between your proposal and mine is: you force the
> PTL to be the release steward (rather than having a choice there), and
> introduce a delay between election and start of authority for the PTL.
t; has a bright line anywhere. And I think
that basic working networking for requested computes isn't something we
should require another service for.
-Sean
--
Sean Dague
http://dague.net
__
OpenSt
On 09/07/2016 12:27 PM, Thierry Carrez wrote:
> Barrett, Carol L wrote:
>> From: Sean Dague [mailto:s...@dague.net]
>>> I think another option would be to run the PTL election early, but just
>>> don't have the turn over happen until the master release opens up.
nother option would be to run the PTL election early, but just
don't have the turn over happen until the master release opens up. The
current transition period is actually quite short as noted by the
comments around how design summit pl
ova/blob/25abb68039ca122b4b3796a9f8c9e3495db22772/nova/objects/resource_provider.py#L637)
which means which order we'll get the rows and the join means sometimes
we'll be correctly comparing, sometimes we won't. But until you get to 3
guests at once, then you'll never be able to s
at if you have multiple versions of your API
reference document, no one will know if they are on the right one. If
you have one version, and explain "this has been removed, might not be
in your installation, you can find out if it's available with X Y Z".
Then all consumers
here. It's been invaluable.
-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.openst
ep decreasing over time. It will
be deployed and maintained by less and less skilled operators in each
release, because it will be deployed and maintained by more total
operators each release.
Putting DB trigger failure analysis into the toolkit required to manage
an upgrade failu
he scenes with a service user.
Doing context.elevated() and then trying to do this kind of call just
doesn't work (which was in the original patch) because you can't just
conjure keystone admin credentials that way. If so, we'd have a crazy
security issue. :)
Neutron is a better analog he
st the Nova changes with and without the
> placement service to make sure we didn't completely screw something up.
>
> --
>
> If I've left something out please add it here.
>
--
Sean Dague
http://dague.net
ployments are running under different user
ids. Which means shared locks between them are basically not possible.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
bout what locking can look
like in these common libraries, because they have a lot of ported code
that doesn't really work when communicating between 2 services.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Develo
.
There is a lot of value that in these hard problem spaces like zero down
uptime we keep to common patterns between projects because there are
limited folks with the domain knowledge, and splitting that even further
makes it hard to make this more universal among projects.
-Sean
--
Sean Dague
this to completion. It's been a wild couple of
days :)
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
, and leads failure.
I opened a bug https://bugs.launchpad.net/tempest/+bug/1616338, and will fix it.
Thank you for looking into this. Please let me know when you have any
patches up to address the bug so we can prioritize them merging.
Have a great day.
-Sean
--
Sean Dague
http
201 - 300 of 1956 matches
Mail list logo
