on that, it would be great.
This is probably not the only big new issue, but it seems like a pretty
concrete one that solving would help drop out merge window (which is 16
hours).
-Sean
--
Sean Dague
http://dague.net
On 08/22/2016 12:10 AM, Michael Still wrote:
So, if this is about preserving CI time, then its cool for me to merge
these on a US Sunday when the gate is otherwise idle, right?
yes.
Michael
On Fri, Aug 19, 2016 at 7:02 AM, Sean Dague <s...@dague.net
<mailto:s...@dague.net&g
On 08/11/2016 10:14 AM, Sean Dague wrote:
>
> So... I overstepped here and jumped to a conclusion based on an
> incorrect understanding of people's sentiments. And there has been some
> concern expressed that part of this conversation was private, which is a
> valid concern. I'm
On 08/18/2016 02:22 PM, Sean Dague wrote:
> On 08/18/2016 11:00 AM, Matt Riedemann wrote:
>> It's that time of year again to talk about killing this job, at least
>> from the integrated gate (move it to experimental for people that care
>> about postgresql, or make it gatin
led down a bit and there is more head room.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr
necessary) would be good. The only other thing I'd like
> to see (and it may already be done) is to have pg upgrade test coverage,
> aka, I don't want to hit that keystone bug again :P But that's a
> different conversation.
That's entirely doable inside the project. W
6-User-Survey-Report.pdf
+1.
Postgresql in the gate hasn't provided any real value in a long time
(tempest just really can't tickle the differences between the dbs,
especially as projects put much better input validation in place).
During icehouse the job was even accident
differences
between what would be in the mitaka tree vs. newton tree was can figure
out an appropriate way to express that in api-ref.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List
t a burndown dashboard for this with Nova -
http://burndown.dague.org/ (source -
https://github.com/sdague/rst-burndown). It should be reasonably
adaptable to other projects if you have a host to run it on.
-Sean
--
Sean Dague
http://dague.net
the
neutron services are running.
I *specifically* left out running nova-net from the networking section
for devstack. If you want to provide a patch that's cool, but figured in
it's deprecated state it's better to not even tell people about it.
-Sean
--
Sean Dague
http://dague.net
___
will
take a while. (Note: this is one of the reasons I suggested the next
step with python3 be full stack testing, because I think we could
actually get Nova working there well in advance of the unit tests
ported, for the above issue. That however requires someone to take on
the work for fu
hing towards putting services in containers, you'd need to
do all sorts of additional work to make this lock path actually a shared
construct between 2 containers.
These are both pretty problematic changes for the entire deploy space
without
nge in master until all the
affected projects had landed release notes / docs around this. Otherwise
this could very well have snuck in to devstack, done the right thing
there, and never been noticed by others.
-S
releases?
5) What is the more ideal long term solution here?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?s
of upgrade. It's very important that
the cinder team is able to keep a very visible hammer for vendors not
living up to their commitments.
Keeping some visible data around drivers that are flapping (going
unsupported, showing up with CI to get back out of the state,
disappearing again) would be
nice to not be overly brutal to our operators
at the same time.
And if not, I think that tags (or lack there of) aren't fully
communicating the situation here. Cinder docs should basically say "only
use ceph / lvm / nf
concern, and have a global default. Or have some way that users are
warned if we think they aren't in a compliant state.
I've put the devstack patch on a -2 hold until we get ACK from both Nova
and Cinder teams that everyone's cool with this.
-Sean
--
Sean Dague
http://dague.net
me.
We do support microversion markup in the document, you can see some of
that in action here in the Nova API Ref -
http://developer.openstack.org/api-ref/compute/?expanded=list-servers-detail
-Sean
--
Sean Dagu
On 08/11/2016 07:56 PM, Tony Breeds wrote:
On Thu, Aug 11, 2016 at 09:13:12AM +0200, Andreas Jaeger wrote:
On 2016-08-10 23:06, Sean Dague wrote:
Based on reading some logs, it looks like requirements updates are
getting regenerated on every requirements land for all open patches,
even
On 08/10/2016 11:46 AM, Sean Dague wrote:
> On 08/10/2016 11:36 AM, Sean Dague wrote:
>> On 08/09/2016 07:30 PM, Heidi Joy Tretheway wrote:
>>> TL;DR: If you don’t want a mascot, you don’t have to. But Nova, you’ll
>>> be missed. :-)
>>>
>>> A few note
another on all of those the same way.
This is probably something that makes sense to add as an image
attribute, because images will need guest configuration to support
serial consoles. As an image attribute this would also help on testing
becau
/scripts/propose_update.sh
and make it so that if the commit did not change, don't push a rebased
review.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
On 08/10/2016 11:36 AM, Sean Dague wrote:
> On 08/09/2016 07:30 PM, Heidi Joy Tretheway wrote:
>> TL;DR: If you don’t want a mascot, you don’t have to. But Nova, you’ll
>> be missed. :-)
>>
>> A few notes following up on Matt Riedemann, Clint Byrum, Daniel
>>
folks working on logos can come up with something
cool around that.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-req
y a thing.
-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.or
portantly, assuming that testing is only valid if it covers
every scenario, sets the bar at entirely the wrong place.
A lower bound test would eliminate some of the worst fiction we've got.
Testing is never 100%. With a complex system like OpenStack, it's
probably not even 1% (
(http://devstack.org) once I'm a few more cups of
coffee into the morning. However, in the mean time, if you see weird
fails during stacking, try deleting PUBLIC_INTERFACE from your local.conf.
-Sean
--
Sean Dague
http://dague.net
e risking to leave minimums where they are and bump
constraints, because the minimums could be lying that they still work at
the lower level.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing Li
breathing space to address any possible fallout from the merge.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
issue that will probably hurt us other places).
So, we could do a lot of work to smooth the transition, which would get
thrown away shortly after, or just create a flag day and have docs
broken for a bit until people get across it.
-Sean
--
Sean Dague
http://dague.net
ts which could actually talk to the outside world. We don't
ever test that they do.The masq rule openned this up for the first time
in our gate as well.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (
On 08/05/2016 11:34 AM, Armando M. wrote:
>
>
> On 5 August 2016 at 05:59, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 08/04/2016 09:15 PM, Armando M. wrote:
> > So glad we are finally within the grasp of this!
>
on, we live with the fails, or we disable the test for now so we
can move forward and get this out to everyone.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions
On 08/04/2016 12:47 PM, John Garbutt wrote:
> On 4 August 2016 at 14:18, Andrew Laski <and...@lascii.com> wrote:
>> On Thu, Aug 4, 2016, at 08:20 AM, Sean Dague wrote:
>>> On 08/03/2016 08:54 PM, Andrew Laski wrote:
>>>> I've brought some of these thou
because
it makes some assumptions on the gate config. That will be fixed soon.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
PI versions.
I think that if we put some code version into place, we'll just assume
we can use that to signal changes, and stop realizing how disruptive it
is to make those changes for existing users.
-Sean
--
Sean Dague
http://dague.net
__
what I remember
other places to test time boundaries like this.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opensta
-02_03_52_14_537923
I'm not fully sure where to go from here. But wanted to make sure that
data is out there. Any keystone folks who can dive into and sort it out
would be highly appreciated.
-Sean
--
Sean Dague
http://dague.net
of the measurements we're
> taking and not let the letter of the new laws kill the spirit.
>
> Yours in cliches,
I do understand that concern. Metrics games definitely can have
unintended consequences. Are there instances of software in our
ecosystem that you consider don
pushing on it too hard. Then folks did, and we
realized that there was kind of a house of cards here, that's required
special intervention to address some of the issues found.
Keeping a diverse community up front helps mitigate some of this. It's
not a silver bullet by any means, but it does help
te if people think there are better timeframes instead.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
ng that
your top priority. If teams aren't interested in putting that ahead of
development work, that's fine, but that doesn't make it a sustainable
OpenStack project.
-Sean
--
Sean Dague
http://dague.net
__
dvance, yamling it up might be in
order. Because this mostly looks like it would reduce to one of those
green/yellow/red checker boards by project and task.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Developmen
That does not require them to grow
> diverse enough to get team:diverse-affiliation.
The idea of 3 cycles to loose the single-vendor tag sounds very
reasonable to me. This also is very much along the spirit of the tag in
that it
r its management, nothing more.
More importantly... *only* xenapi driver implements this, and it's not
exposed over the API. In reality that part of the virt driver layer
should probably be removed.
Like jay said, there are better tools for collecting this than Nova.
-Sean
--
d just be another bump, with
things we apparently missed. I'm not sure it's super important that
there is a REAL proxy API microversion. We got most of it in one go, and
as long as we catch the stragglers in 2.39 (let's make that the last
merged one before the release so that we can figure out anyth
sion 2.37 and has it's own Tempest test, although that test
> relies on Neutron so I might be OK for the most part.
Is that strictly true? We could also just configure all the jobs for
Nova network to set max microversion at 2.35. That would probably be
more straight forward way of appro
s. And when people understand
both sides of a problem, they are more likely to anticipate a problem
during review that no tests caught and didn't seem to change an interface.
This isn't a thing that gets fixed with policy. It get
On 07/25/2016 08:05 AM, Daniel P. Berrange wrote:
> On Mon, Jul 25, 2016 at 07:57:08AM -0400, Sean Dague wrote:
>> On 07/22/2016 11:30 AM, Daniel P. Berrange wrote:
>>> On Thu, Jul 21, 2016 at 07:03:53AM -0700, Matt Riedemann wrote:
>>>> On 7/21/2016 2:03 AM, Bhor, D
On 07/22/2016 09:20 AM, Angus Lees wrote:
> On Thu, 21 Jul 2016 at 09:27 Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 07/12/2016 06:25 AM, Matt Riedemann wrote:
>
> > We probably aren't doing anything while Sean Dague is on
sts. But I also don't
think that embedding another pattern during milestone 3 is the right
time to do it. At least lets hold until next cycle opens up when there
is more time to actually look at trade offs here.
-Sean
--
Sean Dague
http://dague.net
__
enstack.org/337372
The patch is merged.
Also... missing tests have gone missing for long times on all kinds of
projects, including nova / neutron. Missing tests require people keeping
an eye on things, because they don't fail when they disappear.
-Sean
On 07/12/2016 06:25 AM, Matt Riedemann wrote:
We probably aren't doing anything while Sean Dague is on vacation. He's
back next week and we have the nova/cinder meetups, so I'm planning on
talking about the grenade issue in person and hopefully we'll have a
plan by the end of next week to move
in
/etc, aren't really a thing. You really can't have it both ways. Either
these are in the part of the filesystem where ops expect to change them,
or they are not.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
[3] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
It seems prudent.
Thanks Dims for keeping this effort alive so long. It's unfortunate that
no one else was up for maintaining this driver.
-Sean
--
Sean Dague
http://dague.net
.
-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/mailman
little other
than taking up space, so it's mostly just about compaction, which could
be run on a weekly basis.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions
hand. I just think #1 is a more general
> solution.
>
>>>
>>> 3. Order the results by updated_at,created_at so that if updated_at
>>> isn't set for older records, created_at will be used. I think we all
>>> agreed in the mee
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> That's a good point.
I would be +2 on setting updated == created on initial create across the
board in the system. I think people actually expect this because they
assume it's like unix time stamp
commend that you do so sooner rather than
later on that front.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?s
hard to figure out if there is a non manual way
through this. Even if that means some compat code that we keep for a
release to just bridge the gap.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development
On 06/26/2016 10:02 PM, Angus Lees wrote:
> On Fri, 24 Jun 2016 at 20:48 Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 06/24/2016 05:12 AM, Thierry Carrez wrote:
> > I'm adding Possibility (0): change Grenade so that rootwrap
>
o let's focus on that and evaluate the landscape of other
> interpreters when the porting work is done.
+1, please don't get ahead of things until there is real full stack
testing running on python3.
It would also be good if some of our operators were running on python 3
and providing feedback th
orted.
Actually, I don't think so. Matt ran that test scenario, and we're
missing the rootwrap rule that lets privsep-helper run as root. So we
fail to start the daemon from the unpriv nova compute process post upgrade.
-Sean
--
Sean Dague
http://dague.net
nsitioned to privsep. That's fine, but only if we get rid of
> rootwrap soon. So only if we have a plan for (4) anyway. Option (0) is a
> bit of a hard sell for upgrade procedures -- if we need to take a hit in
> that area, let's do (4) directly...
>
> In summary, I think the choice is b
e. But given how close
>> we are to having the initial phase of the port done (thanks Victor!),
>> and how far we are from discussions of priorities for Ocata, it
>> seems very reasonable to set a community-wide goal for our next
>> release cycle.
>>
>> Thoughts?
>>
>>
will need to make sure the rootwrap filters are in place
> _before_ we perform any upgrades.
Are we going to have to do this for every service individually as it
moves to privsep? Or is there a way we can do it common once, take t
On 06/22/2016 03:13 PM, Jay Faulkner wrote:
>
>
> On 6/22/16 12:01 PM, Sean Dague wrote:
>> On 06/22/2016 02:37 PM, Chris Hoge wrote:
>>>> On Jun 22, 2016, at 11:24 AM, Sean Dague <s...@dague.net> wrote:
>>>>
>>>> On 06/22/2016 01:59 PM, C
On 06/22/2016 02:37 PM, Chris Hoge wrote:
>
>> On Jun 22, 2016, at 11:24 AM, Sean Dague <s...@dague.net> wrote:
>>
>> On 06/22/2016 01:59 PM, Chris Hoge wrote:
>>>
>>>> On Jun 20, 2016, at 5:10 AM, Sean Dague <s...@dague.net
>>>> &
On 06/22/2016 01:59 PM, Chris Hoge wrote:
>
>> On Jun 20, 2016, at 5:10 AM, Sean Dague <s...@dague.net
>> <mailto:s...@dague.net>> wrote:
>>
>> On 06/14/2016 07:19 PM, Chris Hoge wrote:
>>>
>>>> On Jun 14, 2016, at 3:59 PM, Edwa
elopment 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
___
sources. It
might be good to get that fixed at the same time, because the resolver
work in pip gets harder to compare results if our order and their order
for string representation is different.
And I agree, the upstream string order is kind of madness. :)
-Sean
--
Sean Dague
http://dague.ne
have to do request validation, and you still have
to actually right controllers and views. Routes has a restful resource
model -
https://routes.readthedocs.io/en/latest/restful.html#restful-services -
which is really not more complicated tha
sion: 2.11
8 bytes to be more explicit on our ACK, and to allow flexibility for
composite actions in the future (which may never be used, so 8 bytes is
our cost).
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Develo
sessions that use cookies and keep some
persistent state over the course of the session (besides auth). Which is
the kind of session support that these frameworks tend to provide.
-Sean
--
Sean Dague
http://dague.net
___
rather than lack of acceptance. If you don't like
> either Flaks or Pecan, look at Pyramid or Pylons or one of the others.
> But please stop building new frameworks that make your project so
> completely different from everything else in the
bad choice here. People are going
to be pretty familiar with it in related projects at this level.
Using selector instead of Routes makes things different for unclear
gain. Sticking with Routes seems more prudent.
Doing Flask is fine, but do it bec
om Neutron into the
current format, I also have been surprised enough by future software
evolution to feel more comfortable that we have a backup plan that
includes a signaling mechanism should we need it.
-Sean
--
Sean Dague
http://dague.net
of issues that are theoretical to our consumers.
http://mcfunley.com/choose-boring-technology
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
y thanks Thierry for
> helping with this effort and guidance. I'll make all the add/remove to
> the requirements-core team when this VOTE passes.
+1
--
Sean Dague
http://dague.net
__
OpenStack Development Mail
her that may need to be surfaced to the user.
For instance network portions of the 'servers' object may get impacted
by Neutron.
With all those possibilities, putting in the extra ~8 bytes to handle
contingencies seemed prudent.
-Sean
--
Sean Dague
http
in ways that become super hard to deal with in
the future.
Test code doesn't need to be normalized to within an inch of it's life.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not f
anything added from Juno -> Mitaka without
signaling has exactly the same client breaking behavior as removing
attributes.
Which is why microversions are needed for attribute adds.
-Sean
--
Sean Dague
http://dague.net
__
that that
URL still exists. That was deleted in Oct 2015. I'll look at getting it
properly cleaned up.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: op
ngs
after transitions, that ops can adjust during their timetable.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
st which goes away in 6 months
Will hopefully be a reasonable enough push to get the behavior we want,
which is everyone publishing the same interface.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Developme
The Tempest changes pretty much just anticipate the Nova changes
which are deleting all these facilities in Newton -
https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/api-no-more-extensions.html
- so in some ways we aren't doing folks a ton of favors letting them
delay too far because t
On 06/14/2016 09:02 AM, Daniel P. Berrange wrote:
> On Tue, Jun 14, 2016 at 07:49:54AM -0400, Sean Dague wrote:
>
> [snip]
>
>> The crux of the problem is that os-brick 1.4 and privsep can't be used
>> without a config file change during the upgrade. Which violate
://bugs.launchpad.net/os-brick/+bug/1592043 is the bug we've got on
this. We should probably sort out the path forward here on the ML as
there are a bunch of folks in a bunch of different time zones that have
important perspectives here.
-Sean
--
Sean Dague
http://dague.net
-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 Development Mailing List (not for usage questions)
Unsubscribe
s are going to watch for those failures, and say, with
-1/+1 CR, when they are legit and when it was off the rails. A non
voting job that doesn't have domain experts validating the content
regularly with CR means it gets ignored
sing glance v2 for the Nova <=> Glance communication -
https://review.openstack.org/#/c/321551/
Thanks to Mike and Sudipta for pushing this to completion.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Develop
Nova as a dependency is really
a hard NACK for a bunch of reasons, including the way dependencies work.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
he complexity by testing both
paths. We'll have a new tested opinionated default that we lead with.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: o
the Pagination guideline [2].
Everett,
Could you be more specific as to what your complaints are? This response
is extremely vague, and mildly passive aggressive, so I don't even know
where to start on responses.
-Sean
--
Sean Dague
http://dague.net
so should be easy to go in quick.
-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.
ine is so close.
>
> Thanks
>
> On Tue, May 31, 2016 at 1:09 AM, Ken'ichi Ohmichi <ken1ohmi...@gmail.com
> <mailto:ken1ohmi...@gmail.com>> wrote:
>
> 2016-05-29 19:25 GMT-07:00 Alex Xu <sou...@gmail.com
> <mailto:sou...@gmail.com>>:
&
e appropriate for this so we don't spend a ton of time
duplicating issues into these buckets.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: opensta
old bugs getting more eyes, it's
all bugs getting less time by developers because the pile is so
insurmountable no one ever wants to look at it.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Developm
On 05/31/2016 05:39 AM, Daniel P. Berrange wrote:
> On Tue, May 24, 2016 at 01:59:17PM -0400, Sean Dague wrote:
>> The team working on live migration testing started with an experimental
>> job on Ubuntu 16.04 to try to be using the latest and greatest libvirt +
>> qemu
301 - 400 of 1956 matches
Mail list logo
