evelopment 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
___
les_test_base.py:144:5: C901
'ApiSampleTestBase._compare_result' is too complex (36)
I honestly think this is one of the things that you declare a flag day a
couple weeks out, warn everyone they are going to have to adjust their
max, and move forward.
, and
the way our resources need urls. I was trying to see if we generate it
on our side, but I'm not seeing it, so I suspect this is just a
consequence of the resource mapper and paste.
-Sean
--
Sean Dague
http://dague.net
anks.
>
>
> [1]: https://review.openstack.org/#/c/441203
> https://review.openstack.org/#/c/455709
>
> 2017-09-08 3:18 GMT+08:00 Sean Dague <s...@dague.net
> <mailto:s...@dague.net>>:
>
> This is an email that's probably overdue, but time gets away
k-core, since he's quite aware of the the devstack
>> codebase
>
> +2 on both of these proposals!
Agreed +2.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage
ild when started. I'd be happy to be
wrong about that, but was told in the past that it was just an OVS
limitation.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questi
202 that we know will never actually do what is asked).
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?s
objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/11/457711/35/check/tempest-dsvm-full-xenial/ec523a2/;
rel="nofollow">tempest-dsvm-full-xenial SUCCESS
in 53m 59s
Those css classes are used as selectors by the Toggle CI code to extract
test results.
sing quick. I really
think that some more pictoral upgrade safety cards or something
explaining the things you need to consider, and what parts projects
handle for you would be really useful. And then revisit whatever the
tagging structure is going to be later.
-Sean
--
Sean Dague
http://dague.
hings.
There is a stop gap work around that's running tests right now -
https://review.openstack.org/#/c/509394/1/devstack-vm-gate-wrap.sh
If it passes I'll approve it to get folks back to work. A longer term
solution is probably needed.
over both, if both are
> enabled; config drive is presumably more secure.
>
> thanks,
> Pino
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.or
bican urls for keys seems like a much
better world to be in.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
h
ke 3rd party CI during
the transition. Sounds good.
The 80 / 20 split seems very reasonable, and a good way to let teams get
back to work while letting the v3 effort make forward progress with real
load to smoke out the issues.
Thanks for flipping over to this model.
-Sean
--
S
derstanding as we work through it all.
>
> Monty
>
> ______
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstac
was shut down for that reason so that no one would
mistakenly assume there was any maintenance or support on it. If you or
others want to revive the project, that would be fine, as long as we can
identify 2 individuals who will step up as maintainers.
-Sean
-
for letting me
represent you the past 4 years.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
e of "close but not
exactly the same" API differences between nova-net and neutron really
makes me want to make sure we never intentionally inflict that confusion
on folks again.
-Sean
--
Sean Dague
http://dague.net
__
o figure out if the folks that mostly had it would also need it
on reboot.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.
lope math and
spot checking on resources used, these really aren't a big concern.
But it's harder to see that until we really start accounting for CI time
by project / person, and what kinds of things really do consume the system.
-Sean
--
to get
some better accounting into the existing system to see where resources
are currently spent, and how we could ensure that time is fairly spread
around to ensure maximum productivity by all developers.
-Sean
--
Sean Dague
http://dague.net
__
between them. Based on the confusion that kept seeming to
come during discussions at the PTG, I think we need to circle around and
figure out if there are different ways to explain this to have greater
clarity.
-Sean
--
Sean Dague
http://dague.net
On 09/19/2017 09:00 AM, Sean Dague wrote:
> I've been iterating through gerrit dashboards this morning trying to
> figure out why they no longer show any changes.
>
> It looks like the query: label:Code-Review>=-2,self now matches changes
> you haven't voted on. Previously
,+2 vote on them.
I'll be poking around today to figure out what the options are to get
equivalent functionality is out of the system, then update the gerrit
dashboards in gerrit-dash-creator based on that.
-Sean
--
Sean Dague
http://dague.
-s-proxy.txt.gz
>
> People new to OpenStack don't really know that 'q' means neutron.
>
>
>
> On Thu, Sep 7, 2017 at 5:45 AM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 08/31/2017 06:27 AM, Sean Dague wrote:
> > The work
and getting this rolling.
Eric
Approved for merge, should be in shortly.
Eric, thanks again for stepping up and pulling this all together. Very
much appreciated.
-Sean
--
Sean Dague
http://dague.net
Thanks,
Eric Fried (efried)
Thank you Eric. Would love to get a recommended pdb path into the docs.
Ping me as soon as it's up for review, and I'll get it merged quickly.
Thanks for stepping up here, it's highly appreciated.
-Sean
--
Sean Dague
to step up there. If so please feel free to reach out,
and we can carve out some PTG time in helping a new push organize here.
However, without new leadership here, the current plan is to just put
the effort to rest.
-Sean
--
Sean Dague
http://dague.net
On 08/31/2017 06:27 AM, Sean Dague wrote:
> The work that started last cycle to make devstack only have a single
> execution mode, that was the same between automated QA and local, is
> nearing it's completion.
>
> https://review.openstack.org/#/c/499186/ is the patch that will
ested qemu, this hasn't
been used for a very long time.
I think this classifies as the kind of thing we can straight remove, and
it will simplify a few things if we do.
-Sean
--
Sean Dague
http://dague.net
__
making jobs pretend to be grenade to keep
screen running), now is the time to run tests against this patch and see
where things stand.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List
a core maintainer of the project.
>
> So to the existing core team members, please respond with a yay/nay and
> after about a week or so we should have a decision (knowing a few cores
> are on vacation right now).
>
+1
--
Sean Dague
http://dague.net
___
wing change will bring back local search behavior like that -
https://review.openstack.org/#/c/493107/
It will need to be landed and release, and probably backported to
stable/pike given that all the branches have been cut.
-Sean
--
Sean Dague
http://dague.net
__
On 08/11/2017 10:49 AM, Anne Gentle wrote:
> On Fri, Aug 11, 2017 at 8:10 AM, Sean Dague <s...@dague.net> wrote:
>> On 08/11/2017 08:50 AM, Anne Gentle | Just Write Click wrote:
>>> Yeah, I need to circle back in the theme work to make sure both search
>>> scope
uot; which would get rid of swift_search
and just use baked in local search. Then on a per site basic people
could turn it on / off, and openstackdocstheme could still be used for
sites that want global search.
-Sean
--
Sean Dague
http://dague.net
c, in the rbd search above it returns content from all
published branches, and seems to be coming back in reverse order. So
mitaka content is the first link for folks for searching from latest docs.
-Sean
--
Sean Dague
http://dague.net
__
rted documentation is going to need
some heavy pruning / editing next cycle to get into shape).
For now it's just a copy and paste of the old opts.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing L
On 08/09/2017 09:24 AM, Sean Dague wrote:
> On 08/09/2017 09:19 AM, Doug Hellmann wrote:
>> Excerpts from Sean Dague's message of 2017-08-08 17:01:29 -0400:
>>> When trying to import
>>> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38c
options' directive. It uses
> the same inputs as the sample file generator. See
> https://docs.openstack.org/oslo.config/latest/reference/sphinxext.html for
> details
So in this case we could:
.. show-options::
oslo.vmware
And that would have the same impact?
-Sean
--
Sean Dague
http:/
it shows up?
If anyone has thoughts on the best resolutions here, that would be great.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
goes in /admin. See
> http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html#proposed-change
> for details.
Ok, I guess a lot of things got binned incorrectly during the
transition. I think the definition of user was less clearly und
On 08/07/2017 05:04 PM, Clark Boylan wrote:
> On Wed, Aug 2, 2017, at 01:44 PM, Clark Boylan wrote:
>> On Wed, Aug 2, 2017, at 11:37 AM, Sean Dague wrote:
>>> On 08/02/2017 12:28 PM, Clark Boylan wrote:
>>>> On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
&
be a couple of sections and
landing documents where appropriate.
Please chime in if you have opinions. Otherwise I'm going to start
writing the rest of this tomorrow to try to get it all sorted for RC.
-Sean
--
Sean Dague
http://dague.net
nk that "Copy and Modify" is a better paradigm. Or "New Flavor
based on X" which will prefill based on an existing one.
The Delete flavor button should come with a giant warning of "This will
make a lot of information in your environment confusing, you should
n
them so that they can create new instances like the ones there.
The only way to change the flavor of an instance is to resize it.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questi
CLI users (nova cli or openstack client)
* Horizon users
* API users (possibly using python APIs, possibly others)
When a person shows up at our site from where ever, we should assume
they are a CLI user. It's universal, and easy to show examples. It's
also just simpler to int
put the docs with the code" would be a simple enough
>> rule that we wouldn't have to think too hard about where to put
>> individual example files, which would speed up the migration.
>
> If I find a doc that tells me how to set up a VM with a Neutron
> network and ports and subnets a
y report of 404 urls posted somewhere public,
that would be extremely useful, because the easy ones based on git
renames are done, and everything else is going to require human
inspection to figure out what the right landing target is.
-Sean
--
Sean Dague
http://dague.net
___
but am trying to use a nova deployed by someone else
> and I start from the python-novaclient or python-openstackclient
> docs because I installed one of those in order to talk to nova.
>
> I thought "put the docs with the code" would be a simple eno
An issue with the xenserver CI was identified. Once we get this patch
in, and backported to ocata, it should also address a frequent grenade
multinode fail scenario which is plaguing the gate.
-Sean
On 08/02/2017 07:17 AM, Sean Dague wrote:
The 3 node scenarios in Neutron (which
he CI runs on both the
main and experimental queue on devstack for this change look pretty
good, so I think we're safe to move forward this time. But we also
thought that the last time, and were wrong.
-Sean
--
Sean Dague
http:/
of tree is not recommended and comes with
all of these risks.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.opensta
in
bounds to paths on the site that haven't been there for 8 years.
It would be really good if we had a way (manual or automated) to have
301 redirects, that are fixable by the teams that now own the
documentation (the project teams).
-Sean
--
Sean Dague
http://dague.net
bscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@list
nding anyone else in this stack
calling set_latent. Is this just a circular bug on the cors.py module?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
inters to your machine learning work that
clustered things, I'd happily take a look and see how that matches with
domain experts. Thanks a bunch for also diving in here!
-Sean
--
Sean Dague
http://dague.net
__
OpenStac
On 07/20/2017 09:27 AM, Sean Dague wrote:
> Here is a starting patch that gets us close (no tests yet) -
> https://review.openstack.org/#/c/485602/ - it's going to require a paste
> change, which is less than idea.
After some #openstack-nova IRC discussion this morning, we decided the
On 07/19/2017 06:28 PM, Matt Riedemann wrote:
> On 7/19/2017 6:16 AM, Sean Dague wrote:
>> We hit a similar issue with placement, and added custom
>> paste middleware for that. Maybe we need to consider a similar thing
>> here, that would only emit if running under uwsgi/apa
On 07/19/2017 06:28 PM, Matt Riedemann wrote:
> On 7/19/2017 6:16 AM, Sean Dague wrote:
>> We hit a similar issue with placement, and added custom
>> paste middleware for that. Maybe we need to consider a similar thing
>> here, that would only emit if running under uwsgi/apa
On 07/19/2017 09:46 PM, Matt Riedemann wrote:
> On 7/19/2017 6:16 AM, Sean Dague wrote:
>> I was just starting to look through some logs to see if I could line up
>> request ids (part of global request id efforts), when I realized that in
>> the process to uwsgi by default
ve their path to said clouds (as
they are beyond the firewall). It's not true with public clouds, but
it's not making the situation any worse, because right now it's shared
passwords to accounts.
-Sean
--
Sean Dague
http://dague.net
_
to match up
everything. We hit a similar issue with placement, and added custom
paste middleware for that. Maybe we need to consider a similar thing
here, that would only emit if running under uwsgi/apache?
Thoughts?
-Sean
--
Sean Dague
http://dague.net
on the right foot.
It would be really nice if we could this as first class support and not
bolt on later, because I fear we're going to get pretty complicated
adhoc schema definitions here that have to be done client side.
-Sean
--
Sean Dague
http://dague.net
On 07/11/2017 04:31 PM, Jeremy Stanley wrote:
On 2017-07-10 07:33:28 -0400 (-0400), Sean Dague wrote:
[...]
Ideally storyboard would just be a lot more receptive to these kinds of
things, by emitting a more native event stream,
Well, there is
http://git.openstack.org/cgit/openstack-infra
eeting, travel plans are more fluid than I
would like today. Will be there if possible.
I will also be unable to attend today due to being in a metal tube at
the time of the meeting.
-Sean
--
Sean Dague
http://dag
e, so that we have a way to deal with bugs in existing
> pike releases, but I think we can retire the repository at any point
> after that.
>
> Thoughts?
+1 and thanks for building the oslosphinx module years ago to start us
down this standardization on themes.
-Sean
-
a
good thing. It's much like the fact that we've largely done gerrit
review dashboards client side, because they are fast to iterate on, then
server side.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development
On 07/05/2017 03:07 PM, Emilien Macchi wrote:
> On Wed, Jun 28, 2017 at 7:33 AM, Ben Nemec <openst...@nemebean.com> wrote:
>>
>>
>> On 06/23/2017 11:52 AM, Sean Dague wrote:
>>>
>>> The Nova bug backlog is just over 800 open bugs, which while
>
On 06/28/2017 10:33 AM, Ben Nemec wrote:
>
>
> On 06/23/2017 11:52 AM, Sean Dague wrote:
>> The Nova bug backlog is just over 800 open bugs, which while
>> historically not terrible, remains too large to be collectively usable
>> to figure out where things stand. We
things
executing at the same time, breaks that. It's cool if someone wants to
do it, however it definitely needs more dedicated folks on the review
side to be successful.
-Sean
--
Sean Dague
http://dague.net
__
Op
On 06/27/2017 09:42 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> I also think it's fine to rebrand WG to SIG, but we should also be
>> honest that it's mostly a rebrand to consolidate on terminology that k8s
>> and cncf have used that people find easier to understand so i
ummaries by teams are pretty critical to increasing the shared
understanding.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.o
die out,
is they need a reasonable amount of project management to be effective.
There are lots of demands on teams, and having someone that can
represent a bigger goal, knows what it looks like when complete, and can
go to the affected teams with "here is the next one thing I need from
you
On 06/26/2017 04:49 AM, Sylvain Bauza wrote:
>
>
> Le 23/06/2017 18:52, Sean Dague a écrit :
>> The Nova bug backlog is just over 800 open bugs, which while
>> historically not terrible, remains too large to be collectively usable
>> to figure out where things st
uggestions are welcomed. The tooling will have the
nova flow in mind, but I'm trying to make it so it takes a project name
as params on all the scripts, so anyone can use it. It's a little hack
and slash right now to discover what the right patterns are.
-Sean
--
Sean Dague
http:/
ree, there should be a single name here. They can delegate and
collect up a group, but at the end of the day one person should be
responsible for it.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List
that people don't need to look at source code is not
as high.
I'm firmly in the camp that sample request / response is a good thing,
but from a priorities perspective it's way more important to get that on
end user APIs than quasi internal ones.
-Sean
--
Sean Dagu
ce would be more, but
those aren't changing so fast that I think they'd be too unweildly to
keep close.
As I have strong feelings that this all would help, I would be happy to
volunteer to manually update that information. Just need enough access
to do that.
-Sean
--
Sean Dague
http:/
ed as one-to-one mapping of repositories
> to corresponding project. It created massive sprawl
> within the ecosystem, limited opportunities for code sharing,
> and made refactoring a nightmare. I lost count of the number
> of times we submitted n inconsistent patches to change
> similar be
On 06/22/2017 04:33 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> [...]
>> I think even if it was only solvable on github, and not cgit, it would
>> help a lot. The idea of using github project tags and pinning suggested
>> by Lauren seems great to me.
>>
and the rest to /openstack-ecosystem or something.
Even if that's flat inside our gerrit and cgit environment.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usag
an be done about it. If not,
> still better than nothing?
I've actually looked through the blockdiag source (to try to solve a
similar problem). There is no easy way to change it.
If people find it confusing, the best thing to do would be s
Glance, or Cinder), it wasn't
applied there.
It's also a question about why a library is doing different back end
testing through full stack testing, instead of more targeted and
controlled behavior. Which I think is probably also less than ideal.
Both would be good things to fix.
-Sean
--
ight? So I get there is some debate on that patch, but is it
blocking anything?
Again, we seem to be missing specifics and a set of events here, which
lacking that everyone is trying to guess what the problems are, which I
don't think is effective.
-Sean
--
Sean Dague
http://dague
reasonable specific thing to fix. It's not a grand issue, it's a
specific mismatch on what configs should be common.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage
xisting in the infra mirror.
-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.op
elp the user eliminate bugs in their program. If they specified marker
twice either they thought it did something, or they made a mistake. Both
are wrong. When we are silent on that front it means they may not be
getting the behavior they were expecting, which hurts their experience
with the API.
igher
> impact on end users.
>
> The point of this email is to find out whether anyone has a better
> suggestion for how to handle this situation.
It would be useful to provide detailed examples. Everything is trade
offs, and having the conversation in the abstrac
mirrored if it would clear a bunch of things up for people. It would
just need to be an extra piece of info in our project list about where
those projects should mirror to (which may not be the same namespace as
in gerrit).
-Sean
--
Sean Dague
http://dague.net
___
eviously Stackforge,
> replacing what was previously called "unofficial OpenStack projects")
> will bring some clarity as to what is OpenStack and what is beyond it.
I think those are all fine. The other term that popped into my head was
"Friends of OpenStack" as a w
warnings work, I'm not 100% confident this is going to be smooth for
everyone. If you hit an issue in your api-ref building after this lands,
please pop up on #openstack-dev and we'll try to work through it.
-Sean
--
Sean Dague
http://dague.net
+ GB disk images
could be classified as a special case of Artifacts, but it turns
optimizing for their specialness is really important to a well
functioning cloud.
Glance might not be the most exciting project, but what seems to be
asked for is help on the existing stuff. I'd
there without
approve authority, especially given the normal trust building exercise
for core teams takes 3+ months. It might be useful to figure out if
there are a set of folks already in the community that the existing core
team would be happy to provisionally promote to h
you set requirements lines to
what are in that file. So that effectively prevents anyone from changing
the linters lines ever (see
http://logs.openstack.org/69/473369/1/check/gate-nova-requirements/b425844/console.html)
-Sean
--
Sean Dague
http://dague.net
cific reason
that's not going to work for you? (e.g. Routes-2.3.1-py2.py3-none-any.whl)
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
distracting, and definitely shouldn't be
happening during the final milestone.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@list
onic reviews to get that into shape for merge would be appreciated.
Comments / questions welcomed. As well as anyone that's interested in
expanding this support to additional services.
-Sean
--
Sean Dague
http://dague
o keep track of the global_request_id coming from Nova
originally, so that the admin events coming back to Nova are tagged with
the original Nova initiating request?
Any advise here, or help in understanding is very welcomed. Thanks in
advance.
-Sean
--
Sean Dague
http
a bump in the review
process as there is a concern that it's changing the API. Though from an
end user perspective that's not happening, it's just changing which
field things get logged into. We'll see if we can work through that.
-Sean
--
Sean Dague
http://dague.net
good long term, is beyond scope right
now), but I wanted to get an idea how this sits with the glance team.
Thanks in advance,
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage
lders, and letting it optimize for a better
experience by OpenStack users. Especially given limited resources.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
1 - 100 of 1956 matches
Mail list logo
