Re: [openstack-dev] Proposal for a process to keep up with Python releases

[Tony Breeds]

On Mon, Oct 22, 2018 at 04:33:49PM +0200, Thomas Goirand wrote:

> One of the reoccurring problem that I'm facing in Debian is that not
> only Python 3 version is lagging behind, but OpenStack dependencies are
> also lagging behind the distro. Often, the answer is "we don't support
> this or that version of X", which of course is very frustrating.

Can you provide a recent instance of this?  I feel like we have a
misunderstanding here.

> One
> thing which would be super nice, would be a non-voting gate job that
> test with the latest version of every Python dependencies as well, so we
> get to see breakage early. We've stopped seeing them since we decided it
> breaks too often and we would hide problems behind the
> global-requirement thing.

We watch for this in requirements where everyday we update to the latest
co-installable dependencies[1] and gate on them.  If that passes it gets
merged into the repo and used by all projects.

Where we could do better is making the failures visible, and we're open
to suggestions there.

We have the following caps:
 cmd2!=0.8.3,<0.9.0;python_version<'3.0'  # MIT
 construct<2.9  # MIT
 Django<2;python_version<'3.0'  # BSD
 Django<2.1;python_version>='3.0'  # BSD
 django-floppyforms<2  # BSD
 elasticsearch<3.0.0  # Apache-2.0
 jsonpath-rw<2.0  # Apache-2.0
 jsonschema<3.0.0  # MIT
 PrettyTable<0.8  # BSD
 python-congressclient<2000  # Apache-2.0
 warlock<2  # Apache-2.0
 XStatic-jQuery<2  # MIT License

These of course do impact the dependencies that are considered
co-installable and we're working towards minimising this list.

You can see from[1] that the lates urllib is incompatible with botocore.
So we'll exclude that from the update and try again.  Meanwahile we'll
file a bug (Possibly a patch) in botocore to get the cap removed or
bumped.


Yours Tony.

[1] https://review.openstack.org/#/c/612252/


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [qa] patrole] Nominating Sergey Vilgelm and Mykola Yakovliev for Patrole core

[Ghanshyam Mann]

+1 for both of them. They have been doing great work in Patrole and will be 
good addition in team. 

-gmann


  On Tue, 23 Oct 2018 03:34:51 +0900 MONTEIRO, FELIPE C  
wrote  
 >   
 > Hi,
 >   
 >  I would like to nominate Sergey Vilgelm and Mykola Yakovliev for Patrole 
 > core as they have both done excellent work the past cycle in improving the 
 > Patrole framework as well as increasing Neutron Patrole test coverage, which 
 > includes various  Neutron plugins/extensions as well like fwaas. I believe 
 > they will both make an excellent addition to the Patrole core team.
 >   
 >  Please vote with a +1/-1 for the nomination, which will stay open for one 
 > week.
 >   
 >  Felipe
 > 
 > __
 > 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
 > 



__
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

Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update

[Matt Riedemann]

On 10/22/2018 4:35 PM, Adrian Turjak wrote:

The one other open question I have is about the Adjutant change [2]. I
know Adjutant is very new and I'm not sure what upgrades look like for
that project, so I don't really know how valuable adding the upgrade
check framework is to that project. Is it like Horizon where it's
mostly stateless and fed off plugins? Because we don't have an upgrade
check CLI for Horizon for that reason.

[1]
https://review.openstack.org/#/q/topic:upgrade-checkers+(status:open+OR+status:merged)
[2]https://review.openstack.org/#/c/611812/


Adjutant's codebase is also going to be a bit unstable for the next few
cycles while we refactor some internals (we're not marking it 1.0 yet).
Once the current set of ugly refactors planned for late Stein are done I
may look at building some upgrade checking, once we also work out what
out upgrade checking should look like. Probably mostly checking config
changes, database migration states, and plugin compatibility.

Adjutant already has a concept of startup checks at least, which while
not anywhere near as extensive as they should be, mostly amount to
making sure your config file looks 'mostly' sane regarding plugins
before starting up the service, and we do intend to expand on that, plus
we can reuse a large chunk of that for upgrade checking.


OK it seems there is not really any point in trying to satisfy the 
upgrade checkers goal for Adjutant in Stein then. Should we just abandon 
the change?


--

Thanks,

Matt

__
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

Re: [openstack-dev] [goals][upgrade-checkers] Week R-25 Update

[Adrian Turjak]

On 20/10/18 4:09 AM, Matt Riedemann wrote:
> The big news this week is we have a couple of volunteer developers
> from NEC (Akhil Jain and Rajat Dhasmana) who are pushing the base
> framework changes across a lot of the projects [1]. I'm trying to
> review as many of these as I can. The request now is for the core
> teams on these projects to review them as well so we can keep moving,
> and then start thinking about non-placeholder specific checks for each
> project.
>
> The one other open question I have is about the Adjutant change [2]. I
> know Adjutant is very new and I'm not sure what upgrades look like for
> that project, so I don't really know how valuable adding the upgrade
> check framework is to that project. Is it like Horizon where it's
> mostly stateless and fed off plugins? Because we don't have an upgrade
> check CLI for Horizon for that reason.
>
> [1]
> https://review.openstack.org/#/q/topic:upgrade-checkers+(status:open+OR+status:merged)
> [2] https://review.openstack.org/#/c/611812/
>
Adjutant's codebase is also going to be a bit unstable for the next few
cycles while we refactor some internals (we're not marking it 1.0 yet).
Once the current set of ugly refactors planned for late Stein are done I
may look at building some upgrade checking, once we also work out what
out upgrade checking should look like. Probably mostly checking config
changes, database migration states, and plugin compatibility.

Adjutant already has a concept of startup checks at least, which while
not anywhere near as extensive as they should be, mostly amount to
making sure your config file looks 'mostly' sane regarding plugins
before starting up the service, and we do intend to expand on that, plus
we can reuse a large chunk of that for upgrade checking.


__
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

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

[Sergio A. de Carvalho Jr.]

https://bugs.launchpad.net/nova/+bug/1799298

On Mon, Oct 22, 2018 at 9:15 PM Sergio A. de Carvalho Jr. <
scarvalh...@gmail.com> wrote:

> Cool, I'll open a bug then.
>
> I was wondering if, before joining the metadata tables with the rest of
> instance data, we could do a UNION, since both tables are structurally
> identical.
>
> On Mon, Oct 22, 2018 at 9:04 PM Dan Smith  wrote:
>
>> > Do you guys see an easy fix here?
>> >
>> > Should I open a bug report?
>>
>> Definitely open a bug. IMHO, we should just make the single-instance
>> load work like the multi ones, where we load the metadata separately if
>> requested. We might be able to get away without sysmeta these days, but
>> we needed it for the flavor details back when the join was added. But,
>> user metadata is controllable by the user and definitely of interest in
>> that code, so just dropping sysmeta from the explicit required_attrs
>> isn't enough, IMHO.
>>
>> --Dan
>>
>
__
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

Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer

[Jason E. Rist]

On 10/19/2018 06:23 AM, Juan Antonio Osorio Robles wrote:
> Hello!
> 
> 
> I would like to propose Bob Fournier (bfournie) as a core reviewer in
> TripleO. His patches and reviews have spanned quite a wide range in our
> project, his reviews show great insight and quality and I think he would
> be a addition to the core team.
> 
> What do you folks think?
> 
> 
> Best Regards
> 
> 
> 
> __
> 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
> 
yup.

-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

[Sergio A. de Carvalho Jr.]

Cool, I'll open a bug then.

I was wondering if, before joining the metadata tables with the rest of
instance data, we could do a UNION, since both tables are structurally
identical.

On Mon, Oct 22, 2018 at 9:04 PM Dan Smith  wrote:

> > Do you guys see an easy fix here?
> >
> > Should I open a bug report?
>
> Definitely open a bug. IMHO, we should just make the single-instance
> load work like the multi ones, where we load the metadata separately if
> requested. We might be able to get away without sysmeta these days, but
> we needed it for the flavor details back when the join was added. But,
> user metadata is controllable by the user and definitely of interest in
> that code, so just dropping sysmeta from the explicit required_attrs
> isn't enough, IMHO.
>
> --Dan
>
__
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

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

[Dan Smith]

> Do you guys see an easy fix here?
>
> Should I open a bug report?

Definitely open a bug. IMHO, we should just make the single-instance
load work like the multi ones, where we load the metadata separately if
requested. We might be able to get away without sysmeta these days, but
we needed it for the flavor details back when the join was added. But,
user metadata is controllable by the user and definitely of interest in
that code, so just dropping sysmeta from the explicit required_attrs
isn't enough, IMHO.

--Dan

__
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

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

[Sergio A. de Carvalho Jr.]

Thanks so much for the replies, guys.

> Have you debugged to the point of knowing where the initial DB query is
starting from?
>
> Looking at history, my guess is this is the change which introduced it
for all requests:
>
> https://review.openstack.org/#/c/276861/

That is my understanding too. Before, metadata was fetched separately but
this change meant that it both tables are always joined with other instance
data.

I've debugged it to the point where the query gets built, in

https://github.com/openstack/nova/blob/mitaka-eol/nova/db/sqlalchemy/api.py#L2005

which results in a number of left outer joins by the "joinedload" calls,
including to "instance_metadata" and "instance_system_metadata".

Most other tables have a single row for each instance (on our clusters,
anyway), so the impact for us is simply down to metadata.

> Just to be clear, you don't have any modifications to the code anywhere,
do you?

We do have some minor changes to Nova but nothing near instance, metadata
or the ORM code.

Do you guys see an easy fix here?

Should I open a bug report?

On Mon, Oct 22, 2018 at 7:17 PM Dan Smith  wrote:

> > We haven't been doing this (intentionally) for quite some time, as we
> > query and fill metadata linearly:
> >
> >
> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2244
> >
> > and have since 2013 (Havana):
> >
> > https://review.openstack.org/#/c/26136/
> >
> > So unless there has been a regression that is leaking those columns back
> > into the join list, I'm not sure why the query you show would be
> > generated.
>
> Ah, Matt Riedemann just pointed out on IRC that we're not doing it on
> single-instance fetch, which is what you'd be hitting in this path. We
> use that approach in a lot of places where the rows would also be
> multiplied by the number of instances, but not in the single case. So,
> that makes sense now.
>
> --Dan
>
> __
> 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
>
__
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

Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer

[Giulio Fidente]

On 10/19/18 2:23 PM, Juan Antonio Osorio Robles wrote:
> Hello!
> 
> 
> I would like to propose Bob Fournier (bfournie) as a core reviewer in
> TripleO. His patches and reviews have spanned quite a wide range in our
> project, his reviews show great insight and quality and I think he would
> be a addition to the core team.
> 
> What do you folks think?

I think thank you Bob!

-- 
Giulio Fidente
GPG KEY: 08D733BA

__
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

Re: [openstack-dev] Proposal for a process to keep up with Python releases

[Zane Bitter]

On 22/10/18 10:33 AM, Thomas Goirand wrote:

On 10/19/18 5:17 PM, Zane Bitter wrote:

We have traditionally held to the principle that we want each release to
support the latest release of CentOS and the latest LTS release of
Ubuntu, as they existed at the beginning of the release cycle.[2]
Currently this means in practice one version of py2 and one of py3, but
in the future it will mean two, usually different, versions of py3.


That's not very nice to forget about the Debian case, which usually
closely precedes Ubuntu. If you want to support Ubuntu better, then
supporting Debian better helps. I usually get the issue before everyone,
as Sid is the distro which is updated the most often. Therefore, please
make sure to include Debian in your proposal.


This is something that needs to be addressed separately I think. It has 
been our long-standing, documented testing policy. If you want to change 
it, make a proposal. For the purposes of this discussion though, the 
main point to take away from the paragraph you quoted is that once 
Python2 is EOL there will rarely be a _single_ version of Python3 that 
is sufficient to support even 2 distros, let alone more.


I haven't forgotten about you, and in fact one of the goals of this 
process is to ensure that we stay up-to-date and not get into situations 
like you had in Rocky where we were two releases behind. Debian will 
definitely benefit from that.



For unit tests, the most important thing is to test on the versions of
Python we target. It's less important to be using the exact distro that
we want to target, because unit tests generally won't interact with
stuff outside of Python.


One of the reoccurring problem that I'm facing in Debian is that not
only Python 3 version is lagging behind, but OpenStack dependencies are
also lagging behind the distro. Often, the answer is "we don't support
this or that version of X", which of course is very frustrating. One
thing which would be super nice, would be a non-voting gate job that
test with the latest version of every Python dependencies as well, so we
get to see breakage early. We've stopped seeing them since we decided it
breaks too often and we would hide problems behind the
global-requirement thing.


I'll leave this to the requirements team, who are more qualified to comment.


And sometimes, we have weird interactions. For example, taskflow was
broken in Python 3.7 before this patch:
https://salsa.debian.org/openstack-team/libs/python-taskflow/commit/6a10261a8a147d901c07a6e7272dc75b9f4d0988

which broke multiple packages using it. Funny thing, it looks like it
wouldn't have happen if we didn't have a pre-version of Python 3.7.1 in
Sid, apparently. Anyway, this can happen again.


So, for example, (and this is still under active debate) for Stein we
might have gating jobs for py35 and py37, with a periodic job for py36.
The T jobs might only have voting py36 and py37 jobs, but late in the T
cycle we might add a non-voting py38 job on master so that people who
haven't switched to the U template yet can see what, if anything,
they'll need to fix.


This can only happen if we have supporting distribution packages for it.
IMO, this is a call for using Debian Testing or even Sid in the gate.


It depends on which versions we choose to support, but if necessary yes.


We'll run the unit tests on any distro we can find that supports the
version of Python we want. It could be a non-LTS Ubuntu, Fedora, Debian
unstable, whatever it takes. We won't wait for an LTS Ubuntu to have a
particular Python version before trying to test it.


I very much agree with that.


Before the start of each cycle, the TC would determine which range of
versions we want to support, on the basis of the latest one we can find
in any distro and the earliest one we're likely to need in one of the
supported Linux distros.


Release of Python aren't aligned with OpenStack cycles. Python 3.7
appeared late in the Rocky cycle. Therefore, unfortunately, doing what
you propose above doesn't address the issue.


This is valuable feedback; it's important to know where there are 
real-world cases that we're not addressing.


Python 3.7 was released 3 weeks after rocky-2 and only 4 weeks before 
rocky-3. TBH I find it hard to imagine any process that would have led 
us to attempt to get every OpenStack project supporting 3.7 in Rocky 
without a radical change in our conception of how OpenStack is distributed.


On the bright side, under this process we would have had 3.6 support in 
Ocata and we could have automatically added a non-voting (or periodic) 
3.7 job during Rocky development as soon as a distro was available for 
testing, which would at least have made it easier to locate problems 
earlier even if we didn't get full 3.7 support until the Stein release.



Integration Tests
-

Integration tests do test, amongst other things, integration with
non-openstack-supplied things in the distro, so it's important that we
test on the 

Re: [openstack-dev] Proposal for a process to keep up with Python releases

[Clark Boylan]

On Mon, Oct 22, 2018, at 7:33 AM, Thomas Goirand wrote:
> On 10/19/18 5:17 PM, Zane Bitter wrote:

snip

> > Integration Tests
> > -
> > 
> > Integration tests do test, amongst other things, integration with
> > non-openstack-supplied things in the distro, so it's important that we
> > test on the actual distros we have identified as popular.[2] It's also
> > important that every project be testing on the same distro at the end of
> > a release, so we can be sure they all work together for users.
> 
> I find very disturbing to see the project only leaning toward these only
> 2 distributions. Why not SuSE & Debian?

It has to do with previous statements about distro support from the TC: 
https://governance.openstack.org/tc/reference/project-testing-interface.html#linux-distributions
 is the [2] above. Changing this would be an orthogonal piece of work even 
though there is relationship between the two topics. Zane's proposal can 
accommodate change in the distro support assertion, but is focused on figuring 
out which python versions to test with that as one of the inputs.

Clark

__
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

Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer

[James Slagle]

On Fri, Oct 19, 2018 at 8:23 AM Juan Antonio Osorio Robles
 wrote:
>
> Hello!
>
>
> I would like to propose Bob Fournier (bfournie) as a core reviewer in
> TripleO. His patches and reviews have spanned quite a wide range in our
> project, his reviews show great insight and quality and I think he would
> be a addition to the core team.
>
> What do you folks think?

+1




-- 
-- James Slagle
--

__
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

[openstack-dev] [cyborg] [nova] Poll: Name for VARs

[Nadathur, Sundar]

Hi,
The name VAR (Virtual Accelerator Request) is introduced in 
https://review.openstack.org/#/c/603955/. It came up during the Stein 
PTG and is being used by default, but some folks have said they find the 
name VAR to be confusing. I would like to resolve this to completion, so 
that whatever name we choose is not subject to recurrent debates in the 
future.


Here is a poll for Cyborg and Nova developers to indicate their 
preferences for existing or proposed options:
https://docs.google.com/spreadsheets/d/179Q8J9qIJNOiVm86K7bWPxo7otTsU18XVCI32V77JaU/edit?usp=sharing 



1. Please add your name, if not already listed, and please feel free to 
propose additional options as you see fit.

2. The voting is by rank -- 1 indicates most preferred.
3. If you strongly oppose a term, you may say 'No' and justify with a 
comment.

   (Comments are added by pressing Ctrl-Alt-M on a cell.)

I'll keep this open for a minimum of two days and possibly for a week 
depending on feedback.


Regards,
Sundar


__
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

[openstack-dev] [qa] patrole] Nominating Sergey Vilgelm and Mykola Yakovliev for Patrole core

[MONTEIRO, FELIPE C]

Hi,

I would like to nominate Sergey Vilgelm and Mykola Yakovliev for Patrole core 
as they have both done excellent work the past cycle in improving the Patrole 
framework as well as increasing Neutron Patrole test coverage, which includes 
various Neutron plugins/extensions as well like fwaas. I believe they will both 
make an excellent addition to the Patrole core team.

Please vote with a +1/-1 for the nomination, which will stay open for one week.

Felipe
__
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

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

[Dan Smith]

> We haven't been doing this (intentionally) for quite some time, as we
> query and fill metadata linearly:
>
> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2244
>
> and have since 2013 (Havana):
>
> https://review.openstack.org/#/c/26136/
>
> So unless there has been a regression that is leaking those columns back
> into the join list, I'm not sure why the query you show would be
> generated.

Ah, Matt Riedemann just pointed out on IRC that we're not doing it on
single-instance fetch, which is what you'd be hitting in this path. We
use that approach in a lot of places where the rows would also be
multiplied by the number of instances, but not in the single case. So,
that makes sense now.

--Dan

__
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

Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

[Ben Nemec]

On 10/22/18 10:32 AM, Morgan Fainberg wrote:
I can spin up the code and make it available. There is an example 
(highly-flask specific right now, but would be easy to make it generic) 
from keystone [0] has been implemented. Where should this code live? A 
new library? oslo.?  The aforementioned example would need 
"external middleware via config" loading capabilities, but that isn't 
hard to do, just adding an oslo.cfg opt and referencing it.


This seems pretty closely related to oslo.middleware, so maybe we could 
put it there? Everything in there now appears to be actual middleware, 
but a module to allow the use of that middleware isn't too much of a 
stretch.




[0] 
https://github.com/openstack/keystone/blob/master/keystone/server/flask/core.py#L93

Cheers,
--Morgan

On Mon, Oct 22, 2018 at 8:12 AM Sean McGinnis > wrote:


On Mon, Oct 22, 2018 at 07:49:35AM -0700, Morgan Fainberg wrote:
 > I should be able to do a write up for Keystone's removal of paste
*and*
 > move to flask soon.
 >
 > I can easily extract the bit of code I wrote to load our external
 > middleware (and add an external loader) for the transition away
from paste.
 >
 > I also think paste is terrible, and would be willing to help
folks move off
 > of it rather than maintain it.
 >
 > --Morgan
 >

Do I detect a volunteer to champion a cycle goal? :)


__
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


__
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



__
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

Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

[Zane Bitter]

On 22/10/18 10:38 AM, Thomas Goirand wrote:

On 10/22/18 12:55 PM, Chris Dent wrote:

My assumption is that it's "something we plan to minimally maintain
because we depend on it". in which case all options would work: the
exact choice depends on whether there is anybody interested in helping
maintaining it, and where those contributors prefer to do the work.


Thus far I'm not hearing any volunteers. If that continues to be the
case, I'll just keep it on bitbucket as that's the minimal change.


Could you please move it to Github, so that at least, it's easier to
check out? Mercurial is always a pain...


FWIW as one data point I probably would have fixed the py37 pull request 
myself instead of just commenting, had it not involved doing:


* A pull request
* on bitbucket
* with Mercurial

(I used to like the Mercurial UI, but it turns out that after_really_ 
learning Git... my brain is full and I can't remember anything else.)


- ZB

__
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

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

[Dan Smith]

> Of course this is only a problem when instances have a lot of metadata
> records. An instance with 50 records in "instance_metadata" and 50
> records in "instance_system_metadata" will fetch 50 x 50 = 2,500 rows
> from the database. It's not difficult to see how this can escalate
> quickly. This can be a particularly significant problem in a HA
> scenario with multiple API nodes pulling data from multiple database
> nodes.

We haven't been doing this (intentionally) for quite some time, as we
query and fill metadata linearly:

https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2244

and have since 2013 (Havana):

https://review.openstack.org/#/c/26136/

So unless there has been a regression that is leaking those columns back
into the join list, I'm not sure why the query you show would be
generated.

Just to be clear, you don't have any modifications to the code anywhere,
do you?

--Dan

__
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

Re: [openstack-dev] [cinder] [nova] Problem of Volume(in-use) Live Migration with ceph backend

[melanie witt]

On Mon, 22 Oct 2018 11:45:55 +0800 (GMT+08:00), Boxiang Zhu wrote:
I created a new vm and a new volume with type 'ceph'[So that the volume 
will be created on one of two hosts. I assume that the volume created on 
host dev@rbd-1#ceph this time]. Next step is to attach the volume to the 
vm. At last I want to migrate the volume from host dev@rbd-1#ceph to 
host dev@rbd-2#ceph, but it failed with the exception 
'NotImplementedError(_("Swap only supports host devices")'.


So that, my real problem is that is there any work to migrate 
volume(*in-use*)(*ceph rbd*) from one host(pool) to another host(pool) 
in the same ceph cluster?
The difference between the spec[2] with my scope is only one is 
*available*(the spec) and another is *in-use*(my scope).



[1] http://docs.ceph.com/docs/master/rbd/rbd-openstack/
[2] https://review.openstack.org/#/c/296150


Ah, I think I understand now, thank you for providing all of those 
details. And I think you explained it in your first email, that cinder 
supports migration of ceph volumes if they are 'available' but not if 
they are 'in-use'. Apologies that I didn't get your meaning the first time.


I see now the code you were referring to is this [3]:

if volume.status not in ('available', 'retyping', 'maintenance'):
LOG.debug('Only available volumes can be migrated using backend '
  'assisted migration. Falling back to generic migration.')
return refuse_to_migrate

So because your volume is not 'available', 'retyping', or 'maintenance', 
it's falling back to generic migration, which will end up with an error 
in nova because the source_path is not set in the volume config.


Can anyone from the cinder team chime in about whether the ceph volume 
migration could be expanded to allow migration of 'in-use' volumes? Is 
there a reason not to allow migration of 'in-use' volumes?


[3] 
https://github.com/openstack/cinder/blob/c42fdc470223d27850627fd4fc9d8cb15f2941f8/cinder/volume/drivers/rbd.py#L1618-L1621


Cheers,
-melanie






__
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

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

[Matt Riedemann]

On 10/22/2018 11:59 AM, Matt Riedemann wrote:
Thanks for this. Have you debugged to the point of knowing where the 
initial DB query is starting from?


Looking at history, my guess is this is the change which introduced it 
for all requests:


https://review.openstack.org/#/c/276861/


From that change, as far as I can tell, we only needed to pre-join on 
metadata because of setting the "launch_metadata" variable:


https://review.openstack.org/#/c/276861/1/nova/api/metadata/base.py@145

I don't see anything directly using system_metadata, although that one 
is sometimes tricky and could be lazy-loaded elsewhere.


I do know that starting in ocata we use system_metadata for dynamic 
vendor metadata:


https://github.com/openstack/nova/blob/stable/ocata/nova/api/metadata/vendordata_dynamic.py#L85

Added in change: https://review.openstack.org/#/c/417780/

But if you don't provide vendor data then that should not be a problem.

--

Thanks,

Matt

__
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

Re: [openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

[Matt Riedemann]

On 10/22/2018 11:25 AM, Sergio A. de Carvalho Jr. wrote:

Hi,

While troubleshooting a production issue we identified that the Nova 
metadata API is fetching a lot more raw data from the database than 
seems necessary. The problem appears to be caused by the SQL query used 
to fetch instance data that joins the "instance" table with, among 
others, two metadata tables: "instance_metadata" and 
"instance_system_metadata". Below is a simplified version of this query 
(I've added the full query at the end of this message for reference):


SELECT ...
   FROM (SELECT ...
           FROM `instances`
          WHERE `instances` . `deleted` = ?
            AND `instances` . `uuid` = ?
          LIMIT ?) AS `anon_1`
   LEFT OUTER JOIN `instance_system_metadata` AS 
`instance_system_metadata_1`
     ON `anon_1` . `instances_uuid` = `instance_system_metadata_1` . 
`instance_uuid`
   LEFT OUTER JOIN (`security_group_instance_association` AS 
`security_group_instance_association_1`

                    INNER JOIN `security_groups` AS `security_groups_1`
                    ON `security_groups_1` . `id` = 
`security_group_instance_association_1` . `security_group_id`
                    AND `security_group_instance_association_1` . 
`deleted` = ?

                    AND `security_groups_1` . `deleted` = ? )
     ON `security_group_instance_association_1` . `instance_uuid` = 
`anon_1` . `instances_uuid`

    AND `anon_1` . `instances_deleted` = ?
   LEFT OUTER JOIN `security_group_rules` AS `security_group_rules_1`
     ON `security_group_rules_1` . `parent_group_id` = 
`security_groups_1` . `id`

    AND `security_group_rules_1` . `deleted` = ?
   LEFT OUTER JOIN `instance_info_caches` AS `instance_info_caches_1`
     ON `instance_info_caches_1` . `instance_uuid` = `anon_1` . 
`instances_uuid`

   LEFT OUTER JOIN `instance_extra` AS `instance_extra_1`
     ON `instance_extra_1` . `instance_uuid` = `anon_1` . `instances_uuid`
   LEFT OUTER JOIN `instance_metadata` AS `instance_metadata_1`
     ON `instance_metadata_1` . `instance_uuid` = `anon_1` . 
`instances_uuid`

    AND `instance_metadata_1` . `deleted` = ?

The instance table has a 1-to-many relationship to both 
"instance_metadata" and "instance_system_metadata" tables, so the query 
is effectively producing a cross join of both metadata tables.


To illustrate the impact of this query, I have an instance that has 2 
records in "instance_metadata" and 5 records in "instance_system_metadata":


 > select instance_uuid,`key`,value from instance_metadata where 
instance_uuid = 'a6cf4a6a-effe-4438-9b7f-d61b23117b9b';

+--+---++
| instance_uuid                        | key       | value  |
+--+---++
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property1 | value1 |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property2 | value  |
+--+---++
2 rows in set (0.61 sec)

 > select instance_uuid,`key`,valusystem_metadata where instance_uuid = 
'a6cf4a6a-effe-4438-9b7f-d61b23117b9b';

++--+
| key                    | value                                |
++--+
| image_disk_format      | qcow2                                |
| image_min_ram          | 0                                    |
| image_min_disk         | 20                                   |
| image_base_image_ref   | 39cd564f-6a29-43e2-815b-62097968486a |
| image_container_format | bare                                 |
++--+
5 rows in set (0.00 sec)

For this particular instance, the query used by the metadata API will 
fetch 10 records from the database:


+--+-+---++--+
| anon_1_instances_uuid                | instance_metadata_1_key | 
instance_metadata_1_value | instance_system_metadata_1_key | 
instance_system_metadata_1_value     |

+--+-+---++--+
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property1               | 
value1                    | image_disk_format              | qcow2   
                          |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property2               | value 
                     | image_disk_format              | qcow2   
                      |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property1               | 
value1                    | image_min_ram                  | 0   
                          |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property2               | value 
                     | image_min_ram                  | 0   

[openstack-dev] [nova] Metadata API cross joining "instance_metadata" and "instance_system_metadata"

[Sergio A. de Carvalho Jr.]

Hi,

While troubleshooting a production issue we identified that the Nova
metadata API is fetching a lot more raw data from the database than seems
necessary. The problem appears to be caused by the SQL query used to fetch
instance data that joins the "instance" table with, among others, two
metadata tables: "instance_metadata" and "instance_system_metadata". Below
is a simplified version of this query (I've added the full query at the end
of this message for reference):

SELECT ...
  FROM (SELECT ...
  FROM `instances`
 WHERE `instances` . `deleted` = ?
   AND `instances` . `uuid` = ?
 LIMIT ?) AS `anon_1`
  LEFT OUTER JOIN `instance_system_metadata` AS `instance_system_metadata_1`
ON `anon_1` . `instances_uuid` = `instance_system_metadata_1` .
`instance_uuid`
  LEFT OUTER JOIN (`security_group_instance_association` AS
`security_group_instance_association_1`
   INNER JOIN `security_groups` AS `security_groups_1`
   ON `security_groups_1` . `id` =
`security_group_instance_association_1` . `security_group_id`
   AND `security_group_instance_association_1` . `deleted`
= ?
   AND `security_groups_1` . `deleted` = ? )
ON `security_group_instance_association_1` . `instance_uuid` = `anon_1`
. `instances_uuid`
   AND `anon_1` . `instances_deleted` = ?
  LEFT OUTER JOIN `security_group_rules` AS `security_group_rules_1`
ON `security_group_rules_1` . `parent_group_id` = `security_groups_1` .
`id`
   AND `security_group_rules_1` . `deleted` = ?
  LEFT OUTER JOIN `instance_info_caches` AS `instance_info_caches_1`
ON `instance_info_caches_1` . `instance_uuid` = `anon_1` .
`instances_uuid`
  LEFT OUTER JOIN `instance_extra` AS `instance_extra_1`
ON `instance_extra_1` . `instance_uuid` = `anon_1` . `instances_uuid`
  LEFT OUTER JOIN `instance_metadata` AS `instance_metadata_1`
ON `instance_metadata_1` . `instance_uuid` = `anon_1` . `instances_uuid`
   AND `instance_metadata_1` . `deleted` = ?

The instance table has a 1-to-many relationship to both "instance_metadata"
and "instance_system_metadata" tables, so the query is effectively
producing a cross join of both metadata tables.

To illustrate the impact of this query, I have an instance that has 2
records in "instance_metadata" and 5 records in "instance_system_metadata":

> select instance_uuid,`key`,value from instance_metadata where
instance_uuid = 'a6cf4a6a-effe-4438-9b7f-d61b23117b9b';
+--+---++
| instance_uuid| key   | value  |
+--+---++
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property1 | value1 |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property2 | value  |
+--+---++
2 rows in set (0.61 sec)

> select instance_uuid,`key`,valusystem_metadata where instance_uuid =
'a6cf4a6a-effe-4438-9b7f-d61b23117b9b';
++--+
| key| value|
++--+
| image_disk_format  | qcow2|
| image_min_ram  | 0|
| image_min_disk | 20   |
| image_base_image_ref   | 39cd564f-6a29-43e2-815b-62097968486a |
| image_container_format | bare |
++--+
5 rows in set (0.00 sec)

For this particular instance, the query used by the metadata API will fetch
10 records from the database:

+--+-+---++--+
| anon_1_instances_uuid| instance_metadata_1_key |
instance_metadata_1_value | instance_system_metadata_1_key |
instance_system_metadata_1_value |
+--+-+---++--+
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property1   | value1
 | image_disk_format  | qcow2
 |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property2   | value
  | image_disk_format  | qcow2
   |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property1   | value1
 | image_min_ram  | 0
 |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property2   | value
  | image_min_ram  | 0
   |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | property1   | value1
 | image_min_disk | 20
  |
| a6cf4a6a-effe-4438-9b7f-d61b23117b9b | 

Re: [openstack-dev] [Openstack-operators] [Octavia] [Kolla] SSL errors polling amphorae and missing tenant network interface

[Gaël THEROND]

Doing the same documentation process here as well (except that I’m using
kolla). The only annoying thing is the doc submission process :-/.

Le lun. 22 oct. 2018 à 16:50, Erik McCormick  a
écrit :

> Oops, dropped Operators. Can't wait until it's all one list...
> On Mon, Oct 22, 2018 at 10:44 AM Erik McCormick
>  wrote:
> >
> > On Mon, Oct 22, 2018 at 4:23 AM Tobias Urdin 
> wrote:
> > >
> > > Hello,
> > >
> > > I've been having a lot of issues with SSL certificates myself, on my
> > > second trip now trying to get it working.
> > >
> > > Before I spent a lot of time walking through every line in the DevStack
> > > plugin and fixing my config options, used the generate
> > > script [1] and still it didn't work.
> > >
> > > When I got the "invalid padding" issue it was because of the DN I used
> > > for the CA and the certificate IIRC.
> > >
> > >  > 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING
> > > octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect
> > > to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa
> > > routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'),
> > > ('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'),
> > > ('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
> > >  > 19:47 < tobias-urdin> after a quick google "The problem was that my
> > > CA DN was the same as the certificate DN."
> > >
> > > IIRC I think that solved it, but then again I wouldn't remember fully
> > > since I've been at so many different angles by now.
> > >
> > > Here is my IRC logs history from the #openstack-lbaas channel, perhaps
> > > it can help you out
> > > http://paste.openstack.org/show/732575/
> > >
> >
> > Tobias, I owe you a beer. This was precisely the issue. I'm deploying
> > Octavia with kolla-ansible. It only deploys a single CA. After hacking
> > the templates and playbook to incorporate a separate server CA, the
> > amphorae now load and provision the required namespace. I'm adding a
> > kolla tag to the subject of this in hopes that someone might want to
> > take on changing this behavior in the project. Hopefully after I get
> > through Upstream Institute in Berlin I'll be able to do it myself if
> > nobody else wants to do it.
> >
> > For certificate generation, I extracted the contents of
> > octavia_certs_install.yml (which sets up the directory structure,
> > openssl.cnf, and the client CA), and octavia_certs.yml (which creates
> > the server CA and the client certificate) and mashed them into a
> > separate playbook just for this purpose. At the end I get:
> >
> > ca_01.pem - Client CA Certificate
> > ca_01.key - Client CA Key
> > ca_server_01.pem - Server CA Certificate
> > cakey.pem - Server CA Key
> > client.pem - Concatenated Client Key and Certificate
> >
> > If it would help to have the playbook, I can stick it up on github
> > with a huge "This is a hack" disclaimer on it.
> >
> > > -
> > >
> > > Sorry for hijacking the thread but I'm stuck as well.
> > >
> > > I've in the past tried to generate the certificates with [1] but now
> > > moved on to using the openstack-ansible way of generating them [2]
> > > with some modifications.
> > >
> > > Right now I'm just getting: Could not connect to instance. Retrying.:
> > > SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
> > > from the amphoras, haven't got any further but I've eliminated a lot of
> > > stuck in the middle.
> > >
> > > Tried deploying Ocatavia on Ubuntu with python3 to just make sure there
> > > wasn't an issue with CentOS and OpenSSL versions since it tends to lag
> > > behind.
> > > Checking the amphora with openssl s_client [3] it gives the same one,
> > > but the verification is successful just that I don't understand what
> the
> > > bad signature
> > > part is about, from browsing some OpenSSL code it seems to be related
> to
> > > RSA signatures somehow.
> > >
> > > 140038729774992:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad
> > > signature:s3_clnt.c:2032:
> > >
> > > So I've basicly ruled out Ubuntu (openssl-1.1.0g) and CentOS
> > > (openssl-1.0.2k) being the problem, ruled out signing_digest, so I'm
> > > back to something related
> > > to the certificates or the communication between the endpoints, or what
> > > actually responds inside the amphora (gunicorn IIUC?). Based on the
> > > "verify" functions actually causing that bad signature error I would
> > > assume it's the generated certificate that the amphora presents that is
> > > causing it.
> > >
> > > I'll have to continue the troubleshooting to the inside of the amphora,
> > > I've used the test-only amphora image before but have now built my own
> > > one that is
> > > using the amphora-agent from the actual stable branch, but same issue
> > > (bad signature).
> > >
> > > For verbosity this is the config options set for the certificates in
> > > octavia.conf and which file it was copied from [4], same here, a
> > > replication of what openstac

[openstack-dev] [ironic] Team gathering at the Forum?

[Dmitry Tantsur]

Hi ironicers! :)

We are trying to plan an informal Ironic team gathering in Berlin. If you care 
about Ironic and would like to participate, please fill in 
https://doodle.com/poll/iw5992px765nthde. Note that the location is tentative, 
also depending on how many people sign up.


Dmitry

__
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

Re: [openstack-dev] [nova] spec review day is ON for next tuesday oct 23

[melanie witt]

On Tue, 16 Oct 2018 10:56:38 -0700, Melanie Witt wrote:

Thanks everyone for your replies on the thread to help organize this.

Looks like most of the team is available to participate, so we will have
a spec review day next week on Tuesday October 23.


Just wanted to remind everybody that the spec review day is tomorrow!

Cheers,
-melanie




__
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

Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

[Morgan Fainberg]

I can spin up the code and make it available. There is an example
(highly-flask specific right now, but would be easy to make it generic)
from keystone [0] has been implemented. Where should this code live? A new
library? oslo.?  The aforementioned example would need "external
middleware via config" loading capabilities, but that isn't hard to do,
just adding an oslo.cfg opt and referencing it.

[0]
https://github.com/openstack/keystone/blob/master/keystone/server/flask/core.py#L93
Cheers,
--Morgan

On Mon, Oct 22, 2018 at 8:12 AM Sean McGinnis  wrote:

> On Mon, Oct 22, 2018 at 07:49:35AM -0700, Morgan Fainberg wrote:
> > I should be able to do a write up for Keystone's removal of paste *and*
> > move to flask soon.
> >
> > I can easily extract the bit of code I wrote to load our external
> > middleware (and add an external loader) for the transition away from
> paste.
> >
> > I also think paste is terrible, and would be willing to help folks move
> off
> > of it rather than maintain it.
> >
> > --Morgan
> >
>
> Do I detect a volunteer to champion a cycle goal? :)
>
>
> __
> 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
>
__
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

Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

[Sean McGinnis]

On Mon, Oct 22, 2018 at 07:49:35AM -0700, Morgan Fainberg wrote:
> I should be able to do a write up for Keystone's removal of paste *and*
> move to flask soon.
> 
> I can easily extract the bit of code I wrote to load our external
> middleware (and add an external loader) for the transition away from paste.
> 
> I also think paste is terrible, and would be willing to help folks move off
> of it rather than maintain it.
> 
> --Morgan
> 

Do I detect a volunteer to champion a cycle goal? :)


__
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

Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

[Morgan Fainberg]

Also, doesn't bitbucket have a git interface now too (optionally)?

On Mon, Oct 22, 2018, 07:49 Morgan Fainberg 
wrote:

> I should be able to do a write up for Keystone's removal of paste *and*
> move to flask soon.
>
> I can easily extract the bit of code I wrote to load our external
> middleware (and add an external loader) for the transition away from paste.
>
> I also think paste is terrible, and would be willing to help folks move
> off of it rather than maintain it.
>
> --Morgan
>
> On Mon, Oct 22, 2018, 07:38 Thomas Goirand  wrote:
>
>> On 10/22/18 12:55 PM, Chris Dent wrote:
>> >> My assumption is that it's "something we plan to minimally maintain
>> >> because we depend on it". in which case all options would work: the
>> >> exact choice depends on whether there is anybody interested in helping
>> >> maintaining it, and where those contributors prefer to do the work.
>> >
>> > Thus far I'm not hearing any volunteers. If that continues to be the
>> > case, I'll just keep it on bitbucket as that's the minimal change.
>>
>> Could you please move it to Github, so that at least, it's easier to
>> check out? Mercurial is always a pain...
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> __
>> 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
>>
>
__
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

Re: [openstack-dev] [Octavia] [Kolla] SSL errors polling amphorae and missing tenant network interface

[Erik McCormick]

Oops, dropped Operators. Can't wait until it's all one list...
On Mon, Oct 22, 2018 at 10:44 AM Erik McCormick
 wrote:
>
> On Mon, Oct 22, 2018 at 4:23 AM Tobias Urdin  wrote:
> >
> > Hello,
> >
> > I've been having a lot of issues with SSL certificates myself, on my
> > second trip now trying to get it working.
> >
> > Before I spent a lot of time walking through every line in the DevStack
> > plugin and fixing my config options, used the generate
> > script [1] and still it didn't work.
> >
> > When I got the "invalid padding" issue it was because of the DN I used
> > for the CA and the certificate IIRC.
> >
> >  > 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING
> > octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect
> > to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa
> > routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'),
> > ('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'),
> > ('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
> >  > 19:47 < tobias-urdin> after a quick google "The problem was that my
> > CA DN was the same as the certificate DN."
> >
> > IIRC I think that solved it, but then again I wouldn't remember fully
> > since I've been at so many different angles by now.
> >
> > Here is my IRC logs history from the #openstack-lbaas channel, perhaps
> > it can help you out
> > http://paste.openstack.org/show/732575/
> >
>
> Tobias, I owe you a beer. This was precisely the issue. I'm deploying
> Octavia with kolla-ansible. It only deploys a single CA. After hacking
> the templates and playbook to incorporate a separate server CA, the
> amphorae now load and provision the required namespace. I'm adding a
> kolla tag to the subject of this in hopes that someone might want to
> take on changing this behavior in the project. Hopefully after I get
> through Upstream Institute in Berlin I'll be able to do it myself if
> nobody else wants to do it.
>
> For certificate generation, I extracted the contents of
> octavia_certs_install.yml (which sets up the directory structure,
> openssl.cnf, and the client CA), and octavia_certs.yml (which creates
> the server CA and the client certificate) and mashed them into a
> separate playbook just for this purpose. At the end I get:
>
> ca_01.pem - Client CA Certificate
> ca_01.key - Client CA Key
> ca_server_01.pem - Server CA Certificate
> cakey.pem - Server CA Key
> client.pem - Concatenated Client Key and Certificate
>
> If it would help to have the playbook, I can stick it up on github
> with a huge "This is a hack" disclaimer on it.
>
> > -
> >
> > Sorry for hijacking the thread but I'm stuck as well.
> >
> > I've in the past tried to generate the certificates with [1] but now
> > moved on to using the openstack-ansible way of generating them [2]
> > with some modifications.
> >
> > Right now I'm just getting: Could not connect to instance. Retrying.:
> > SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
> > from the amphoras, haven't got any further but I've eliminated a lot of
> > stuck in the middle.
> >
> > Tried deploying Ocatavia on Ubuntu with python3 to just make sure there
> > wasn't an issue with CentOS and OpenSSL versions since it tends to lag
> > behind.
> > Checking the amphora with openssl s_client [3] it gives the same one,
> > but the verification is successful just that I don't understand what the
> > bad signature
> > part is about, from browsing some OpenSSL code it seems to be related to
> > RSA signatures somehow.
> >
> > 140038729774992:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad
> > signature:s3_clnt.c:2032:
> >
> > So I've basicly ruled out Ubuntu (openssl-1.1.0g) and CentOS
> > (openssl-1.0.2k) being the problem, ruled out signing_digest, so I'm
> > back to something related
> > to the certificates or the communication between the endpoints, or what
> > actually responds inside the amphora (gunicorn IIUC?). Based on the
> > "verify" functions actually causing that bad signature error I would
> > assume it's the generated certificate that the amphora presents that is
> > causing it.
> >
> > I'll have to continue the troubleshooting to the inside of the amphora,
> > I've used the test-only amphora image before but have now built my own
> > one that is
> > using the amphora-agent from the actual stable branch, but same issue
> > (bad signature).
> >
> > For verbosity this is the config options set for the certificates in
> > octavia.conf and which file it was copied from [4], same here, a
> > replication of what openstack-ansible does.
> >
> > Appreciate any feedback or help :)
> >
> > Best regards
> > Tobias
> >
> > [1]
> > https://github.com/openstack/octavia/blob/master/bin/create_certificates.sh
> > [2] http://paste.openstack.org/show/732483/
> > [3] http://paste.openstack.org/show/732486/
> > [4] http://paste.openstack.org/show/732487/
> >
> > On 10/20/2018 01:53 AM, Michael Johnson wrote:
> > > Hi Erik,
> > >
> > >

Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

[Morgan Fainberg]

I should be able to do a write up for Keystone's removal of paste *and*
move to flask soon.

I can easily extract the bit of code I wrote to load our external
middleware (and add an external loader) for the transition away from paste.

I also think paste is terrible, and would be willing to help folks move off
of it rather than maintain it.

--Morgan

On Mon, Oct 22, 2018, 07:38 Thomas Goirand  wrote:

> On 10/22/18 12:55 PM, Chris Dent wrote:
> >> My assumption is that it's "something we plan to minimally maintain
> >> because we depend on it". in which case all options would work: the
> >> exact choice depends on whether there is anybody interested in helping
> >> maintaining it, and where those contributors prefer to do the work.
> >
> > Thus far I'm not hearing any volunteers. If that continues to be the
> > case, I'll just keep it on bitbucket as that's the minimal change.
>
> Could you please move it to Github, so that at least, it's easier to
> check out? Mercurial is always a pain...
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> 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
>
__
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

Re: [openstack-dev] [Octavia] [Kolla] SSL errors polling amphorae and missing tenant network interface

[Erik McCormick]

On Mon, Oct 22, 2018 at 4:23 AM Tobias Urdin  wrote:
>
> Hello,
>
> I've been having a lot of issues with SSL certificates myself, on my
> second trip now trying to get it working.
>
> Before I spent a lot of time walking through every line in the DevStack
> plugin and fixing my config options, used the generate
> script [1] and still it didn't work.
>
> When I got the "invalid padding" issue it was because of the DN I used
> for the CA and the certificate IIRC.
>
>  > 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING
> octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect
> to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa
> routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'),
> ('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'),
> ('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
>  > 19:47 < tobias-urdin> after a quick google "The problem was that my
> CA DN was the same as the certificate DN."
>
> IIRC I think that solved it, but then again I wouldn't remember fully
> since I've been at so many different angles by now.
>
> Here is my IRC logs history from the #openstack-lbaas channel, perhaps
> it can help you out
> http://paste.openstack.org/show/732575/
>

Tobias, I owe you a beer. This was precisely the issue. I'm deploying
Octavia with kolla-ansible. It only deploys a single CA. After hacking
the templates and playbook to incorporate a separate server CA, the
amphorae now load and provision the required namespace. I'm adding a
kolla tag to the subject of this in hopes that someone might want to
take on changing this behavior in the project. Hopefully after I get
through Upstream Institute in Berlin I'll be able to do it myself if
nobody else wants to do it.

For certificate generation, I extracted the contents of
octavia_certs_install.yml (which sets up the directory structure,
openssl.cnf, and the client CA), and octavia_certs.yml (which creates
the server CA and the client certificate) and mashed them into a
separate playbook just for this purpose. At the end I get:

ca_01.pem - Client CA Certificate
ca_01.key - Client CA Key
ca_server_01.pem - Server CA Certificate
cakey.pem - Server CA Key
client.pem - Concatenated Client Key and Certificate

If it would help to have the playbook, I can stick it up on github
with a huge "This is a hack" disclaimer on it.

> -
>
> Sorry for hijacking the thread but I'm stuck as well.
>
> I've in the past tried to generate the certificates with [1] but now
> moved on to using the openstack-ansible way of generating them [2]
> with some modifications.
>
> Right now I'm just getting: Could not connect to instance. Retrying.:
> SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
> from the amphoras, haven't got any further but I've eliminated a lot of
> stuck in the middle.
>
> Tried deploying Ocatavia on Ubuntu with python3 to just make sure there
> wasn't an issue with CentOS and OpenSSL versions since it tends to lag
> behind.
> Checking the amphora with openssl s_client [3] it gives the same one,
> but the verification is successful just that I don't understand what the
> bad signature
> part is about, from browsing some OpenSSL code it seems to be related to
> RSA signatures somehow.
>
> 140038729774992:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad
> signature:s3_clnt.c:2032:
>
> So I've basicly ruled out Ubuntu (openssl-1.1.0g) and CentOS
> (openssl-1.0.2k) being the problem, ruled out signing_digest, so I'm
> back to something related
> to the certificates or the communication between the endpoints, or what
> actually responds inside the amphora (gunicorn IIUC?). Based on the
> "verify" functions actually causing that bad signature error I would
> assume it's the generated certificate that the amphora presents that is
> causing it.
>
> I'll have to continue the troubleshooting to the inside of the amphora,
> I've used the test-only amphora image before but have now built my own
> one that is
> using the amphora-agent from the actual stable branch, but same issue
> (bad signature).
>
> For verbosity this is the config options set for the certificates in
> octavia.conf and which file it was copied from [4], same here, a
> replication of what openstack-ansible does.
>
> Appreciate any feedback or help :)
>
> Best regards
> Tobias
>
> [1]
> https://github.com/openstack/octavia/blob/master/bin/create_certificates.sh
> [2] http://paste.openstack.org/show/732483/
> [3] http://paste.openstack.org/show/732486/
> [4] http://paste.openstack.org/show/732487/
>
> On 10/20/2018 01:53 AM, Michael Johnson wrote:
> > Hi Erik,
> >
> > Sorry to hear you are still having certificate issues.
> >
> > Issue #2 is probably caused by issue #1. Since we hot-plug the tenant
> > network for the VIP, one of the first steps after the worker connects
> > to the amphora agent is finishing the required configuration of the
> > VIP interface inside the network namespace on the amphroa.
>

Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

[Thomas Goirand]

On 10/22/18 12:55 PM, Chris Dent wrote:
>> My assumption is that it's "something we plan to minimally maintain
>> because we depend on it". in which case all options would work: the
>> exact choice depends on whether there is anybody interested in helping
>> maintaining it, and where those contributors prefer to do the work.
> 
> Thus far I'm not hearing any volunteers. If that continues to be the
> case, I'll just keep it on bitbucket as that's the minimal change.

Could you please move it to Github, so that at least, it's easier to
check out? Mercurial is always a pain...

Cheers,

Thomas Goirand (zigo)

__
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

Re: [openstack-dev] Proposal for a process to keep up with Python releases

[Thomas Goirand]

On 10/19/18 5:17 PM, Zane Bitter wrote:
> We have traditionally held to the principle that we want each release to
> support the latest release of CentOS and the latest LTS release of
> Ubuntu, as they existed at the beginning of the release cycle.[2]
> Currently this means in practice one version of py2 and one of py3, but
> in the future it will mean two, usually different, versions of py3.

That's not very nice to forget about the Debian case, which usually
closely precedes Ubuntu. If you want to support Ubuntu better, then
supporting Debian better helps. I usually get the issue before everyone,
as Sid is the distro which is updated the most often. Therefore, please
make sure to include Debian in your proposal.

> For unit tests, the most important thing is to test on the versions of
> Python we target. It's less important to be using the exact distro that
> we want to target, because unit tests generally won't interact with
> stuff outside of Python.

One of the reoccurring problem that I'm facing in Debian is that not
only Python 3 version is lagging behind, but OpenStack dependencies are
also lagging behind the distro. Often, the answer is "we don't support
this or that version of X", which of course is very frustrating. One
thing which would be super nice, would be a non-voting gate job that
test with the latest version of every Python dependencies as well, so we
get to see breakage early. We've stopped seeing them since we decided it
breaks too often and we would hide problems behind the
global-requirement thing.

And sometimes, we have weird interactions. For example, taskflow was
broken in Python 3.7 before this patch:
https://salsa.debian.org/openstack-team/libs/python-taskflow/commit/6a10261a8a147d901c07a6e7272dc75b9f4d0988

which broke multiple packages using it. Funny thing, it looks like it
wouldn't have happen if we didn't have a pre-version of Python 3.7.1 in
Sid, apparently. Anyway, this can happen again.

> So, for example, (and this is still under active debate) for Stein we
> might have gating jobs for py35 and py37, with a periodic job for py36.
> The T jobs might only have voting py36 and py37 jobs, but late in the T
> cycle we might add a non-voting py38 job on master so that people who
> haven't switched to the U template yet can see what, if anything,
> they'll need to fix.

This can only happen if we have supporting distribution packages for it.
IMO, this is a call for using Debian Testing or even Sid in the gate.

> We'll run the unit tests on any distro we can find that supports the
> version of Python we want. It could be a non-LTS Ubuntu, Fedora, Debian
> unstable, whatever it takes. We won't wait for an LTS Ubuntu to have a
> particular Python version before trying to test it.

I very much agree with that.

> Before the start of each cycle, the TC would determine which range of
> versions we want to support, on the basis of the latest one we can find
> in any distro and the earliest one we're likely to need in one of the
> supported Linux distros.

Release of Python aren't aligned with OpenStack cycles. Python 3.7
appeared late in the Rocky cycle. Therefore, unfortunately, doing what
you propose above doesn't address the issue.

> Integration Tests
> -
> 
> Integration tests do test, amongst other things, integration with
> non-openstack-supplied things in the distro, so it's important that we
> test on the actual distros we have identified as popular.[2] It's also
> important that every project be testing on the same distro at the end of
> a release, so we can be sure they all work together for users.

I find very disturbing to see the project only leaning toward these only
2 distributions. Why not SuSE & Debian?

Cheers,

Thomas Goirand (zigo)

__
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

Re: [openstack-dev] Proposal for a process to keep up with Python releases

[Corey Bryant]

On Fri, Oct 19, 2018 at 3:46 PM Zane Bitter  wrote:

> On 19/10/18 12:30 PM, Clark Boylan wrote:
> > On Fri, Oct 19, 2018, at 8:17 AM, Zane Bitter wrote:
> >> Unit Tests
> >> --
> >>
> >> For unit tests, the most important thing is to test on the versions of
> >> Python we target. It's less important to be using the exact distro that
> >> we want to target, because unit tests generally won't interact with
> >> stuff outside of Python.
> >>
> >> I'd like to propose that we handle this by setting up a unit test
> >> template in openstack-zuul-jobs for each release. So for Stein we'd have
> >> openstack-python3-stein-jobs. This template would contain:
> >
> > Because zuul config is branch specific we could set up every project to
> use a `openstack-python3-jobs` template then define that template
> differently on each branch. This would mean you only have to update the
> location where the template is defined and not need to update every other
> project after cutting a stable branch. I would suggest we take advantage of
> that to reduce churn.
>
> There was a reason I didn't propose that approach: in practice you can't
> add a new gating test to a centralised zuul template definition. If you
> do, many projects will break because the change is not self-testing. At
> best you'll be pitchforked by an angry mob of people who can't get
> anything but py37 fixes through the gate, and at worst they'll all stop
> using the template to get unblocked and then never go back to it.
>
> We don't need everyone to cut over at the same time. We just need them
> to do it in the space of one release cycle. One patch every 6 months is
> not an excessive amount of churn.
>
> >> * A voting gate job for the highest minor version of py3 we want to
> >> support in that release.
> >> * A voting gate job for the lowest minor version of py3 we want to
> >> support in that release.
> >> * A periodic job for any interim minor releases.
> >> * (Starting late in the cycle) a non-voting check job for the highest
> >> minor version of py3 we want to support in the *next* release (if
> >> different), on the master branch only.
> >>
> >> So, for example, (and this is still under active debate) for Stein we
> >> might have gating jobs for py35 and py37, with a periodic job for py36.
> >> The T jobs might only have voting py36 and py37 jobs, but late in the T
> >> cycle we might add a non-voting py38 job on master so that people who
> >> haven't switched to the U template yet can see what, if anything,
> >> they'll need to fix.
> >>
> >> We'll run the unit tests on any distro we can find that supports the
> >> version of Python we want. It could be a non-LTS Ubuntu, Fedora, Debian
> >> unstable, whatever it takes. We won't wait for an LTS Ubuntu to have a
> >> particular Python version before trying to test it.
> >>
> >> Before the start of each cycle, the TC would determine which range of
> >> versions we want to support, on the basis of the latest one we can find
> >> in any distro and the earliest one we're likely to need in one of the
> >> supported Linux distros. There will be a project-wide goal to switch the
> >> testing template from e.g. openstack-python3-stein-jobs to
> >> openstack-python3-treasure-jobs for every repo before the end of the
> >> cycle. We'll have goal champions as usual following up and helping teams
> >> with the process. We'll know where the problem areas are because we'll
> >> have added non-voting jobs for any new Python versions to the previous
> >> release's template.
> >
> > I don't know that this needs to be a project wide goal if you can just
> update the template on the master branch where the template is defined. Do
> that then every project is now running with the up to date version of the
> template. We should probably advertise when this is happening with some
> links to python version x.y breakages/features, but the process itself
> should be quick.
>
> Either way, it'll be project teams themselves fixing any broken tests
> due to a new version being added. So we can either have a formal
> project-wide goal where we project-manage that process across the space
> of a release, or a de-facto project-wide goal where we break everybody
> and then nothing gets merged until they fix it.
>
> > As for python version range selection I worry that that the criteria
> about relies on too much guesswork.
>
> Some guesswork is going to be inevitable, unfortunately, (we have no way
> of knowing what will be in CentOS 8, for example) but I agree that we
> should try to tighten up the criteria as much as possible.
>
> > I do think we should do our best to test future incoming versions of
> python even while not officially supporting them. We will have to support
> them at some point, either directly or via some later version that includes
> the changes from that intermediate version.
>
> +1, I think we should try to add support for higher versions as soon as
> possible. It may take a long time to get into an LTS

Re: [openstack-dev] [tripleo][ui][tempest][oooq] Refreshing plugins from git

[Chandan kumar]

Hello Honza,

On Thu, Oct 18, 2018 at 6:15 PM Bogdan Dobrelya  wrote:
>
> On 10/18/18 2:17 AM, Honza Pokorny wrote:
> > Hello folks,
> >
> > I'm working on the automated ui testing blueprint[1], and I think we
> > need to change the way we ship our tempest tests.
> >
> > Here is where things stand at the moment:
> >
> > * We have a kolla image for tempest
> > * This image contains the tempest rpm, and the openstack-tempest-all rpm
> > * The openstack-tempest-all package in turn contains all of the
> >openstack tempest plugins
> > * Each of the plugins is shipped as an rpm
> >
> > So, in order for a new test in tempest-tripleo-ui to appear in CI we
> > have to go through at least the following tests:
> >
> > * New tempest-tripleo-ui rpm
> > * New openstack-tempest-all rpm
> > * New tempest kolla image
> >
> > This could easily take a week, if not more.
> >
> > What I would like to build is something like the following:
> >
> > * Add an option to the tempest-setup.sh script in tripleo-quickstart to
> >refresh all tempest plugins from git before running any tests
> > * Optionally specify a zuul change for any of the plugins being
> >refreshed
> > * Hook up the test job to patches in tripleo-ui (which tests in
> >tempest-tripleo-ui are testing) so that I can run a fix and its test
> >in a single CI job

I have added a patch in TripleO Quickstart extras Validate-tempest
role: https://review.openstack.org/#/c/612377/ to install any tempest
plugin from git and zuul will pick
the specific change in the gates.
Here is the patch on how to test it with FS: https://review.openstack.org/612386
Basically in any FS, we can add following lines
tempest_format: venv
tempest_plugins_git:
   - 'https://git.openstack.org/openstack/tempest-tripleo-ui.git'
the respective FS related job will install the tempest plugin and we
can also use test_white_regex:  to
trigger the tempest tests.

I think it will solve the problem.

Thanks

Chandan Kumar

__
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

Re: [openstack-dev] [TripleO] easily identifying how services are configured

[Juan Antonio Osorio Robles]

On 10/19/18 8:04 PM, Alex Schultz wrote:
> On Fri, Oct 19, 2018 at 10:53 AM James Slagle  wrote:
>> On Wed, Oct 17, 2018 at 11:14 AM Alex Schultz  wrote:
>>> Additionally I took a stab at combining the puppet/docker service
>>> definitions for the aodh services in a similar structure to start
>>> reducing the overhead we've had from maintaining the docker/puppet
>>> implementations seperately.  You can see the patch
>>> https://review.openstack.org/#/c/611188/ for an additional example of
>>> this.
>> That patch takes the approach of removing baremetal support. Is that
>> what we agreed to do?
>>
> Since it's deprecated since Queens[0], yes? I think it is time to stop
> continuing this method of installation.  Given that I'm not even sure
> the upgrade process even works anymore with baremetal, I don't think
> there's a reason to keep it as it directly impacts the time it takes
> to perform deployments and also contributes to increased complexity
> all around.
>
> [0] 
> http://lists.openstack.org/pipermail/openstack-dev/2017-September/122248.html
As an advantage to removing baremetal support, our nested stack usage
would be a little lighter and this might actually help out deployment
times and resource usage. I like the idea of going ahead and starting to
flatten the stacks for our services.
>
>> I'm not specifically opposed, as I'm pretty sure the baremetal
>> implementations are no longer tested anywhere, but I know that Dan had
>> some concerns about that last time around.
>>
>> The alternative we discussed was using jinja2 to include common
>> data/tasks in both the puppet/docker/ansible implementations. That
>> would also result in reducing the number of Heat resources in these
>> stacks and hopefully reduce the amount of time it takes to
>> create/update the ServiceChain stacks.
>>
> I'd rather we officially get rid of the one of the two methods and
> converge on a single method without increasing the complexity via
> jinja to continue to support both. If there's an improvement to be had
> after we've converged on a single structure for including the base
> bits, maybe we could do that then?
>
> Thanks,
> -Alex
>
>> --
>> -- James Slagle
>> --
>>
>> __
>> 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
> __
> 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

__
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

Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer

[Brent Eagles]

+1

Cheers,
Brent

On Mon, Oct 22, 2018 at 7:06 AM Saravanan KR  wrote:

> +1
>
> Regards,
> Saravanan KR
> On Fri, Oct 19, 2018 at 5:53 PM Juan Antonio Osorio Robles
>  wrote:
> >
> > Hello!
> >
> >
> > I would like to propose Bob Fournier (bfournie) as a core reviewer in
> > TripleO. His patches and reviews have spanned quite a wide range in our
> > project, his reviews show great insight and quality and I think he would
> > be a addition to the core team.
> >
> > What do you folks think?
> >
> >
> > Best Regards
> >
> >
> >
> >
> __
> > 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
>
> __
> 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
>
__
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

Re: [openstack-dev] Proposal for a process to keep up with Python releases

[Chris Dent]

On Fri, 19 Oct 2018, Zane Bitter wrote:

Just to make it easier to visualise, here is an example for how the Zuul 
config _might_ look now if we had adopted this proposal during Rocky:


https://review.openstack.org/611947

And instead of having a project-wide goal in Stein to add 
`openstack-python36-jobs` to the list that currently includes 
`openstack-python35-jobs` in each project's Zuul config[1], we'd have had a 
goal to change `openstack-python3-rocky-jobs` to 
`openstack-python3-stein-jobs` in each project's Zuul config.


I like this, because it involves conscious actions, awareness and
self-testing by each project to move forward to a thing with a
reasonable name (the cycle name).

I don't think we should call that "churn". "Intention" might be a
better word.


--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [all] [tc] [api] Paste Maintenance

[Chris Dent]

On Fri, 19 Oct 2018, Thierry Carrez wrote:


Ed Leafe wrote:

On Oct 15, 2018, at 7:40 AM, Chris Dent  wrote:


I'd like some input from the community on how we'd like this to go.


I would say it depends on the long-term plans for paste. Are we planning on 
weaning ourselves off of paste, and simply need to maintain it until that 
can be completed, or are we planning on encouraging its use?


Agree with Ed... is this something we plan to minimally maintain because we 
depend on it, something that needs feature work and that we want to encourage 
the adoption of, or something that we want to keep on life-support while we 
move away from it?


That is indeed the question. I was rather hoping that some people
who are using paste (besides Keystone) would chime in here with what
they would like to do.

My preference would be that we immediately start moving away from it
and keep paste barely on life-support (a bit like WSME which I also
somehow managed to get involved with despite thinking it is horrible).

However, that's not easy to do because the paste.ini files have to
be considered config because of the way some projects and
deployments use them to drive custom middleware and the ordering of
middleware. So we're in for at least a year or so.

My assumption is that it's "something we plan to minimally maintain because 
we depend on it". in which case all options would work: the exact choice 
depends on whether there is anybody interested in helping maintaining it, and 
where those contributors prefer to do the work.


Thus far I'm not hearing any volunteers. If that continues to be the
case, I'll just keep it on bitbucket as that's the minimal change.

My concern with that is my aforementioned feelings of "it is
horrible". It might be better if someone who actually appreciates
Paste was involved as well.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer

[Saravanan KR]

+1

Regards,
Saravanan KR
On Fri, Oct 19, 2018 at 5:53 PM Juan Antonio Osorio Robles
 wrote:
>
> Hello!
>
>
> I would like to propose Bob Fournier (bfournie) as a core reviewer in
> TripleO. His patches and reviews have spanned quite a wide range in our
> project, his reviews show great insight and quality and I think he would
> be a addition to the core team.
>
> What do you folks think?
>
>
> Best Regards
>
>
>
> __
> 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

__
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

Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer

[Steven Hardy]

On Fri, Oct 19, 2018 at 1:24 PM Juan Antonio Osorio Robles
 wrote:
>
> Hello!
>
>
> I would like to propose Bob Fournier (bfournie) as a core reviewer in
> TripleO. His patches and reviews have spanned quite a wide range in our
> project, his reviews show great insight and quality and I think he would
> be a addition to the core team.
>
> What do you folks think?
+1!

__
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

Re: [openstack-dev] [Octavia] SSL errors polling amphorae and missing tenant network interface

[Tobias Urdin]

+operators

My bad.

On 10/22/2018 10:22 AM, Tobias Urdin wrote:

Hello,

I've been having a lot of issues with SSL certificates myself, on my
second trip now trying to get it working.

Before I spent a lot of time walking through every line in the DevStack
plugin and fixing my config options, used the generate
script [1] and still it didn't work.

When I got the "invalid padding" issue it was because of the DN I used
for the CA and the certificate IIRC.

  > 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect
to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa
routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'),
('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'),
('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
  > 19:47 < tobias-urdin> after a quick google "The problem was that my
CA DN was the same as the certificate DN."

IIRC I think that solved it, but then again I wouldn't remember fully
since I've been at so many different angles by now.

Here is my IRC logs history from the #openstack-lbaas channel, perhaps
it can help you out
http://paste.openstack.org/show/732575/

-

Sorry for hijacking the thread but I'm stuck as well.

I've in the past tried to generate the certificates with [1] but now
moved on to using the openstack-ansible way of generating them [2]
with some modifications.

Right now I'm just getting: Could not connect to instance. Retrying.:
SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
from the amphoras, haven't got any further but I've eliminated a lot of
stuck in the middle.

Tried deploying Ocatavia on Ubuntu with python3 to just make sure there
wasn't an issue with CentOS and OpenSSL versions since it tends to lag
behind.
Checking the amphora with openssl s_client [3] it gives the same one,
but the verification is successful just that I don't understand what the
bad signature
part is about, from browsing some OpenSSL code it seems to be related to
RSA signatures somehow.

140038729774992:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad
signature:s3_clnt.c:2032:

So I've basicly ruled out Ubuntu (openssl-1.1.0g) and CentOS
(openssl-1.0.2k) being the problem, ruled out signing_digest, so I'm
back to something related
to the certificates or the communication between the endpoints, or what
actually responds inside the amphora (gunicorn IIUC?). Based on the
"verify" functions actually causing that bad signature error I would
assume it's the generated certificate that the amphora presents that is
causing it.

I'll have to continue the troubleshooting to the inside of the amphora,
I've used the test-only amphora image before but have now built my own
one that is
using the amphora-agent from the actual stable branch, but same issue
(bad signature).

For verbosity this is the config options set for the certificates in
octavia.conf and which file it was copied from [4], same here, a
replication of what openstack-ansible does.

Appreciate any feedback or help :)

Best regards
Tobias

[1]
https://github.com/openstack/octavia/blob/master/bin/create_certificates.sh
[2] http://paste.openstack.org/show/732483/
[3] http://paste.openstack.org/show/732486/
[4] http://paste.openstack.org/show/732487/

On 10/20/2018 01:53 AM, Michael Johnson wrote:

Hi Erik,

Sorry to hear you are still having certificate issues.

Issue #2 is probably caused by issue #1. Since we hot-plug the tenant
network for the VIP, one of the first steps after the worker connects
to the amphora agent is finishing the required configuration of the
VIP interface inside the network namespace on the amphroa.

If I remember correctly, you are attempting to configure Octavia with
the dual CA option (which is good for non-development use).

This is what I have for notes:

[certificates] gets the following:
cert_generator = local_cert_generator
ca_certificate = server CA's "server.pem" file
ca_private_key = server CA's "server.key" file
ca_private_key_passphrase = pass phrase for ca_private_key
   [controller_worker]
   client_ca = Client CA's ca_cert file
   [haproxy_amphora]
client_cert = Client CA's client.pem file (I think with it's key
concatenated is what rm_work said the other day)
server_ca = Server CA's ca_cert file

That said, I can probably run through this and write something up next
week that is more step-by-step/detailed.

Michael

On Fri, Oct 19, 2018 at 2:31 PM Erik McCormick
 wrote:

Apologies for cross-posting, but in the event that these might be
worth filing as bugs, I wanted the Octavia devs to see it as well...

I've been wrestling with getting Octavia up and running and have
become stuck on two issues. I'm hoping someone has run into these
before. My google foo has come up empty.

Issue 1:
When the Octavia controller tries to poll the amphora instance, it
tries repeatedly and eventually fails. The error on the controller
side is:

2018-10-19 14:17:39.181 26 

Re: [openstack-dev] [tripleo] Proposing Bob Fournier as core reviewer

[Bogdan Dobrelya]

+1

On 10/19/18 3:44 PM, Alex Schultz wrote:

+1
On Fri, Oct 19, 2018 at 6:29 AM Emilien Macchi  wrote:


On Fri, Oct 19, 2018 at 8:24 AM Juan Antonio Osorio Robles 
 wrote:


I would like to propose Bob Fournier (bfournie) as a core reviewer in
TripleO. His patches and reviews have spanned quite a wide range in our
project, his reviews show great insight and quality and I think he would
be a addition to the core team.

What do you folks think?



Big +1, Bob is a solid contributor/reviewer. His area of knowledge has been 
critical in all aspects of Hardware Provisioning integration but also in other 
TripleO bits.
--
Emilien Macchi
__
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


__
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




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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

Re: [openstack-dev] [Octavia] SSL errors polling amphorae and missing tenant network interface

[Tobias Urdin]

Hello,

I've been having a lot of issues with SSL certificates myself, on my 
second trip now trying to get it working.


Before I spent a lot of time walking through every line in the DevStack 
plugin and fixing my config options, used the generate

script [1] and still it didn't work.

When I got the "invalid padding" issue it was because of the DN I used 
for the CA and the certificate IIRC.


> 19:34 < tobias-urdin> 2018-09-10 19:43:15.312 15032 WARNING 
octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect 
to instance. Retrying.: SSLError: ("bad handshake: Error([('rsa 
routines', 'RSA_padding_check_PKCS1_type_1', 'block type is not 01'), 
('rsa routines', 'RSA_EAY_PUBLIC_DECRYPT', 'padding check failed'), 
('SSL routines', 'ssl3_get_key_exchange', 'bad signature')],)",)
> 19:47 < tobias-urdin> after a quick google "The problem was that my 
CA DN was the same as the certificate DN."


IIRC I think that solved it, but then again I wouldn't remember fully 
since I've been at so many different angles by now.


Here is my IRC logs history from the #openstack-lbaas channel, perhaps 
it can help you out

http://paste.openstack.org/show/732575/

-

Sorry for hijacking the thread but I'm stuck as well.

I've in the past tried to generate the certificates with [1] but now 
moved on to using the openstack-ansible way of generating them [2]

with some modifications.

Right now I'm just getting: Could not connect to instance. Retrying.: 
SSLError: [SSL: BAD_SIGNATURE] bad signature (_ssl.c:579)
from the amphoras, haven't got any further but I've eliminated a lot of 
stuck in the middle.


Tried deploying Ocatavia on Ubuntu with python3 to just make sure there 
wasn't an issue with CentOS and OpenSSL versions since it tends to lag 
behind.
Checking the amphora with openssl s_client [3] it gives the same one, 
but the verification is successful just that I don't understand what the 
bad signature
part is about, from browsing some OpenSSL code it seems to be related to 
RSA signatures somehow.


140038729774992:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad 
signature:s3_clnt.c:2032:


So I've basicly ruled out Ubuntu (openssl-1.1.0g) and CentOS 
(openssl-1.0.2k) being the problem, ruled out signing_digest, so I'm 
back to something related
to the certificates or the communication between the endpoints, or what 
actually responds inside the amphora (gunicorn IIUC?). Based on the
"verify" functions actually causing that bad signature error I would 
assume it's the generated certificate that the amphora presents that is 
causing it.


I'll have to continue the troubleshooting to the inside of the amphora, 
I've used the test-only amphora image before but have now built my own 
one that is
using the amphora-agent from the actual stable branch, but same issue 
(bad signature).


For verbosity this is the config options set for the certificates in 
octavia.conf and which file it was copied from [4], same here, a 
replication of what openstack-ansible does.


Appreciate any feedback or help :)

Best regards
Tobias

[1] 
https://github.com/openstack/octavia/blob/master/bin/create_certificates.sh

[2] http://paste.openstack.org/show/732483/
[3] http://paste.openstack.org/show/732486/
[4] http://paste.openstack.org/show/732487/

On 10/20/2018 01:53 AM, Michael Johnson wrote:

Hi Erik,

Sorry to hear you are still having certificate issues.

Issue #2 is probably caused by issue #1. Since we hot-plug the tenant
network for the VIP, one of the first steps after the worker connects
to the amphora agent is finishing the required configuration of the
VIP interface inside the network namespace on the amphroa.

If I remember correctly, you are attempting to configure Octavia with
the dual CA option (which is good for non-development use).

This is what I have for notes:

[certificates] gets the following:
cert_generator = local_cert_generator
ca_certificate = server CA's "server.pem" file
ca_private_key = server CA's "server.key" file
ca_private_key_passphrase = pass phrase for ca_private_key
  [controller_worker]
  client_ca = Client CA's ca_cert file
  [haproxy_amphora]
client_cert = Client CA's client.pem file (I think with it's key
concatenated is what rm_work said the other day)
server_ca = Server CA's ca_cert file

That said, I can probably run through this and write something up next
week that is more step-by-step/detailed.

Michael

On Fri, Oct 19, 2018 at 2:31 PM Erik McCormick
 wrote:

Apologies for cross-posting, but in the event that these might be
worth filing as bugs, I wanted the Octavia devs to see it as well...

I've been wrestling with getting Octavia up and running and have
become stuck on two issues. I'm hoping someone has run into these
before. My google foo has come up empty.

Issue 1:
When the Octavia controller tries to poll the amphora instance, it
tries repeatedly and eventually fails. The error on the controller
side is:

2018-10-19 14:17:39.181 26 ERROR
octavia.amphorae.drive