penStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
--
Sean Dague
http://dague.net
_
complex (37)
./nova/tests/functional/api_samples_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 a
tifact of the way that paste builds pipelines, 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
> Thanks.
>
>
> [1]: https://review.openstack.org/#/c/441203
> https://review.openstack.org/#/c/455709
>
> 2017-09-08 3:18 GMT+08:00 Sean Dague <mailto:s...@dague.net>>:
>
> This is an email that's probably overdue, but time gets away fro
vstack
>> codebase
>
> +2 on both of these proposals!
Agreed +2.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ..
own / rebuild 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 f
ow this is effectively a silent 500 (giving a
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
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 resu
hat are near the problem, they got confusing 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.
ive things.
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 n
vendor data is presented 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-r
keys, that would be ++. Rebuild
doesn't wait on that, but Barbican 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)
U
tively be treated like 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.
patience! This is a giant rollout with a
> bunch of changes in it, so we really do appreciate everyone's
> understanding as we work through it all.
>
> Monty
>
> __
> OpenStack Development Mailing List (not for usa
The project 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.
-Sea
this fall, and thanks 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-re
fold. Digging out of the multi year hole 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
__
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.openstack.or
my back of the envelope 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 th
cess.
If people are deeply concerned about CI resources, step one is 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
-
re to explain the
differences 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
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. P
a -2,-1,+1,+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 Dagu
-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 <mailto:s...@dague.net>> wrote:
>
> On 08/31/2017 06:27 AM, Sean Dague wrote:
> > The work that starte
p 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://dagu
stemd.html
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.
willing 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:/
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
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
_
ously 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 (no
ect from
> 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
___
or glance docs or cinder docs, etc.
The following 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 give
On 08/11/2017 10:49 AM, Anne Gentle wrote:
> On Fri, Aug 11, 2017 at 8:10 AM, Sean Dague 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
>>> scopes are available. My p
_search = True" 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
nce docs or cinder docs, etc.
Equally problematic, 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
of this imported 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 D
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/6f9fc171800e8a43501
the 'show-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
-
cinder ref once 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
r content 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 c
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:/
o think 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 sho
o this
is useful to 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 L
e and users:
* 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&#
; 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 and floating IP
we could get a weekly 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.
, than if I am not
> *running* nova 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.
>
&
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 are
this impacts your CI / jobs, please speak up. The 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
er (or fix it themselves).
Choosing to do a driver out 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
ly getting 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
h
ttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
east I'm having a hard time finding 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 Li
me pointers 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
_
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
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, we
will also physically remove 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
seful 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://dagu
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://dagu
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
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://dague.net
__
OpenStack
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
-
e processing logic team specific is 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
__
On 07/05/2017 03:07 PM, Emilien Macchi wrote:
> On Wed, Jun 28, 2017 at 7: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 terri
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
cuting 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
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 under
good grasp on the wide range of efforts, and
these summaries by teams are pretty critical to increasing the shared
understanding.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usag
unch of
projects, it turns out that the needs of every project are different.
The reason that multi project efforts seem to take so long, or 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
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
it seemed like a good time to try
this out.
Comments and other suggestions 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
gnee for everything.
I agree, 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
__
Open
of examples so 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.
l here. The topics / tags maintenance 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 d
organized 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
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.
>>
&
openstack, 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 Lis
see what can 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 th
#x27;t on Nova, Tempest, 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
all projects right
now, right? 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.
-Sea
eels like it should be a
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 Devel
not existing 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://lis
int of doing strict validation and returning a 400 is to
help 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 wer
lity to work on issues that may have a higher
> 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, an
ver to the github namespace when we
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.n
eplacing what was previously 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 Op
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:/
sues that current glance users are having. 80+ 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
to be tough to make meaningful contributions 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
let 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
___
rch wheel. Is there a specific 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)
U
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...
/.
Ironic 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
ht
oing to be able to 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
hit 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
--
Se
and while 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
's shoulders, 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
1 - 100 of 2095 matches
Mail list logo
