o have all this 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
__
OpenStac
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 som
ure our 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: ope
n 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
> > each project into Keystone, and what the
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 <mailto:s...@dague.net>> wrote:
>
> On 03/01/2017 07:35 AM, Jordan Pittier wrote:
> >
> >
> > On Wed, Mar 1, 2017 at 3:57 AM, Ghanshyam
alled directly
> 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 fixe
onsumed that were specifically out of bounds. Either the
team commits to them inbounds, and there is the contract, or moves
forward under the existing contract.
Though, I expect the issue is that because all the Tempest tests work in
this super class way, this is the only stuff people understood
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 > <mailto:s...@dague.net>> wrote:
>>
>> On 02/27/2017 10:22 AM, Morgan Fainberg wrote:
>>
es
that people 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
hanging the catalog entries needs to be
figured out as well.
I 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
_
to support
local.conf in devstack-gate caused folks to do lots of work 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
go
erent 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
enStack 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.
Remove the name field, only keep the type field. Only use generic names
in the type field - https://github
ng 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)
Unsubscr
On 02/09/2017 08:22 AM, Jim Rollenhagen wrote:
> On Thu, Feb 9, 2017 at 7:51 AM, Sean Dague <mailto:s...@dague.net>> wrote:
>
> On 02/09/2017 07:00 AM, Jim Rollenhagen wrote:
> > Hey folks,
> >
> > Ironic plans to release Ocata this week, once
missing -
https://github.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
ack (which is basically 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.
-S
On 02/02/2017 03:32 PM, Armando M. wrote:
>
>
> On 2 February 2017 at 12:19, Sean Dague <mailto:s...@dague.net>> wrote:
>
> On 02/02/2017 02:28 PM, Armando M. wrote:
> >
> >
> > On 2 February 2017 at 10:08, Sean Dague <mailto:s
On 02/02/2017 02:28 PM, Armando M. wrote:
>
>
> On 2 February 2017 at 10:08, Sean Dague <mailto:s...@dague.net>> wrote:
>
> On 02/02/2017 12:49 PM, Armando M. wrote:
> >
> >
> > On 2 February 2017 at 08:40, Sean Dague <mailto:s
On 02/02/2017 12:49 PM, Armando M. wrote:
>
>
> On 2 February 2017 at 08:40, Sean Dague <mailto:s...@dague.net>> wrote:
>
> On 02/02/2017 11:16 AM, Matthew Treinish wrote:
>
> >
> >
> > We definitely aren't saying run
feel like 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
__
I'm totally 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
__
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?
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 things,
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
were you thinking about the messaging? 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:/
ne actually using postgresql in
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
__
ot;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://dague.net
___
get that reflected in api-ref. That's a short term todo
I can probably bang out before the release. It was always intended to
surface more broadly, but until new api-ref it really wasn't possible.
-Sean
--
Sean Dague
http://dague.net
__
probably narrow the focus of whether
guaruntees to the user that their existing code will continue 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
On 01/20/2017 03:21 PM, Jay Faulkner wrote:
> On Jan 20, 2017, at 9:41 AM, Sean Dague wrote:
>>
>> We released a new os-api-ref yesterday which includes a few
>> enhancements, including the anchor links on the website working as
>> expected now.
>>
>> One
-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/m
tp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.
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 depen
will put a
hard 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
roject
managing this whole process, and discovering and bridging the existing
communication 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.
-Sea
e to do a ton of
work in all the projects 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 questio
> * 'suspend' parameter in "Suspend Server (suspend Action)"
>
> On the other hand,
> the following parameter's value is 'null' in the HTTP request body sample.
> But the parameter type is defined as 'none'.
hich is kind
of ugly 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
_
the virtualhost support which also provide
> 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 ha
number 03897010) whose registered 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 f
ks not in this meeting, please make sure we didn't miss anything
here. Hopefully we can get this closed shortly.
Thanks a bunch,
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing
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 maintenan
ng a graph 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 usa
iling 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.
-Sean
ch on
> number of votes or 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)
U
is merged
by the EOD.
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
___
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
x27;s initial complaints (which 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. :(
-S
tever way suits their needs and that there's no "your endpoints
> should be formed like this..." document. If that's how it is, that's
> fine, but that'll mean something—service catalog, an API, a new
> project, whatever—is going to have to give me the roots
services 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 Mailing Li
er
service 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 ti
mary
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 th
putation is much more indicative of 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 ide
hecks).
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
___
status/781890649444519937. Some 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
___
80% of
the changes we needed, and where we didn't agree we were able to move
forward 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
ent like
this. Be it, expanding 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 starting small. It's to
doing all the gate plumbing for a thing in one tree, then do 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 thi
d be honored to serve on the TC again if chosen.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
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
rticular goal is challenging 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
_
no one is looking,
then 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)
Unsubs
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.
&g
__
>>
>> 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
>
ev
looking at this. 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 M
Ok sure, we should 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)
U
last used for 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)
U
r changes). 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
___
try and improve the quality of these changes, 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.
>>
>
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
many .eu folks. Would be
good to increase testing in 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
___
ut, which led to 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 (no
related to this failure. 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 t
an a barely tested Nova workaround, 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
forever.
The incidence 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
oesn't go hunt for these references
first 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.
migrations or just more run VMs per host 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 colla
sses 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.
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.
However
it's not like "orchestration" 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
__
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
e-revised.png
>
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. The
current transition period is actually quite short as noted by the
c
monster
(https://github.com/openstack/nova/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
ve 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 have the same view of the w
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.o
of our operators will keep 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 t
use we're not doing it
with user context, we're doing it behind the 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
he
> experimental queue job we can test 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
__
t in *almost* all real deployments 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
s about 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
__
OpenSt
mechanisms.
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.
drive 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.ope
, 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 2095 matches
Mail list logo
