Re: [openstack-dev] [octavia] haproxy fails to receive datagram

[Yipei Niu]

Hi, Adam,

The following details of my older amphora image are as follows.

+--+--+
| Property | Value|
+--+--+
| checksum | aa279b9ae1f265a232266e17ea04065c |
| container_format | bare |
| created_at   | 2017-07-24T10:46:34Z |
| disk_format  | qcow2|
| id   | 5d6d5f69-a4b1-440a-b6bb-10bf945e3f85 |
| min_disk | 0|
| min_ram  | 0|
| name | amphora-x64-haproxy  |
| owner| c4f8c2a8fadc4b7c915f299db95c88a8 |
| protected| False|
| size | 674900480|
| status   | active   |
| tags | ["amphora"]  |
| updated_at   | 2017-07-24T10:47:54Z |
| virtual_size | None |
| visibility   | public   |
+--+--+

It is created on 2017-07-24, while my latest one is created at 2017-09-28.

I installed octavia with devstack, but it doesn't work. I discussed the
issue with Michael, he cannot reproduce the error. Please refer to the
history mails here
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122814.html.
I can console in the amphora and trace the packet is received by my
amphora, but haproxy fails to respond. More details are here
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122587.html.
I think maybe there is something wrong with my latest amphora image, I
hence use an older amphora image in the latest environment, it works. As a
result, the networking are supposed to be fine. What do you think?

Best regards,
Yipei
__
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] [vitrage] No IRC meeting this week

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

The IRC meeting this week is canceled, as many Vitrage contributors will be on 
vacation.
Next week we will hold the Vitrage virtual PTG on Tue-Thu, October 17-19. More 
details can be found in the etherpad:
https://etherpad.openstack.org/p/vitrage-ptg-queens

Best Regards,
Ifat.

__
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] [packaging][all] Sample Config Files in setup.cfg

[Luigi Toscano]

On Saturday, 7 October 2017 12:30:54 CEST Thomas Goirand wrote:
> On 10/03/2017 03:07 PM, Luigi Toscano wrote:
> >> Why not? Simply because installing config files in /usr/etc is silly.
> >> The question would rather be: why not accepting the PBR patch...
> > 
> > It is silly, but again, people consuming from deb or RPM won't notice it.
> 
> Though people doing the packaging will suffer. Please don't throw the
> baby over the wall, and let's fix the issue.

This is an overstatement (proof below). Nothing is different for people doing 
the packaging.

For example, sahara have been installing those files for a long time under 
data_files, When the patch changed the location from /usr, I just changed the 
way those files are copied:
https://review.rdoproject.org/r/#/c/9722/
(this does not happen for Ubuntu and Debian packaging right now, so there are 
duplicated files).

This means that:
1) if the files are not installed through data_files, you have to manually 
copy them using the packaging script ;
2) if the files are installed using data_files, you either move them in the 
right position or delete that copy and still copy the proper files in the 
right place

You need to act anyway. So the 2 cases are not different, and point 2) is 
*already happening* for a long while. No change here.

The only difference is that when data_files installation is fixed, it would be 
fixed for everyone, and it's easier to track those file anyway.

> 
> > Sure, having the python tools install the files in the right directory is
> > the ideal final solution.
> 
> Let's get there then. In the mean while, don't break stuff.

Nothing is broken, see above.

> > My point is that the proposed solution is not worse than
> > the previous one and fixes at least one use case that was not previously
> > covered (the one that can be easily fixed).
> 
> You are proposing to induce pain to everyone doing packaging, just
> because it solves your developer pip use case. That's not what OpenStack
> used to do, and that's not fair. Let's fix things properly *first*
> please, maybe by discussing the PBR fix I linked to. Can we agree that
> this is the pragmatic easy (but maybe temporarily) way to fix the issue,
> even if it's not perfect and a setuptools fix would be better?

It does not, see above.


-- 
Luigi

__
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] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

[Flavio Percoco]

Greetings,

I've been working on something called triple-apbs (and it's respective roles) in
the last couple of months. You can find more info about this work here[0][1][2]

This work is at the point where I think it would be worth start discussing how
we want these repos to exist under the TripleO umbrella. As far as I can tell,
we have 2 options (please comment with alternatives if there are more):

1. A repo per role: Each role would have its own repo - this is the way I've
been developing it on Github. This model is closer to the ansible way of doing
things and it'll make it easier to bundle, ship, and collaborate on, individual
roles. Going this way would produce something similar to what the
openstack-ansible folks have.

2. Everything in a single repo: this would ease the import process and
integration with the rest of TripleO. It'll make the early days of this work a
bit easier but it will take us in a direction that doesn't serve one of the
goals of this work.

My preferred option is #1 because one of the goals of this work is to have
independent roles that can also be consumed standalone. In other words, I would
like to stay closer to the ansible recommended structure for roles. Some
examples[3][4]

Any thoughts? preferences?
Flavio

[0] http://blog.flaper87.com/deploy-mariadb-kubernetes-tripleo.html
[1] http://blog.flaper87.com/glance-keystone-mariadb-on-k8s-with-tripleo.html
[2] https://github.com/tripleo-apb
[3] https://github.com/tripleo-apb/ansible-role-k8s-mariadb
[4] https://github.com/tripleo-apb/ansible-role-k8s-glance

--
@flaper87
Flavio Percoco


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] [ironic][inspector] Virtual Queens PTG

[milanisko k]

Folks,

I'd like to gently remind You about the poll and to thank to those who
already voted!
Also I'd like to set the end-of-poll date to tomorrow, EOB.
In case You know someone who might like to join but is currently on PTO,
please let me know.

Cheers,
milan

pá 6. 10. 2017 v 13:40 odesílatel milanisko k  napsal:

> Folks,
>
> as there have been multiple questions about Inspector that I couldn't
> answer due to my PTG absence, I've decided to make it up to You and
> organise a virtual inspector-focused PTG call (over some BlueJeans or TBD).
>
> The other Inspector Cores gracefully agreed to. I've selected the times
> all of us were most comfortable with and would like to ask You to do the
> same[1].
>
> As far as the program is concerned, I've created an Etherpad with some
> bullets to base our discussion on[2], TL;DR of it being *current
> Inspector status on HA&DHCP filtering and plan on Ironic--Inspector merge*
> and picking action items.
>
> I'd like to kindly invite You, the Community, to participate.
>
> Best Regards,
> milan
>
> [1] https://doodle.com/poll/q7m4mnvv3h7k8eae
> [2] https://etherpad.openstack.org/p/inspector-queens-virtual-ptg
>
>
__
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] [packaging][all] Sample Config Files in setup.cfg

[Jesse Pretorius]

> From: James Page 

> 1) +1 for a consistent approach across projects - /usr/share/ sounds 
> like a sensible location - avoiding any complexity with managing changes made 
> by users in /etc/ for deploy from source use-cases, and allowing 
> packagers to know where to expect reference/sample config files to appear 
> during the package build-out/install process.

We have agreement from packagers for Ubuntu [1] and RDO [2] to include the 
files in the relative path /share. This seems to be the least offensive. 
OpenStack-Ansible supports the inclusion of the files, regardless of path [3].

There was acceptance of the /etc relative path from a SuSE packager [4]. Thomas 
Bechtold – could you comment on whether the relative path of /share is also 
good for SuSE packaging?

There has been an objection from the OpenStack package maintainer for Debian, 
but that objection has been to the use of the relative path of /etc. Thomas 
Goirand, could you please indicate whether you support the use of the relative 
path of /share given the currently available functionality in setuptools and 
pbr?

> 2) Looking at the Ubuntu packaging for OpenStack projects, we have quite a 
> few places where oslo-config-generator or oslo-policy-generator is used to 
> generate sample configuration files as part of the package build; I might 
> have missed it in my read through of this thread but it would be awesome if 
> those could be integrated as part of this process as well as the originating 
> project would then be able to provide some level for assurance to the content 
> of generated files in downstream distributions.

As mentioned in [4] these should be auto-generated. Some projects do this and 
submit samples into the repo from time to time, others have just left a stub 
with an explanation of how to generate it.

> I'd also be +1 on a packaging SIG; I don't think it will ever be a high 
> overhead SIG but it sounds like there are common challenges for deployment 
> projects and distributors which would benefit from shared focus.

I’m not in a position to set this up or run it, but would be happy to 
participate if someone is able to take ownership of it.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123235.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123294.html
[3] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123035.html
[4] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122843.html
[5] 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122825.html



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
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] [nova] otification update week 41

[Balazs Gibizer]

Hi,

Here is the status update / focus settings mail for w41.

Bugs

[Medium] https://bugs.launchpad.net/nova/+bug/1699115 api.fault
notification is never emitted
It seems that rackspace does not use api.fault notification [2][3] So 
the agreement seems to be to remove the dead code.

Patch is proposed and needs a second +2:
* https://review.openstack.org/#/c/505164/ Remove dead code of 
api.fault notification sending


[2] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-26.log.html#t2017-09-26T19:57:03
[3] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-09-27.log.html#t2017-09-27T08:30:57



[Undecided] https://bugs.launchpad.net/nova/+bug/1718226 bdm is 
wastefully loaded for versioned instance notifications
Patch series needs a second +2: 
https://review.openstack.org/#/q/topic:bug/1718226


[High] https://bugs.launchpad.net/nova/+bug/1706563
TestRPC.test_cleanup_notifier_null fails with timeou
[High] https://bugs.launchpad.net/nova/+bug/1685333 Fatal Python error:
Cannot recover from stack overflow. - in py35 unit test job
The first bug is just a duplicate of the second. It seems the TetRPC
test suite has a way to end up in an infinite recusion.
Two compeeting patches were proposed that might help us getting at 
least logs from the failing test cases but there is no decision which 
patch should be merged.

* https://review.openstack.org/#/c/507253/
* https://review.openstack.org/#/c/507239/

[Undecided] https://bugs.launchpad.net/nova/+bug/1721670 Build 
notification in conductor fails to send due to InstanceNotFound Edit

Patch has been proposed: https://review.openstack.org/#/c/509967/

[Undecided] https://bugs.launchpad.net/nova/+bug/1721843 Unversioned 
notifications not being sent
Regression in the legacy notifications introduced when the short 
cutting of the versioned notification payload generation was added. 
Only affects compute.instance.update legacy notification.



Versioned notification transformation
-
The interface.attach / detach notifications has been merged. \o/
Here are the 3 patches for this week:
* https://review.openstack.org/#/c/396210 Transform aggregate.add_host 
notification
* https://review.openstack.org/#/c/396211 Transform 
aggregate.remove_host notification
* https://review.openstack.org/#/c/443764 use context mgr in 
instance.delete


Just a reminder that the versioned notification burndown chart is 
available on a new address: 
http://burndown.peermore.com/nova-notification/



Small improvements
--

* https://review.openstack.org/#/q/topic:refactor-notification-samples
Factor out duplicated notification sample data
This is a start of a longer patch series to deduplicate notification
sample data.
Takashi pointed out in the review that the current proposal actually 
changes the content of the sample appearing in our documentations. The 
reason is that some fields of the common sample fragment is overridden 
only during the functional test run and not during the doc generation. 
We agreed with Matt to try to make the override in a more clever way 
that applies to both the functional test and the doc generation.

The series needs to be updated.

Weekly meeting
--
Next subteam meeting will be held on 10th of October, Tuesday 17:00 UTC 
on openstack-meeting-4.

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171010T17


Cheers,
gibi




__
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] [packaging][all] Sample Config Files in setup.cfg

[Thomas Bechtold]

Hi,

On 09.10.2017 12:36, Jesse Pretorius wrote:
[...]
We have agreement from packagers for Ubuntu [1] and RDO [2] to include 
the files in the relative path /share. This seems to be the least 
offensive. OpenStack-Ansible supports the inclusion of the files, 
regardless of path [3].


There was acceptance of the /etc relative path from a SuSE packager [4]. 
Thomas Bechtold – could you comment on whether the relative path of 
/share is also good for SuSE packaging?


Works for me.


Tom

__
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] FW: [vitrage]Vitrage Devstack on master

[Afek, Ifat (Nokia - IL/Kfar Sava)]

From: "Hefetz, Idan (Nokia - IL/Kfar Sava)" 


Hi,
To use Vitrage Devstack on master, please notice that after this 
commit, a few steps are required:


  1.  Add the following to  /etc/vitrage/vitrage.conf
[database]
connection = mysql+pymysql://root:password@127.0.0.1/vitrage?charset=utf8


  1.  Add the following to /opt/stack/vitrage/vitrage.egg-info/entry_points.txt
[vitrage.storage]
mysql = vitrage.storage.impl_sqlalchemy:Connection
mysql+pymysql = vitrage.storage.impl_sqlalchemy:Connection
postgresql = vitrage.storage.impl_sqlalchemy:Connection
sqlite = vitrage.storage.impl_sqlalchemy:Connection


  1.  Run ‘sudo service apache2 restart’
  2.  Run ‘sudo service devstack@vitrage-graph restart’

Another option is to recreate the stack using stack.sh.

Thanks,
Idan hefetz.
__
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] [ptls] Sydney Forum Project Onboarding Rooms

[Flavio Percoco]

On 06/10/17 07:31 -0700, Emilien Macchi wrote:

On Thu, Oct 5, 2017 at 8:50 AM, Kendall Nelson  wrote:
[...]

If you are interested in reserving a spot, just reply directly to me and I
will put your project on the list. Please let me know if you want one and
also include the names and emails anyone that will be speaking with you.


TripleO - Emilien Macchi - emil...@redhat.com


I'll help here if needed :)
Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] [tc][election] TC candidacy

[Colleen Murphy]

I'd like to submit my candidacy for a position on the OpenStack TC.

I work at SUSE as a Cloud Developer. I have been involved with OpenStack for
three years, first as a contributor to the Puppet-OpenStack team, then with
the
Infra team, and now as a core reviewer for keystone.

>From the beginning I have had a keen interest in onboarding new
contributors and
guiding them to be productive community members. Growing our community
following our recent drop in contributors is one of our biggest challenges.
I also see diversifying our community as intertwined with attracting and
onboarding new members. I have always been impressed with OpenStack's
welcoming
community and inclusivity, but the numbers show that we could be doing
better
on gender diversity[1] and I believe we must continue to build up momentum
in
improving cultural inclusivity.

My work in OpenStack has given me with an understanding of the needs of
operators and deployment tool teams and a desire to support those needs.
Admitting deployment tools into the Big Tent was a great step in closing the
communication gap between core projects and deployers and ultimately lead
to an
improvement in the user experience for operators. Continuing this pattern of
inter-group collaboration is fundamental to making OpenStack better.

I care a lot about OpenStack and I'd like to contribute to its overall
health
and success in any way that I can, and I see serving on the TC as an
excellent
way to do that. Thank you for your consideration.

Colleen Murphy (cmurphy)
https://www.openstack.org/community/members/profile/11727/colleen-murphy
http://stackalytics.com/?release=all&user_id=krinkle

[1] http://superuser.openstack.org/articles/bitergia-intel-report/
__
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] [tc][election] TC candidacy

[Ildiko Vancsa]

Hi All,

I would like to announce my candidacy for a seat on the OpenStack Technical
Committee for the upcoming year.

I'm working for the OpenStack Foundation as Ecosystem Technical Lead where
my responsibility is to help our members to succeed with OpenStack both as
software and community. My main focus areas are Telecom/NFV, on boarding
and collaboration with adjacent communities.

I joined the community nearly four years ago. By my contributions I’m the 
constant
voice of usability and maintainability aspects while encouraging collaboration 
within
and between project teams.

During the past few years I’ve been leading the activities to add the Cinder 
volume
multi-attach functionality to Nova, which turned into a collaborative activity 
between
the two teams to simplify the interaction between the two services [1]. By this 
work
we are increasing maintainability of the code bases and stability of the 
services.
Driven by the experiences of this work I see cross-project collaboration as an 
area
to further improve. As part of the TC I would like to continue driving 
cross-project
activities, where I would like to help with making the interactions between the 
teams
more efficient to ensure end-to-end feature implementation and continuous code
maintenance and improvement.

I’m one of the drivers of the Upstream Institute activities to provide guidance 
to
newcomers to the community. As our community is a continuously changing
environment it is crucial to be welcoming and ensure we distribute the knowledge
about our processes and code base while remaining open to transfer 
responsibilities
to newer community members. As a TC member I would like to help the project
teams to share and maintain this mindset to help the contributor ecosystem to
remain healthy and balanced and our teams to become more efficient.

In the course of my current role within the Foundation I continuously learn 
about the
goals and challenges of our ecosystem companies who are productifying, 
distributing
and operating OpenStack. It is very important to keep a close feedback loop 
between
our users, operators and developers in order to define our focus and priorities 
to features
requests and issues that are in high demand. At the same time it is also 
crucial to keep
OpenStack an innovative environment which is open to explore new emerging 
technologies
and also integrates well with other communities in the ecosystem. If I get 
elected to the
TC I would like to help collaborating with organizations on different fields, 
from
standardization (i.e. ETSI NFV) through SDN/NFV (i.e. OPNFV) to the research and
scientific area.

As an example I’ve been involved in OPNFV [2] for about two and a half years 
and I’m
also one of their ambassadors [3]. I’m continuously working on to find the 
connection
points between the two communities [4] to build a large ecosystem which fits 
OpenStack's
current priorities in the sense of actively supporting and being the foundation 
for NFV. As
part of the TC I would like to continue to help the ongoing joint activities to 
create
an interoperability test suite for the NFV area and have OPNFV’s CI system 
integrated
with OpenStack to get close to immediate feedback while developing new Telecom
and NFV related features. As the adoption of OpenStack in the Telecom area is
continuously growing and operators are looking at OpenStack as a main building
block for their systems, I would like to serve as a representative in the 
technical
driving force of OpenStack, who can operate as a translator to build a common
roadmap.

Last but not least, I would like to increase diversity in the TC, but more 
importantly
my goal is to add fresh blood to the group driving this community. In my
opinion it is crucial to constantly revisit items from a different perspective 
and
let new voices articulate their views and ideas in order to see the big 
picture. Long
term this can ensure that OpenStack keeps its adaptability to continue to be a
smoothly functioning ecosystem providing a stable, successful and continuously
evolving software package.

Thank you for reading through my thoughts. It is an honor to be part of 
OpenStack,
which is why I would like to take part in helping to further the efforts of 
providing a
package that can serve the whole industry and which is backed up by a growing
and smoothly functioning ecosystem.

Thank you for your consideration.

Best Regards,
Ildikó (ildikov)

[1] http://stackalytics.com/?release=all&user_id=ildiko-vancsa&metric=person-day
[2] https://www.opnfv.org
[3] https://www.opnfv.org/community/ambassadors
[4] https://www.openstack.org/summit/austin-2016/summit-schedule/events/7510


__
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] [tc][election] TC candidacy

[Nicolas Bock]

On Mon, Oct 09, 2017 at 02:53:27PM +0200, Colleen Murphy wrote:

I'd like to submit my candidacy for a position on the OpenStack TC.


+1 !!

I think Collen would be an an excellent addition to the TC!


I work at SUSE as a Cloud Developer. I have been involved with OpenStack for
three years, first as a contributor to the Puppet-OpenStack team, then with
the
Infra team, and now as a core reviewer for keystone.

From the beginning I have had a keen interest in onboarding new
contributors and
guiding them to be productive community members. Growing our community
following our recent drop in contributors is one of our biggest challenges.
I also see diversifying our community as intertwined with attracting and
onboarding new members. I have always been impressed with OpenStack's
welcoming
community and inclusivity, but the numbers show that we could be doing
better
on gender diversity[1] and I believe we must continue to build up momentum
in
improving cultural inclusivity.

My work in OpenStack has given me with an understanding of the needs of
operators and deployment tool teams and a desire to support those needs.
Admitting deployment tools into the Big Tent was a great step in closing the
communication gap between core projects and deployers and ultimately lead
to an
improvement in the user experience for operators. Continuing this pattern of
inter-group collaboration is fundamental to making OpenStack better.

I care a lot about OpenStack and I'd like to contribute to its overall
health
and success in any way that I can, and I see serving on the TC as an
excellent
way to do that. Thank you for your consideration.

Colleen Murphy (cmurphy)
https://www.openstack.org/community/members/profile/11727/colleen-murphy
http://stackalytics.com/?release=all&user_id=krinkle

[1] http://superuser.openstack.org/articles/bitergia-intel-report/



__
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] [packaging][all] Sample Config Files in setup.cfg

[Thomas Goirand]

On 10/06/2017 10:23 AM, James Page wrote:
> On Tue, 3 Oct 2017 at 18:15 Doug Hellmann  > wrote:
> 
> Excerpts from Jesse Pretorius's message of 2017-10-03 15:57:17 +:
> > On 10/3/17, 3:01 PM, "Doug Hellmann"  > wrote:
> >
> > >> Given that this topic has gone through several cycles of
> discussion and has never gone anywhere, does it perhaps merit
> definition as a project interface so that we can define the problem
> this is trying to solve and set a standard formally once and for all?
> >
> > >    Maybe a couple of the various packaging projects can agree
> and just
> > >    set a de facto rule (and document it). That worked out OK for us
> > >    with the doc reorganization when we updated the docs.o.o site
> > >    templates.
> >
> > I’m happy to facilitate that. Is there some sort of place where
> such standards are recorded? Ie Where do I submit a review to and is
> there an example to reference for the sort of information that
> should be in it?
> >
> 
> The docs team put that info in the spec for the migration. Do we
> have a packaging SIG yet? That seems like an ideal body to own a
> standard like this long term. Short term, just getting some agreement
> on the mailing list would be a good start.
> 
> 
> Bah - missed the start of this thread but here's my tuppence
> 
> 1) +1 for a consistent approach across projects - /usr/share/
> sounds like a sensible location - avoiding any complexity with managing
> changes made by users in /etc/ for deploy from source
> use-cases, and allowing packagers to know where to expect
> reference/sample config files to appear during the package
> build-out/install process.

The /usr/share/ issue is, in Debian, it goes most of the time
in /usr/share/-common. For example for nova, it goes in:

/usr/share/nova-common/nova.conf

and then this file is copied in the postinst to /etc/nova. The reason is
we want /etc/nova to be accessible from the nova user only (ie: not
accessible system wide) because of security issues. And the only way to
do that, is to dynamically copy the file to /etc/nova after the nova
system user is created.

So yeah, you can push files in /usr/share/nova, but then we'll have to
actually *delete* them in the packaging, because it doesn't fit our use
case. So in fact, best would be if this could be overridden, for example
using an environment variable. Something like:

export OSLO_CONFIG_FILE_DEST=/usr/share/nova-common

This way, I wouldn't have to manually move/copy/delete/regenerate config
files by hand in debian/rules.

I hope this helps,
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] [tripleo] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

[Jiří Stránský]

On 9.10.2017 11:29, Flavio Percoco wrote:

Greetings,

I've been working on something called triple-apbs (and it's respective roles) in
the last couple of months. You can find more info about this work here[0][1][2]

This work is at the point where I think it would be worth start discussing how
we want these repos to exist under the TripleO umbrella. As far as I can tell,
we have 2 options (please comment with alternatives if there are more):

1. A repo per role: Each role would have its own repo - this is the way I've
been developing it on Github. This model is closer to the ansible way of doing
things and it'll make it easier to bundle, ship, and collaborate on, individual
roles. Going this way would produce something similar to what the
openstack-ansible folks have.

2. Everything in a single repo: this would ease the import process and
integration with the rest of TripleO. It'll make the early days of this work a
bit easier but it will take us in a direction that doesn't serve one of the
goals of this work.

My preferred option is #1 because one of the goals of this work is to have
independent roles that can also be consumed standalone. In other words, I would
like to stay closer to the ansible recommended structure for roles. Some
examples[3][4]

Any thoughts? preferences?


+1 for option #1. In addition to standalone usage, it feels like a 
better match for "the container way of doing things" in that we'll be 
able to easily mix and match APB versions when necessary. (E.g. having 
problems with bleeding edge Glance APB? Just use a slightly older one 
without being compelled to downgrade the other APBs.) A parallel could 
be drawn to how openstack/puppet-* repos are managed and IMO it's been 
working well that way.


Using APBs this way also seems more "out-of-the-box ready" for APBs that 
don't originate in TripleO project, should we ever want/need to use them 
(e.g. for non-OpenStack services).


Global changes will be harder as they'll require separate commits, and 
in general it's more repos (+ RPMs) to manage, but i hope the 
aforementioned benefits outweigh this.


Jirka


Flavio

[0] http://blog.flaper87.com/deploy-mariadb-kubernetes-tripleo.html
[1] http://blog.flaper87.com/glance-keystone-mariadb-on-k8s-with-tripleo.html
[2] https://github.com/tripleo-apb
[3] https://github.com/tripleo-apb/ansible-role-k8s-mariadb
[4] https://github.com/tripleo-apb/ansible-role-k8s-glance

--
@flaper87
Flavio Percoco



__
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-dev] [tc][election] TD candidacy (mnaser)

[Mohammed Naser]

Dear OpenStack users and developers,

I'm submitting my candidacy for a position in the OpenStack TC.

I believe that being involved in many facets surrounding OpenStack makes me
a good candidate to be a member of the technical commitee.

On one of the most important sides, the community:  I have spoken to countless
users, potential users of OpenStack and continue to have conversations about
why users choose OpenStack and the reason why they do not want to use it.  I
think having this external feedback is extremely beneficial in order to take
the best decisions, as those users are impacted by our very decisions.

At the same time, thinking about developers who work hard on our community
to produce the awesome technology we work on:  I have personally been one of
them and continue to be one of them.  I have started contributing to OpenStack
since 2011 across many projects and I am the current PTL for the Puppet
OpenStack team.  In addition, I continue to assist and fix any issues that I
see at hand, helping out the infrastructure team when needed as well.

Finally, one of the critical points is deployers:  I have architected, operated
and deployed our public cloud with OpenStack since 2011, in addition to many
other private cloud deployments.  Our public cloud has a long history, having
started it's life early and undergone many upgrades.  I have personally
overseen all those upgrades and brought feedback directly back to projects
as well as including bug fixes for the projects.

I believe strong leadership comes from setting an example.  With the involvement
in the community, working with the developers and being a deployer myself that
contributes back, I believe that it puts me in a unique position to understand
many parts of the equation that helps us take the best decisions in order to
have a sustainable technical future for the OpenStack projects.

I strongly believe that we have the most solid fundamental infrastructure
software at the moment.  However, I think that the focus should increase in
working with other external communities which depend on infrastructure to
increase our implementations.  For example, working with Kubernetes in order
to strengthen the cloud providers and perhaps get even more integration features
such as auto-scaling.  This will solidify OpenStack as the best set of
infrastructure services in the market.

In addition, I believe that we should put more effort and try to encourage
more work on projects which abstract existing complicated software into a
service.  The few projects that come into mind are Magnum (deploying container
orchestration services) and Sahara (big data platforms).  Those projects can
help make OpenStack a single centralized unit where users can get infrastructure
but easy access to services, on-demand, built with best practices and integrated
with the external tools as explained in the paragraph above.

For me, OpenStack is a wonderful community filled with awesome people who are
all extremely supportive of each other and work together.  I am extremely
proud to be part of this wonderful community and I hope that by becoming an
elected TC, I can help the success of all OpenStack projects from my experience.

Thank you very much for taking the time to read this and I wish the best of
luck to all other candidates.

Regards,
Mohammed Naser

__
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] [tripleo] Looking for help in properly configuring a TripleO environment

[Mark Hamzy]

I am looking for help in properly configuring a TripleO environment on a 
machine with two network cards talking to two baremetal nodes in the 
overcloud also with two network cards.  One network will be for 
provisioning and one will be for internet connection.  I have documented 
my current configuration at:

https://fedoraproject.org/wiki/User:Hamzy/TripleO_mixed_undercloud_overcloud_try8


2017-09-23 23:54:49Z [overcloud.ControllerAllNodesValidationDeployment.0]: 
CREATE_COMPLETE  state changed
2017-09-23 23:54:49Z [overcloud.ControllerAllNodesValidationDeployment]: 
CREATE_COMPLETE  Stack CREATE completed successfully
2017-09-23 23:54:49Z [overcloud.ControllerAllNodesValidationDeployment]: 
CREATE_COMPLETE  state changed
2017-09-24 00:05:06Z [overcloud.ComputeAllNodesValidationDeployment.0]: 
SIGNAL_IN_PROGRESS  Signal: deployment d54b96a6-1860-4802-a$
45-db4ece0317e4 failed (1)
2017-09-24 00:05:06Z [overcloud.ComputeAllNodesValidationDeployment.0]: 
CREATE_FAILED  Error: resources[0]: Deployment to server fa$led: 
deploy_status_code : Deployment exited with non-zero status code: 1
2017-09-24 00:05:06Z [overcloud.ComputeAllNodesValidationDeployment]: 
CREATE_FAILED  Resource CREATE failed: Error: resources[0]: D$ployment to 
server failed: deploy_status_code : Deployment exited with non-zero status 
code: 1
2017-09-24 00:05:07Z [overcloud.ComputeAllNodesValidationDeployment]: 
CREATE_FAILED  Error: 
resources.ComputeAllNodesValidationDepl$yment.resources[0]: Deployment to 
server failed: deploy_status_code: Deployment exited with non-zero status 
code: 1
2017-09-24 00:05:07Z [overcloud]: CREATE_FAILED  Resource CREATE failed: 
Error: resources.ComputeAllNodesValidationDeployment.resou$ces[0]: 
Deployment to server failed: deploy_status_code: Deployment exited with 
non-zero status code: 1

 Stack overcloud CREATE_FAILED 

overcloud.ComputeAllNodesValidationDeployment.0:
  resource_type: OS::Heat::StructuredDeployment
  physical_resource_id: d54b96a6-1860-4802-ad45-db4ece0317e4
  status: CREATE_FAILED
  status_reason: |
Error: resources[0]: Deployment to server failed: deploy_status_code : 
Deployment exited with non-zero status code: 1
  deploy_stdout: |
...
Ping to 172.16.0.14 failed. Retrying...
Ping to 172.16.0.14 failed. Retrying...
Ping to 172.16.0.14 failed. Retrying...
Ping to 172.16.0.14 failed. Retrying...
Ping to 172.16.0.14 failed. Retrying...
Ping to 172.16.0.14 failed. Retrying...
Ping to 172.16.0.14 failed. Retrying...
Ping to 172.16.0.14 failed. Retrying...
Ping to 172.16.0.14 failed. Retrying...
FAILURE
(truncated, view all with --long)
  deploy_stderr: |
172.16.0.14 is not pingable. Local Network: 172.16.0.0/24

Burried somewhat in that URL was the following way to view my templates:

cp -r /usr/share/openstack-tripleo-heat-templates templates
(cd templates/; wget --quiet -O - 
https://hamzy.fedorapeople.org/openstack-tripleo-heat-templates.patch | 
patch -p1)

The controller and compute do install and get IP address from DHCP:

[hamzy@overcloud-controller-0 ~]$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enP1p3s0f0:  mtu 1500 qdisc mq 
portid 98be9454b240 state DOWN qlen 1000
link/ether 98:be:94:54:b2:40 brd ff:ff:ff:ff:ff:ff
3: enP1p3s0f1:  mtu 1500 qdisc mq 
portid 98be9454b242 state DOWN qlen 1000
link/ether 98:be:94:54:b2:42 brd ff:ff:ff:ff:ff:ff
4: enP1p5s0f0:  mtu 1500 qdisc mq 
portid 98be94546360 state DOWN qlen 1000
link/ether 98:be:94:54:63:60 brd ff:ff:ff:ff:ff:ff
5: enP1p5s0f1:  mtu 1500 qdisc mq 
portid 98be94546362 state DOWN qlen 1000
link/ether 98:be:94:54:63:62 brd ff:ff:ff:ff:ff:ff
6: enP3p11s0f0:  mtu 1500 qdisc mq 
portid 40f2e9316940 state DOWN qlen 1000
link/ether 40:f2:e9:31:69:40 brd ff:ff:ff:ff:ff:ff
7: enP3p11s0f1:  mtu 1500 qdisc mq 
portid 40f2e9316942 state DOWN qlen 1000
link/ether 40:f2:e9:31:69:42 brd ff:ff:ff:ff:ff:ff
8: enP6p1s0f0:  mtu 1500 qdisc mq 
portid 98be94541f80 state DOWN qlen 1000
link/ether 98:be:94:54:1f:80 brd ff:ff:ff:ff:ff:ff
9: enP6p1s0f1:  mtu 1500 qdisc mq 
portid 98be94541f82 state DOWN qlen 1000
link/ether 98:be:94:54:1f:82 brd ff:ff:ff:ff:ff:ff
10: enP3p5s0f0:  mtu 1500 qdisc mq 
portid 01304534323130363730453131 state DOWN qlen 1000
link/ether 00:90:fa:74:05:50 brd ff:ff:ff:ff:ff:ff
11: enP3p5s0f1:  mtu 1500 qdisc mq 
portid 02304534323130363730453131 state DOWN qlen 1000
link/ether 00:90:fa:74:05:51 brd ff:ff:ff:ff:ff:ff
12: enP3p5s0f2:  mtu 1500 qdisc mq master 
ovs-system portid 03304534323130363730453131 state UP qlen 1000
link/ether 00:90:fa:74:05:52 brd ff:ff:ff:ff:ff:ff
inet6 fe80::290:faff:fe74:552/64 scope link 
   valid_lft forever preferred_lft forever
13: e

Re: [openstack-dev] [tripleo] Looking for help in properly configuring a TripleO environment

[Joe Talerico]

If you ssh to your compute node can you ping 172.16.0.14?

On Mon, Oct 9, 2017 at 11:54 AM, Mark Hamzy  wrote:
> I am looking for help in properly configuring a TripleO environment on a
> machine with two network cards talking to two baremetal nodes in the
> overcloud also with two network cards.  One network will be for provisioning
> and one will be for internet connection.  I have documented my current
> configuration at:
>
> https://fedoraproject.org/wiki/User:Hamzy/TripleO_mixed_undercloud_overcloud_try8
>
>
> 2017-09-23 23:54:49Z [overcloud.ControllerAllNodesValidationDeployment.0]:
> CREATE_COMPLETE  state changed
> 2017-09-23 23:54:49Z [overcloud.ControllerAllNodesValidationDeployment]:
> CREATE_COMPLETE  Stack CREATE completed successfully
> 2017-09-23 23:54:49Z [overcloud.ControllerAllNodesValidationDeployment]:
> CREATE_COMPLETE  state changed
> 2017-09-24 00:05:06Z [overcloud.ComputeAllNodesValidationDeployment.0]:
> SIGNAL_IN_PROGRESS  Signal: deployment d54b96a6-1860-4802-a$
> 45-db4ece0317e4 failed (1)
> 2017-09-24 00:05:06Z [overcloud.ComputeAllNodesValidationDeployment.0]:
> CREATE_FAILED  Error: resources[0]: Deployment to server fa$led:
> deploy_status_code : Deployment exited with non-zero status code: 1
> 2017-09-24 00:05:06Z [overcloud.ComputeAllNodesValidationDeployment]:
> CREATE_FAILED  Resource CREATE failed: Error: resources[0]: D$ployment to
> server failed: deploy_status_code : Deployment exited with non-zero status
> code: 1
> 2017-09-24 00:05:07Z [overcloud.ComputeAllNodesValidationDeployment]:
> CREATE_FAILED  Error:
> resources.ComputeAllNodesValidationDepl$yment.resources[0]: Deployment to
> server failed: deploy_status_code: Deployment exited with non-zero status
> code: 1
> 2017-09-24 00:05:07Z [overcloud]: CREATE_FAILED  Resource CREATE failed:
> Error: resources.ComputeAllNodesValidationDeployment.resou$ces[0]:
> Deployment to server failed: deploy_status_code: Deployment exited with
> non-zero status code: 1
>
>  Stack overcloud CREATE_FAILED
>
> overcloud.ComputeAllNodesValidationDeployment.0:
>   resource_type: OS::Heat::StructuredDeployment
>   physical_resource_id: d54b96a6-1860-4802-ad45-db4ece0317e4
>   status: CREATE_FAILED
>   status_reason: |
> Error: resources[0]: Deployment to server failed: deploy_status_code :
> Deployment exited with non-zero status code: 1
>   deploy_stdout: |
> ...
> Ping to 172.16.0.14 failed. Retrying...
> Ping to 172.16.0.14 failed. Retrying...
> Ping to 172.16.0.14 failed. Retrying...
> Ping to 172.16.0.14 failed. Retrying...
> Ping to 172.16.0.14 failed. Retrying...
> Ping to 172.16.0.14 failed. Retrying...
> Ping to 172.16.0.14 failed. Retrying...
> Ping to 172.16.0.14 failed. Retrying...
> Ping to 172.16.0.14 failed. Retrying...
> FAILURE
> (truncated, view all with --long)
>   deploy_stderr: |
> 172.16.0.14 is not pingable. Local Network: 172.16.0.0/24
>
> Burried somewhat in that URL was the following way to view my templates:
>
> cp -r /usr/share/openstack-tripleo-heat-templates templates
> (cd templates/; wget --quiet -O -
> https://hamzy.fedorapeople.org/openstack-tripleo-heat-templates.patch| patch
> -p1)
>
> The controller and compute do install and get IP address from DHCP:
>
> [hamzy@overcloud-controller-0 ~]$ ip a
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: enP1p3s0f0:  mtu 1500 qdisc mq portid
> 98be9454b240 state DOWN qlen 1000
> link/ether 98:be:94:54:b2:40 brd ff:ff:ff:ff:ff:ff
> 3: enP1p3s0f1:  mtu 1500 qdisc mq portid
> 98be9454b242 state DOWN qlen 1000
> link/ether 98:be:94:54:b2:42 brd ff:ff:ff:ff:ff:ff
> 4: enP1p5s0f0:  mtu 1500 qdisc mq portid
> 98be94546360 state DOWN qlen 1000
> link/ether 98:be:94:54:63:60 brd ff:ff:ff:ff:ff:ff
> 5: enP1p5s0f1:  mtu 1500 qdisc mq portid
> 98be94546362 state DOWN qlen 1000
> link/ether 98:be:94:54:63:62 brd ff:ff:ff:ff:ff:ff
> 6: enP3p11s0f0:  mtu 1500 qdisc mq portid
> 40f2e9316940 state DOWN qlen 1000
> link/ether 40:f2:e9:31:69:40 brd ff:ff:ff:ff:ff:ff
> 7: enP3p11s0f1:  mtu 1500 qdisc mq portid
> 40f2e9316942 state DOWN qlen 1000
> link/ether 40:f2:e9:31:69:42 brd ff:ff:ff:ff:ff:ff
> 8: enP6p1s0f0:  mtu 1500 qdisc mq portid
> 98be94541f80 state DOWN qlen 1000
> link/ether 98:be:94:54:1f:80 brd ff:ff:ff:ff:ff:ff
> 9: enP6p1s0f1:  mtu 1500 qdisc mq portid
> 98be94541f82 state DOWN qlen 1000
> link/ether 98:be:94:54:1f:82 brd ff:ff:ff:ff:ff:ff
> 10: enP3p5s0f0:  mtu 1500 qdisc mq portid
> 01304534323130363730453131 state DOWN qlen 1000
> link/ether 00:90:fa:74:05:50 brd ff:ff:ff:ff:ff:ff
> 11: enP3p5s0f1:  mtu 1500 qdisc mq portid
> 02304534323130363730453131 state DOWN qlen 1000
> link/ether 00:90:fa:74:05:51 brd ff:ff:ff:ff

[openstack-dev] [tripleo] Tripleo CI Community meeting tomorrow

[Arx Cruz]

Hello

We are going to have a TripleO CI Community meeting tomorrow 10/10/2017 at
1 pm UTC time.
The meeting is going to happen on BlueJeans [1] and also on IRC on #tripleo
channel.

After that, we will hold Office Hours starting at 4PM UTC in case someone
from community have any questions related to CI.

Hope to see you there.

1 - https://bluejeans.com/287352206?src=calendarLink



Kind regards,
Arx Cruz
__
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] [oslo][mistral] Mistral expressions package

[Bob Haddleton]

Hello Oslo team:

The Mistral project has an expressions package [0] that is used to 
evaluate inline expressions using a context.  It has a pluggable 
architecture that presently supports Jinja and YAQL expression 
evaluation.  It also allows custom functions[1] to provide Python 
implementations of functionality that is then made available to the 
expression evaluation engines.


This functionality was originally developed to support dynamic 
processing within Mistral workflows, but is also very useful in other 
applications that use templates which require runtime evaluation of 
expressions.


I'd like to explore extracting this functionality from mistral to make 
it more widely available with minimal dependencies.


The expressions dependencies are pretty limited:

Jinja2
oslo.utils
oslo.log
stevedore
yaql

and since 60% are already oslo-maintained packages, it seemed like a 
logical place to start.


I'd appreciate feedback on the topic.  There is no real OpenStack 
dependency in the functionality, so maybe a standalone package on pypi 
makes sense.


Thanks for your help,

Bob Haddleton


[0] https://github.com/openstack/mistral/tree/master/mistral/expressions
[1] 
https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63



__
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] [keystone][nova] Persistent application credentials

[Zane Bitter]

On 12/09/17 18:58, Colleen Murphy wrote:
While it's fresh in our minds, I wanted to write up a short recap of 
where we landed in the Application Credentials discussion in the BM/VM 
room today. For convenience the (as of yet unrevised) spec is here:


Thanks so much for staying on this Colleen, it's tremendously helpful to 
have someone from the core team keeping an eye on it :)



http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/application-credentials.html

Attached are images of the whiteboarded notes.

On the contentious question of the lifecycle of an application 
credential, we re-landed in the same place we found ourselves in when 
the spec originally landed, which is that the credential becomes invalid 
when its creating user is disabled or deleted. The risk involved in 
allowing a credential to continue to be valid after its creating user 
has been disabled is not really surmountable, and we are basically 
giving up on this feature. The benefits we still get from not having to 
embed user passwords in config files, especially for LDAP or federated 
users, is still a vast improvement over the situation today, as is the 
ability to rotate credentials.


OK, there were lots of smart people in the room so I trust that y'all 
made the right decision.


I'd just like to step back for a moment though and ask: how exactly do 
we expect users to make use of Keystone?


When I think about a typical OpenStack user of the near future, they 
looks something like this: there's a team with a handful of developers, 
with maybe one or two devops engineers. This team is responsible for a 
bunch of applications, at various stages in their lifecycles. They work 
in a department with several such teams, in an organisation with several 
such departments. People regularly join or leave the team - whether 
because they join or leave the organisation or just transfer between 
different teams. The applications are deployed with Heat and are at 
least partly self-managing (e.g. they use auto-scaling, or auto-healing, 
or have automated backups, or all of the above), but also require 
occasional manual intervention (beyond just a Heat stack-update). The 
applications may be deployed to a private OpenStack cloud, a public 
OpenStack cloud, or both, with minimal differences in how they work when 
moving back and forth.


(Obviously the beauty of Open Source is that we don't think about only 
one set of users. But I think if we can serve this set of users as a 
baseline then we have built something pretty generically useful.)


So my question is: how do we recommend these users use Keystone? We 
definitely _can_ support them. But the most workable way I can think of 
would be to create a long-lived application user account for each 
project in LDAP/ActiveDirectory/whatever and have that account manage 
the application. Then things will work basically the same way in the 
public cloud, where you also get a user per project. Hopefully some 
auditability is maintained by having Jenkins/Zuul/Solum/whatever do the 
pushing of changes to Heat, although realistically many users will not 
be that sophisticated. Once we have application credentials, the folks 
doing manual intervention would be able to do so in the same way on 
public clouds as on private clouds, without being given the account 
credentials.


Some observations about this scenario:
* The whole user/role infrastructure is completely unused - 'Users' are 
1:1 with projects. We might as well not have built it.
* Having Keystone backed by LDAP/ActiveDirectory is arguably worse than 
useless - it just means there are two different places to set things up 
when creating a project and an extra layer of indirection. (I won't say 
we might as well not have built it, because many organisations have 
compliance rules that, ahem, well let's just say they were developed in 
a different context :)
* We're missing an essential feature of cloud (or even of VPSs): you 
shouldn't need to raise a ticket with IT to be able to deploy a new 
application. Any involvement from them should be asynchronous (e.g. 
setting quotas - although even that is an OpenStack-specific thing: in 
public clouds excessive use is discouraged by _billing_ and in 
non-OpenStack clouds users set their _own_ quotas); we don't want humans 
in the loop.
* AFAIK it's not documented anywhere that this is the way we expect you 
to use OpenStack. Anybody would think it's all about the Users and Roles.


Perhaps someone can suggest a better scenario for this group of users? I 
can't think of one that doesn't involve radical differences between 
public & private clouds (something we're explicitly trying to prevent, 
according to our mission statement), and/or risk total application 
breakage when personnel change.


My worry is that in this and other areas, there's a disconnect between 
the needs of the people whom we say we're building OpenStack for and 
what we're actually building. (Speculati

Re: [openstack-dev] [ironic] Proposing Shivanand Tendulker for ironic-core

[Dmitry Tantsur]

Okay, we have the majority of cores (plus a few non-cores), and no objections.
Welcome to the team! :)

On 10/03/2017 10:07 PM, milanisko k wrote:
> +1 :)
>
> --
> milan
>
> út 3. 10. 2017 v 18:02 odesílatel Vladyslav Drok  > napsal:
>
> +1 for Shiv
>
>
> On 3 Oct 2017 11:20 a.m., "Sam Betts (sambetts)"  > wrote:
>
> +1,
>
> __ __
>
> Sam
>
> __ __
>
> On 03/10/2017, 08:21, "tua...@vn.fujitsu.com
> "  > wrote:
>
> __ __
>
> +1 , Yes, I definitely agree with you.
>
> 
>
> Regards
>
> Tuan
>
> 
>
> *From:*Nisha Agarwal [mailto:agarwalnisha1...@gmail.com
> ]
> *Sent:* Tuesday, October 03, 2017 12:28 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
>  >
> *Subject:* Re: [openstack-dev] [ironic] Proposing Shivanand Tendulker
> for ironic-core
>
> 
>
> +1
>
> 
>
> Regards
>
> Nisha
>
> 
>
> On Mon, Oct 2, 2017 at 11:13 PM, Loo, Ruby  > wrote:
>
> +1, Thx Dmitry for the proposal and Shiv for doing all the work 
> :D
>
> 
>
> --ruby
>
> 
>
> *From: *Dmitry Tantsur  >
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)"  >
> *Date: *Monday, October 2, 2017 at 10:17 AM
> *To: *"OpenStack Development Mailing List (not for usage 
> questions)"
>  >
> *Subject: *[openstack-dev] [ironic] Proposing Shivanand Tendulker
> for ironic-core
>
> 
>
> Hi all!
>
> I would like to propose Shivanand (stendulker) to the core team.
>
> His stats have been consistently high [1]. He has given a lot of
> insightful reviews recently, and his expertise in the iLO driver 
> is
> also very valuable for the team.
>
> As usual, please respond with your comments and objections.
>
> Thanks,
>
> Dmitry
>
>
> [1] 
> http://stackalytics.com/report/contribution/ironic-group/90
>
>
> 
> __
> 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
>
>
>
> 
>
> 
>
> -- 
>
> The Secret Of Success is learning how to use pain and pleasure, 
> instead
> of having pain and pleasure use you. If You do that you are in control
> of your life. If you don't life controls you.
>
>
> 
> __
> 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
>

__
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] [Oslo][Designate][Congress] Problem with from_dict overrides and new oslo.context release

[Ben Nemec]

Hi,

I brought up the fix[1] I proposed for [2] in the Oslo meeting today, 
and it led to some good discussion that we wanted to take to a broader 
audience.  In particular, the projects that are affected by the bug.


The oslo.context change I proposed would essentially obsolete the 
from_dict function in the Context object since it would obligate us to 
support all the keys in to_dict in the constructor.  This unfortunately 
implies some rather rigid constraints on the Context object.  We could 
essentially never remove any parameters from the constructor (which at 
some point we want to do for things like "tenant" that are deprecated 
but still present) or risk breaking if someone passed in parameters from 
an old to_dict call.


The other proposal was to rewrite the existing naive from_dict overrides 
in the affected projects to function more like the from_dict in the base 
class where it explicitly handles only the keys that the constructor 
will recognize.[3]  One benefit of this approach is that it would allow 
the removal of some previous workarounds[4].  This is also cleaner from 
an API perspective as it doesn't impose any new requirements on the 
oslo.context API.  The obvious drawback is that it requires 
project-specific fixes in the affected projects.  We would, of course, 
be happy to help with those fixes though.


So those are the options we've discussed and my thoughts on them. 
Please feel free to weigh in with any other input you may have.  Thanks.


-Ben

1: https://review.openstack.org/509919
2: https://launchpad.net/bugs/1721432
3: 
https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L371
4: 
https://github.com/openstack/designate/blob/46de766e513cfb97cbfc50b001734e02711517e4/designate/context.py#L42


__
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] [ironic] Proposing Shivanand Tendulker for ironic-core

[Shivanand Tendulker]

Thank you all for your support and trust.

Regards
Shiv

On Mon, Oct 9, 2017 at 10:18 PM, Dmitry Tantsur  wrote:

> Okay, we have the majority of cores (plus a few non-cores), and no
> objections.
> Welcome to the team! :)
>
> On 10/03/2017 10:07 PM, milanisko k wrote:
> > +1 :)
> >
> > --
> > milan
> >
> > út 3. 10. 2017 v 18:02 odesílatel Vladyslav Drok  > > napsal:
> >
> > +1 for Shiv
> >
> >
> > On 3 Oct 2017 11:20 a.m., "Sam Betts (sambetts)"  > > wrote:
> >
> > +1,
> >
> > __ __
> >
> > Sam
> >
> > __ __
> >
> > On 03/10/2017, 08:21, "tua...@vn.fujitsu.com
> > "  > > wrote:
> >
> > __ __
> >
> > +1 , Yes, I definitely agree with you.
> >
> > 
> >
> > Regards
> >
> > Tuan
> >
> > 
> >
> > *From:*Nisha Agarwal [mailto:agarwalnisha1...@gmail.com
> > ]
> > *Sent:* Tuesday, October 03, 2017 12:28 PM
> > *To:* OpenStack Development Mailing List (not for usage
> questions)
> >  > >
> > *Subject:* Re: [openstack-dev] [ironic] Proposing Shivanand
> Tendulker
> > for ironic-core
> >
> > 
> >
> > +1
> >
> > 
> >
> > Regards
> >
> > Nisha
> >
> > 
> >
> > On Mon, Oct 2, 2017 at 11:13 PM, Loo, Ruby  > > wrote:
> >
> > +1, Thx Dmitry for the proposal and Shiv for doing all the
> work :D
> >
> > 
> >
> > --ruby
> >
> > 
> >
> > *From: *Dmitry Tantsur  > >
> > *Reply-To: *"OpenStack Development Mailing List (not for
> usage
> > questions)"  > >
> > *Date: *Monday, October 2, 2017 at 10:17 AM
> > *To: *"OpenStack Development Mailing List (not for usage
> questions)"
> >  > >
> > *Subject: *[openstack-dev] [ironic] Proposing Shivanand
> Tendulker
> > for ironic-core
> >
> > 
> >
> > Hi all!
> >
> > I would like to propose Shivanand (stendulker) to the core
> team.
> >
> > His stats have been consistently high [1]. He has given a
> lot of
> > insightful reviews recently, and his expertise in the iLO
> driver is
> > also very valuable for the team.
> >
> > As usual, please respond with your comments and
> objections.
> >
> > Thanks,
> >
> > Dmitry
> >
> >
> > [1] http://stackalytics.com/report/contribution/ironic-
> group/90
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >  unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev
> >
> >
> >
> > 
> >
> > 
> >
> > -- 
> >
> > The Secret Of Success is learning how to use pain and pleasure,
> instead
> > of having pain and pleasure use you. If You do that you are in
> control
> > of your life. If you don't life controls you.
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >  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
> >  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] Supporting SSH host certificates

[Fox, Kevin M]

Yeah, there is a way to do it today. it really sucks though for most users. Due 
to the complexity of doing the task though, most users just have gotten into 
the terrible habit of ignoring the "this host's ssh key changed" and just 
blindly accepting the change. I kind of hate to say it this way, but because of 
the way things are done today, OpenStack's training folks to ignore man in the 
middle attacks. This is not good. We shouldn't just shrug it off and say folks 
should be more careful. We should try and make the edge less sharp so they are 
less likely to stab themselves, and later, give OpenStack a bad name because 
OpenStack was involved.

(Yeah, I get it is not exactly OpenStack's fault that they use it in an unsafe 
manner. But still, if OpenStack can do something about it, it would be better 
for everyone involved)

This is one thing I think k8s is doing really well. kubectl execuses 
the chain of trust built up from user all the way to the pod. There isn't 
anything manual the user has to do to secure the path. OpenStack really could 
benefit from something similar for client to vm.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Friday, October 06, 2017 3:24 PM
To: openstack-dev
Subject: Re: [openstack-dev] Supporting SSH host certificates

Excerpts from Giuseppe de Candia's message of 2017-10-06 13:49:43 -0500:
> Hi Clint,
>
> Isn't user-data by definition available via the Metadata API, which isn't
> considered secure:
> https://wiki.openstack.org/wiki/OSSN/OSSN-0074
>

Correct! The thinking is to account for the MITM attack vector, not
host or instance security as a whole. One would hope the box comes up
in a mostly drone-like state until it can be hardened with a new secret
host key.

> Or is there a way to specify that certain user-data should only be
> available via config-drive (and not metadata api)?
>
> Otherwise, the only difference I see compared to using Meta-data is that
> the process you describe is driven by the user vs. automated.
>
> Regarding the extra plumbing, I'm not trying to avoid it. I'm thinking to
> eventually tie this all into Keystone. For example, a project should have
> Host CA and User CA keys. Let's assume OpenStack manages these for now,
> later we can consider OpenStack simply proxying signature requests and
> vouching that a public key does actually belong to a specific instance (and
> host-name) or Keystone user. So what I think should happen is when a
> Project is enabled for SSHaaS support, any VM instance automatically gets
> host certificate, authorized principal files based on Keystone roles for
> the project, and users can call an API (or Dashboard form) to get a public
> key signed (and assigned appropriate SSH principals).
>

Fascinating, but it's hard for me to get excited about this when I can
just handle MITM security myself.

Note that the other existing techniques are simpler too. Most instances
will print the public host key to the console. The API offers console
access, so it can be scraped for the host key.

__
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] [ptls] Sydney Forum Project Onboarding Rooms

[Dmitry Tantsur]

Hi!

I would like to request a room for Ironic.

I won't be there, but Julia Kreger  agreed to run
the room. I hope to find more ironic people to be there :)

On 10/05/2017 05:50 PM, Kendall Nelson wrote:
> Hello :)
>
> We have a little over 40 slots available so we should be able to accommodate
> almost everyone, but it will be a first response first serve basis.
>
> Logistics: Slots are 40 min long and will have projection set up in them. The
> rooms have a capacity of about 40 people and will be set up classroom style.
>
> If you are interested in reserving a spot, just reply directly to me and I 
> will
> put your project on the list. *Please let me know if you want one and also
> include the names and emails anyone that will be speaking with you. *
>
> When slots run out, they run out.
>
> Thanks!
>
> -Kendall Nelson (diablo_rojo)
>
>
> __
> 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-dev] [os-upstream-institute] Meeting reminder

[Ildiko Vancsa]

Hi Training Team,

This is a friendly reminder that we are having our meeting in two hours (2000 
UTC) on #openstack-meeting-3.

You can find the agenda here: 
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

See you soon! :)

Thanks,
Ildikó
__
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] [os-upstream-institute][all] Looking for mentors for upcoming events

[Ildiko Vancsa]

Hi All,

We have two Upstream Institute trainings [1] upcoming and we are looking for 
mentors to join us and help new contributors to start their journey in 
OpenStack.

We have a training in Copenhagen on October 18 and one in Sydney before the 
Summit on November 4-5. If you are available for each or both of these 
occasions and interested to join our crew please sign up on our wiki page [2].

If you have any questions please reply to this thread or reach out to the team 
on the #openstack-upstream-institute IRC channel.

Thanks and Best Regards,
Ildikó
(IRC: ildikov)

[1] https://docs.openstack.org/upstream-training/#upcoming-trainings
[2] https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute_Occasions
__
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] [Oslo][Designate][Congress] Problem with from_dict overrides and new oslo.context release

[Doug Hellmann]

Excerpts from Ben Nemec's message of 2017-10-09 12:03:24 -0500:
> Hi,
> 
> I brought up the fix[1] I proposed for [2] in the Oslo meeting today, 
> and it led to some good discussion that we wanted to take to a broader 
> audience.  In particular, the projects that are affected by the bug.
> 
> The oslo.context change I proposed would essentially obsolete the 
> from_dict function in the Context object since it would obligate us to 
> support all the keys in to_dict in the constructor.  This unfortunately 
> implies some rather rigid constraints on the Context object.  We could 
> essentially never remove any parameters from the constructor (which at 
> some point we want to do for things like "tenant" that are deprecated 
> but still present) or risk breaking if someone passed in parameters from 
> an old to_dict call.
> 
> The other proposal was to rewrite the existing naive from_dict overrides 
> in the affected projects to function more like the from_dict in the base 
> class where it explicitly handles only the keys that the constructor 
> will recognize.[3]  One benefit of this approach is that it would allow 
> the removal of some previous workarounds[4].  This is also cleaner from 
> an API perspective as it doesn't impose any new requirements on the 
> oslo.context API.  The obvious drawback is that it requires 
> project-specific fixes in the affected projects.  We would, of course, 
> be happy to help with those fixes though.
> 
> So those are the options we've discussed and my thoughts on them. 
> Please feel free to weigh in with any other input you may have.  Thanks.
> 
> -Ben
> 
> 1: https://review.openstack.org/509919
> 2: https://launchpad.net/bugs/1721432
> 3: 
> https://github.com/openstack/oslo.context/blob/master/oslo_context/context.py#L371
> 4: 
> https://github.com/openstack/designate/blob/46de766e513cfb97cbfc50b001734e02711517e4/designate/context.py#L42
> 

I originally objected to [1] because it seemed like the from_dict()
API was the right place to make the change, and that projects should
be using that class method instead of the constructor if they're
creating contexts from dicts full of data where they can't be sure
of the keys. The current implementation of from_dict() merges keyword
arguments and a dictionary before passing the results to the
constructor, but we could also have it do name translation, strip
unknown arguments (with a warning), etc.

Long term, I think this makes the context API easier to understand
because the constructor arguments are the expected names and all
of the munging logic is isolated in the alternate constructor. Short
term, it's going to be a little more work to fix the current breakage.
I will help with those changes.

Doug

__
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] [ptls] Sydney Forum Project Onboarding Rooms

[Kendall Nelson]

I added Ironic to my spreadsheet and made Julia the primary speaker :) Let
me know if there are other names you want to me to add.

-Kendall (diablo_rojo)

On Mon, Oct 9, 2017 at 10:50 AM Dmitry Tantsur  wrote:

> Hi!
>
> I would like to request a room for Ironic.
>
> I won't be there, but Julia Kreger  agreed
> to run
> the room. I hope to find more ironic people to be there :)
>
> On 10/05/2017 05:50 PM, Kendall Nelson wrote:
> > Hello :)
> >
> > We have a little over 40 slots available so we should be able to
> accommodate
> > almost everyone, but it will be a first response first serve basis.
> >
> > Logistics: Slots are 40 min long and will have projection set up in
> them. The
> > rooms have a capacity of about 40 people and will be set up classroom
> style.
> >
> > If you are interested in reserving a spot, just reply directly to me and
> I will
> > put your project on the list. *Please let me know if you want one and
> also
> > include the names and emails anyone that will be speaking with you. *
> >
> > When slots run out, they run out.
> >
> > Thanks!
> >
> > -Kendall Nelson (diablo_rojo)
> >
> >
> >
> __
> > 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] [oslo][mistral] Mistral expressions package

[Doug Hellmann]

Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:
> Hello Oslo team:
> 
> The Mistral project has an expressions package [0] that is used to 
> evaluate inline expressions using a context.  It has a pluggable 
> architecture that presently supports Jinja and YAQL expression 
> evaluation.  It also allows custom functions[1] to provide Python 
> implementations of functionality that is then made available to the 
> expression evaluation engines.
> 
> This functionality was originally developed to support dynamic 
> processing within Mistral workflows, but is also very useful in other 
> applications that use templates which require runtime evaluation of 
> expressions.
> 
> I'd like to explore extracting this functionality from mistral to make 
> it more widely available with minimal dependencies.
> 
> The expressions dependencies are pretty limited:
> 
> Jinja2
> oslo.utils
> oslo.log
> stevedore
> yaql
> 
> and since 60% are already oslo-maintained packages, it seemed like a 
> logical place to start.
> 
> I'd appreciate feedback on the topic.  There is no real OpenStack 
> dependency in the functionality, so maybe a standalone package on pypi 
> makes sense.
> 
> Thanks for your help,
> 
> Bob Haddleton
> 
> 
> [0] https://github.com/openstack/mistral/tree/master/mistral/expressions
> [1] 
> https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63
> 

Oslo is a good place for things like this that have no other obvious
home, but if the Mistral team is already managing the code is there any
reason they couldn't also manage the library after you pull it out of
the service? It's much easier for any project team to manage a library
now, and we have several other examples of that pattern already.

Doug

__
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] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

[Alex Schultz]

On Mon, Oct 9, 2017 at 3:29 AM, Flavio Percoco  wrote:
> Greetings,
>
> I've been working on something called triple-apbs (and it's respective
> roles) in
> the last couple of months. You can find more info about this work
> here[0][1][2]
>
> This work is at the point where I think it would be worth start discussing
> how
> we want these repos to exist under the TripleO umbrella. As far as I can
> tell,
> we have 2 options (please comment with alternatives if there are more):
>
> 1. A repo per role: Each role would have its own repo - this is the way I've
> been developing it on Github. This model is closer to the ansible way of
> doing
> things and it'll make it easier to bundle, ship, and collaborate on,
> individual
> roles. Going this way would produce something similar to what the
> openstack-ansible folks have.
>

I think we've proven that this is a better way to handle these types
of things so I would prefer option #1. I would say that it might be
useful to also create a basic cookiecutter template for these repos so
we can quickly bootstrap new ones. One thing that has a been a
repeated problem when you do split these modules is having to do bulk
updates for requirements or shared structure items and making sure we
don't accrue a ton of tech-debt over time.

Thanks,
-Alex


> 2. Everything in a single repo: this would ease the import process and
> integration with the rest of TripleO. It'll make the early days of this work
> a
> bit easier but it will take us in a direction that doesn't serve one of the
> goals of this work.
>
> My preferred option is #1 because one of the goals of this work is to have
> independent roles that can also be consumed standalone. In other words, I
> would
> like to stay closer to the ansible recommended structure for roles. Some
> examples[3][4]
>
> Any thoughts? preferences?
> Flavio
>
> [0] http://blog.flaper87.com/deploy-mariadb-kubernetes-tripleo.html
> [1]
> http://blog.flaper87.com/glance-keystone-mariadb-on-k8s-with-tripleo.html
> [2] https://github.com/tripleo-apb
> [3] https://github.com/tripleo-apb/ansible-role-k8s-mariadb
> [4] https://github.com/tripleo-apb/ansible-role-k8s-glance
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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] Repo structure for ansible-k8s-roles-* under TripleO's umbrella

[Emilien Macchi]

On Mon, Oct 9, 2017 at 2:29 AM, Flavio Percoco  wrote:
[...]
> 1. A repo per role: Each role would have its own repo - this is the way I've
> been developing it on Github. This model is closer to the ansible way of
> doing
> things and it'll make it easier to bundle, ship, and collaborate on,
> individual
> roles. Going this way would produce something similar to what the
> openstack-ansible folks have.

+1 on #1 for the composability.

[...]

Have we considered renaming it to something without tripleo in the name?
Or is it too specific to TripleO that we want it in the name?
-- 
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

Re: [openstack-dev] [stable] Preping for the stable/newton EOL

[Alex Schultz]

On Thu, Oct 5, 2017 at 5:01 PM, Tony Breeds  wrote:
> On Thu, Oct 05, 2017 at 09:00:00AM -0600, Alex Schultz wrote:
>> On Tue, Oct 3, 2017 at 9:51 PM, Tony Breeds  wrote:
>
>> Would it be possible to delay the Newton EOL for the TripleO projects
>> for ~1month? We still have some patches outstanding and would like to
>> delay the EOL for now.  As previously mentioned elsewhere it would be
>> beneficial for us to wait until the end of Queens but for now I'd like
>> to pencil in ~1month to give us additional time to evaulate if we need
>> more time.  Let me know if this isn't realistic or there are any
>> glaring issues with this.
>
> I'm happy to exclude tripleo from the initial EOL cycle (and had added
> tripleo's repos to my list of 'opt-out' repos based on previous emails).
> It'd be good if we could setup a one-off time with tripleo, stable (me)
> and infra to look at what CI you have an which parts are generally
> impacted by repo's EOLing.  For example it's probable that
> openstack/requiremnets (and that implies openstack-dev/devstack) need to
> be the last projects to retire.
>
> That isn't terrible but I'd still like to make sure we're on the same
> page so we can level set everyone's expectations.
>
> So who from tripleo needs to be there and what TZ are they in?
>

So probably Emilien and/or some folks from the TripleO CI Squad to
review.  I will bring it up tomorrow during the tripleo meeting.

Thanks,
-Alex

> Yours Tony.
>
> __
> 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] [tc][docs][release] Updating the PTI for docs and tarballs

[Doug Hellmann]

Excerpts from Monty Taylor's message of 2017-10-05 08:45:52 -0500:
> On 09/30/2017 10:40 AM, Doug Hellmann wrote:
> > Excerpts from Monty Taylor's message of 2017-09-30 10:20:08 -0500:
> >> Hey everybody,
> >>
> >> Oh goodie, I can hear you say, let's definitely spend some time
> >> bikeshedding about specific command invocations related to building docs
> >> and tarballs!!!
> >>
> >> tl;dr I want to change the PTI for docs and tarball building to be less
> >> OpenStack-specific
> >>
> >> The Problem
> >> ===
> >>
> >> As we work on Zuul v3, there are a set of job definitions that are
> >> rather fundamental that can totally be directly shared between Zuul
> >> installations whether those Zuuls are working with OpenStack content or
> >> not. As an example "tox -epy27" is a fairly standard thing, so a Zuul
> >> job called "tox-py27" has no qualities specific to OpenStack and could
> >> realistically be used by anyone who uses tox to manage their project.
> >>
> >> Docs and Tarballs builds for us, however, are the following:
> >>
> >> tox -evenv -- python setup.py sdist
> >> tox -evenv -- python setup.py build_sphinx
> >>
> >> Neither of those are things that are likely to work outside of
> >> OpenStack. (The 'venv' tox environment is not a default tox thing)
> >>
> >> I'm going to argue neither of them are actually providing us with much
> >> value.
> >>
> >> Tarball Creation
> >> 
> >>
> >> Tarball creation is super simple. setup_requires is already handled out
> >> of band of everything else. Go clone nova into a completely empty system
> >> and run python setup.py sdist ... and it works. (actually, nova is big.
> >> use something smaller like gertty ...)
> >>
> >>  docker run -it --rm python bash -c 'git clone \
> >>https://git.openstack.org/openstack/gertty && cd gertty \
> >>&& python setup.py sdist'
> >>
> >> There is not much value in that tox wrapper - and it's not like it's
> >> making it EASIER to run the command. In fact, it's more typing.
> >>
> >> I propose we change the PTI from:
> >>
> >> tox -evenv python setup.py sdist
> >>
> >> to:
> >>
> >> python setup.py sdist
> >>
> >> and then change the gate jobs to use the non-tox form of the command.
> >>
> >> I'd also like to further change it to be explicit that we also build
> >> wheels. So the ACTUAL commands that the project should support are:
> >>
> >> python setup.py sdist
> >> python setup.py bdist_wheel
> >>
> >> All of our projects support this already, so this should be a no-op.
> >>
> >> Notes:
> >>
> >> * Python projects that need to build C extensions might need their pip
> >> requirements (and bindep requirements) installed in order to run
> >> bdist_wheel. We do not support that broadly at the moment ANYWAY - so
> >> I'd like to leave that as an outlier and handle it when we need to
> >> handle it.
> >>
> >> * It's *possible* that somewhere we have a repo that has somehow done
> >> something that would cause python setup.py sdist or python setup.py
> >> bdist_wheel to not work without pip requirements installed. I believe we
> >> should consider that a bug and fix it in the project if we find such a
> >> thing - but since we use pbr in all of the OpenStack projects, I find it
> >> extremely unlikely.
> >>
> >> Governance patch submitted: https://review.openstack.org/508693
> >>
> >> Sphinx Documentation
> >> 
> >>
> >> Doc builds are more complex - but I think there is a high amount of
> >> value in changing how we invoke them for a few reasons.
> >>
> >> a) nobody uses 'tox -evenv -- python setup.py build_sphinx' but us
> >> b) we decided to use sphinx for go and javascript - but we invoke sphinx
> >> differently for each of those (since they naturally don't have tox),
> >> meaning we can't just have a "build-sphinx-docs" job and even share it
> >> with ourselves.
> >> c) readthedocs.org is an excellent Open Source site that builds and
> >> hosts sphinx docs for projects. They have an interface for docs
> >> requirements documented and defined that we can align. By aligning,
> >> projects can use migrate between docs.o.o and readthedocs.org and still
> >> have a consistent experience.
> >>
> >> The PTI I'd like to propose for this is more complex, so I'd like to
> >> describe it in terms of:
> >>
> >> - OpenStack organizational requirements
> >> - helper sugar for developers with per-language recommendations
> >>
> >> I believe the result can be a single in-tree doc PTI that applies to
> >> python, go and javascript - and a single Zuul job that applies to all of
> >> our projects AND non-OpenStack projects as well.
> >>
> >> Organizational Requirements
> >> ---
> >>
> >> Following readthedocs.org logic we can actually support a wider range of
> >> schemes technically, but there is human value in having consistency on
> >> these topics across our OpenStack repos.
> >>
> >> * docs live in doc/source
> >> * Python requirements need

Re: [openstack-dev] [docs] Evidence of Success

[Doug Hellmann]

This draft looks really good. I left a few comments on the etherpad.

Excerpts from Jimmy McArthur's message of 2017-10-05 10:33:48 -0500:
> Sorry for the Google Docs link btw. That's where Petr and I were 
> initially collaborating. I've moved this back to the etherpad referenced 
> in ttps://etherpad.openstack.org/p/docs-i18n-ptg-queens 
> 
> 
> https://etherpad.openstack.org/p/docs-i18n-ptg-queens-mission-statement
> 
> > Jimmy McArthur 
> > October 4, 2017 at 1:18 PM
> >
> >
> >> Emilien Macchi 
> >> October 4, 2017 at 12:35 PM
> >>
> >> The draft is really good! It reflects very well what we said we would
> >> do at the PTG, way to go.
> >>
> >> I think the next steps would be:
> >> - Definition of Done, or how you consider something achieved (code
> >> merged, doc published, etc).
> >> - Metrics: what metrics do you use to measure what you're delivering.
> > For the DoD and Metrics our understanding of the task was that they 
> > should be built into the Evidence of Success, though I think we could 
> > still use some more specific metrics in certain spots.  Emilien, would 
> > you suggest we define these as separate line items as well?
> >
> > Thanks!
> > Jimmy
> >> - What do you expect by end of Queens (put some number in metrics is
> >> probably a good start) - it's already mentioned in your draft vision
> >> but it might be revisited once you define the 2 previous items.
> >>
> >> Good work!
> >> Jimmy McArthur 
> >> October 4, 2017 at 10:46 AM
> >> I've made a bit of progress on the collaborative vision for the Docs 
> >> team: 
> >> https://docs.google.com/document/d/1Xy78CnmnKlQ7SbR1XewqgrUdGe7DqnKAGYw_9aj5Ndg/edit#
> >>  
> >>
> >>
> >> This still needs plenty of work, but I wanted to put out what we have 
> >> so we can start to get some feedback from other members of the Docs 
> >> team. The Use Cases section in particular was really vast and hard to 
> >> cut down into prose without getting too detailed.
> >>
> >> Welcome your feedback and input!
> >>
> >> Thanks,
> >> Jimmy
> >>
> >>
> >>
> >> __ 
> >>
> >> 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
> > Emilien Macchi 
> > October 4, 2017 at 12:35 PM
> >
> > The draft is really good! It reflects very well what we said we would
> > do at the PTG, way to go.
> >
> > I think the next steps would be:
> > - Definition of Done, or how you consider something achieved (code
> > merged, doc published, etc).
> > - Metrics: what metrics do you use to measure what you're delivering.
> > - What do you expect by end of Queens (put some number in metrics is
> > probably a good start) - it's already mentioned in your draft vision
> > but it might be revisited once you define the 2 previous items.
> >
> > Good work!
> > Jimmy McArthur 
> > October 4, 2017 at 10:46 AM
> > I've made a bit of progress on the collaborative vision for the Docs 
> > team: 
> > https://docs.google.com/document/d/1Xy78CnmnKlQ7SbR1XewqgrUdGe7DqnKAGYw_9aj5Ndg/edit#
> >  
> >
> >
> > This still needs plenty of work, but I wanted to put out what we have 
> > so we can start to get some feedback from other members of the Docs 
> > team. The Use Cases section in particular was really vast and hard to 
> > cut down into prose without getting too detailed.
> >
> > Welcome your feedback and input!
> >
> > Thanks,
> > Jimmy
> >
> >
> >
> > __ 
> >
> > 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] Supporting SSH host certificates

[Clint Byrum]

And k8s has the benefit of already having been installed with certs that
had to get there somehow.. through a trust bootstrap.. usually SSH. ;)

Excerpts from Fox, Kevin M's message of 2017-10-09 17:37:17 +:
> Yeah, there is a way to do it today. it really sucks though for most users. 
> Due to the complexity of doing the task though, most users just have gotten 
> into the terrible habit of ignoring the "this host's ssh key changed" and 
> just blindly accepting the change. I kind of hate to say it this way, but 
> because of the way things are done today, OpenStack's training folks to 
> ignore man in the middle attacks. This is not good. We shouldn't just shrug 
> it off and say folks should be more careful. We should try and make the edge 
> less sharp so they are less likely to stab themselves, and later, give 
> OpenStack a bad name because OpenStack was involved.
> 

I agree that we could do better.

I think there _is_ a standardized method which is to print the host
public keys to console, and scrape them out on first access.

> (Yeah, I get it is not exactly OpenStack's fault that they use it in an 
> unsafe manner. But still, if OpenStack can do something about it, it would be 
> better for everyone involved)
> 

We could do better though. We could have an API for that.

> This is one thing I think k8s is doing really well. kubectl execuses 
> the chain of trust built up from user all the way to the pod. There isn't 
> anything manual the user has to do to secure the path. OpenStack really could 
> benefit from something similar for client to vm.
> 

This is an unfair comparison. k8s is running in the user space, and as
such rides on the bootstrap trust of whatever was used to install it.

__
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] [tc][election] TC candidacy

[Paul Belanger]

Today I step outside my comfort zone and submit my name into the Technical
Committee's election.

I'm a Red Hat employee who contributes full time to the OpenStack Project
Infrastructure team and have been contributing since Folsom release (22 Sept
2012).

I submit my ballot today, not because I seek to be in the lime light but to help
fill the void of the awesome contributors before me. Like any project, I think
it is healthy to rotate new people and new ideas into a project.  It is a great
way for people to learn new leadership skills but also a way for a project to
gain new energy and share different points of views.

For my knowledge, I hope to bring an point of view from operations. While I
have contributed to OpenStack projects, my primary passion is helping provide
the OpenStack resources to contributors to make OpenStack awesome. In doing so,
working on the Infrastructure project allows for the ability to see what is
great about OpenStack and what could use improvements.

I believe you get out of something what you put into it, so here I am adding my
name of the list.

Good luck to all,
Paul Belanger

__
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] [octavia] New meeting time and channel

[Michael Johnson]

Hello OpenStack load balancing folks,

Summary: Octavia/neutron-lbaas weekly IRC meeting will be 20:00 UTC on
Wednesdays in the #openstack-lbaas channel.

As discussed at the last two weekly meetings[1], we are moving our
meeting time back to the previous time slot.  Unfortunately the
earlier time slot did not work for some team members and attendance
dropped.

Based on the results from the doodle poll [2], our old meeting time
works better for folks when taking into account that some folks are
transitioning to other work. With the recent TC resolution allowing
meetings in the team channels[3] we will be having the weekly IRC
meeting in the #openstack-lbaas channel.

The core team is also available in the #openstack-lbaas channel
covering a wide time window, so please feel free to utilize the
#openstack-lbaas channel if you are unable to attend the weekly
meeting.

Michael (johnsom)

[1] 
https://wiki.openstack.org/wiki/Octavia/Meeting_Minutes#2017-10-04_Weekly_meeting:
[2] https://beta.doodle.com/poll/p65x9xxkec52ecaw
[3] 
https://governance.openstack.org/tc/resolutions/20170718-allow-scheduling-meetings-on-team-channels.html

__
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] [ptls] Sydney Forum Project Onboarding Rooms

[Kendall Nelson]

Wanted to keep this thread towards the top of inboxes for those I haven't
heard from yet.

About a 1/4 of the way booked, so there are still slots available!

-Kendall (diablo_rojo)

On Thu, Oct 5, 2017 at 8:50 AM Kendall Nelson  wrote:

> Hello :)
>
> We have a little over 40 slots available so we should be able to
> accommodate almost everyone, but it will be a first response first serve
> basis.
>
> Logistics: Slots are 40 min long and will have projection set up in them.
> The rooms have a capacity of about 40 people and will be set up classroom
> style.
>
> If you are interested in reserving a spot, just reply directly to me and I
> will put your project on the list. *Please let me know if you want one
> and also include the names and emails anyone that will be speaking with
> you. *
>
> When slots run out, they run out.
>
> Thanks!
>
> -Kendall Nelson (diablo_rojo)
>
__
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] [policy] AWS IAM session

[Lance Bragstad]

I've put a scheduling session on the books for the next policy meeting
[0][1]. Advertising it here since folks who want to be involved have
responded to the thread.

Let's use this meeting time to iron out account details and figure out
what exactly we want to get out of the session.


[0] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
[1] https://etherpad.openstack.org/p/keystone-policy-meeting

On 10/05/2017 02:24 AM, Colleen Murphy wrote:
> On Tue, Oct 3, 2017 at 10:08 PM, Lance Bragstad  > wrote:
>
> Hey all,
>
> It was mentioned in today's keystone meeting [0] that it would be
> useful
> to go through AWS IAM (or even GKE) as a group. With all the recent
> policy discussions and work, it seems useful to get our eyes on
> another
> system. The idea would be to spend time using a video
> conference/screen
> share to go through and play with policy together. The end result
> should
> keep us focused on the implementations we're working on today, but
> also
> provide clarity for the long-term vision of OpenStack's RBAC system.
>
> Are you interested in attending? If so, please respond to the thread.
> Once we have some interest, we can gauge when to hold the meeting,
> which
> tools we can use, and setting up a test IAM account.
>
> Thanks,
>
> Lance
>
> [0]
> 
> http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-03-18.00.log.html#l-119
> 
> 
>
> Please count me in.
>
> Colleen
>
>
> __
> 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



signature.asc
Description: OpenPGP digital 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

[openstack-dev] [ironic] this week's priorities and subteam reports

[Yeleswarapu, Ramamani]

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. Repair the CI after migrating to Zuul v3
2. BIOS interface spec: https://review.openstack.org/#/c/496481/
3. Deprecate "ironic" CLI: https://review.openstack.org/#/c/508218/
4. Switch to none auth for standalone mode: 
https://review.openstack.org/#/c/359061/
5. Bug fix for ironicclient URL handling: 
https://review.openstack.org/#/c/509851/ MERGING

After we repair the CI:
1. Rolling upgrades missing bit: https://review.openstack.org/#/c/497666/
1.1. check object versions in dbsync tool: 
https://review.openstack.org/#/c/497703/

Vendor priorities
-
cisco-ucs:
 Patchs in works for SDK update, but not posted yet, currently rebuilding 
third party CI infra after a disaster...
idrac:
Dell 3d party CI stability improvement for 13G and 12G servers
https://review.openstack.org/#/c/507942/
ilo:
Support SUM based firmware update as clean step for iLO drivers
https://review.openstack.org/#/c/422572/
irmc:
nothing to review this week. secure boot support for virtual media boot 
interface is coming soon.
oneview:
   Migrate python-oneviewclient validations to Ironic OneView Drivers - 
https://review.openstack.org/#/c/468428/

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
(dtantsur on behalf of milan): firewall refactoring: 
https://review.openstack.org/#/c/471831/ (milan) +1 for this week to move one 
step closer towards the dnsmasq PXE filter backend (milan) +1 let's finish this 
one!
networking-baremetal:
  neutron baremetal agent https://review.openstack.org/#/c/456235/
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/

Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 02 Oct 2017 and 09 Oct 2017)
- Ironic: 262 bugs (-1) + 258 wishlist items. 22 new, 205 in progress (+3), 1 
critical (+1), 37 high (+3) and 32 incomplete (-2)
- Inspector: 17 bugs (+4) + 29 wishlist items (-1). 2 new, 15 in progress (+2), 
0 critical, 5 high (+3) and 3 incomplete
- Nova bugs with Ironic tag: 14 (-1). 0 new, 0 critical, 2 high

CI refactoring and missing test coverage

- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- localboot with partitioned image patches:
- IPA - build tinycore based partitioned image with grub 
https://review.openstack.org/#/c/504888/
- Ironic - add localboot partitioned image test: 
https://review.openstack.org/#/c/502886/
- when previous are merged TODO (vsaienko)
- Upload tinycore partitioned image to tarbals.openstack.org
- Switch ironic to use tinyipa partitioned image by default
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- local boot with partition images: TODO 
https://bugs.launchpad.net/ironic/+bug/1531149
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/

Essential Priorities


Ironic client API version negotiation (TheJulia, dtantsur)
--
- status as of 09 Oct 2017:
- not started

External project authentication rework (pas-ha, TheJulia)
-
- gerrit topic: https://review.openstack.org/#/q/topic:bug/1699547
- status as of 27 Sep 2017:
- review needed

Old ironic CLI deprecation (rloo)
-
- rfe: https://bugs.launchpad.net/python-ironicclient/+bug/1700815
- code/doc patch ready for review: Deprecate the ironic CLI: 
https://review.openstack.org/#/c/508218/

Classic drivers deprecation (dtantsur)
--
- spec: 
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/classic-drivers-future.html
- status as of 09 Oct 2017:
- dev documentation for hardware types: TODO
- finish migration guide for all drivers: TODO
- switch documentation to hardware types: TODO

Reference architecture guide (dtantsur, sambetts)
-
- status as of 09 Oct 2017:
- Common bits: https://review.openstack.org/487410 needs review
- list of cases from 
https://etherpad.openstack.org/p/ironic-queens-ptg-open-discussion
- Admin-only provisioner
- smal

Re: [openstack-dev] [neutron][lbaasv2][agent implementation] L7 policy support

[German Eichberger]

Mihaela,

The first version with L7 was Newton and beginning then the LBaaS V2 namespace 
driver would support it as well as Octavia.

German

From: "mihaela.ba...@orange.com" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, October 3, 2017 at 2:13 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [neutron][lbaasv2][agent implementation] L7 policy 
support

Hello,

Does the agent implementation of LBaaSv2 support L7 policies? I am testing with 
Mitaka version and I get “Not Implemented Error”.

{"asctime": "2017-10-03 07:34:42.764","process": "18","levelname": 
"INFO","name": "neutron_lbaas.services.loadbalancer.plugin", "request_id": 
"req-186bf812-1cdf-496b-a117-711f1e42c6bd", "user_identity": {"user_id": 
"44364a07de754daa9ffeb2911fe3620a", "project_id": 
"a5f15235c0714365b98a50a11ec956e7", "domain_id": "-", "user_domain_id": "-", 
"project_domain_id": "-"},"instance": {},"message":"Calling driver operation 
NotImplementedManager.create"}
{"asctime": "2017-10-03 07:34:42.765","process": "18","levelname": 
"ERROR","name": "neutron_lbaas.services.loadbalancer.plugin", "request_id": 
"req-186bf812-1cdf-496b-a117-711f1e42c6bd", "user_identity": {"user_id": 
"44364a07de754daa9ffeb2911fe3620a", "project_id": 
"a5f15235c0714365b98a50a11ec956e7", "domain_id": "-", "user_domain_id": "-", 
"project_domain_id": "-"},"instance": {},"message":"There was an error in the 
driver"}
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>Traceback (most recent call last):
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>  File 
"/opt/neutron/lib/python2.7/site-packages/neutron_lbaas/services/loadbalancer/plugin.py",
 line 486, in _call_driver_operation
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>driver_method(context, db_entity)
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>  File 
"/opt/neutron/lib/python2.7/site-packages/neutron_lbaas/drivers/driver_base.py",
 line 36, in create
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>raise NotImplementedError()
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>NotImplementedError
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>
{"asctime": "2017-10-03 07:34:42.800","process": "18","levelname": 
"ERROR","name": "neutron.api.v2.resource", "request_id": 
"req-186bf812-1cdf-496b-a117-711f1e42c6bd", "user_identity": {"user_id": 
"44364a07de754daa9ffeb2911fe3620a", "project_id": 
"a5f15235c0714365b98a50a11ec956e7", "domain_id": "-", "user_domain_id": "-", 
"project_domain_id": "-"},"instance": {},"message":"create failed"}
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >Traceback (most 
recent call last):
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 84, 
in resource
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >result = 
method(request=request, **args)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/neutron/api/v2/base.py", line 410, in 
create
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >return 
self._create(request, body, **kwargs)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/oslo_db/api.py", line 148, in wrapper
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >ectxt.value 
= e.inner_exc
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >
self.force_reraise()
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >
six.reraise(self.type_, self.value, self.tb)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/oslo_db/api.py", line 138, in wrapper
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >return 
f(*args, **kwargs)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/neutron/api/v2/base.py", line 521, in 
_create
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >obj = 
do_create(body)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/neutron/api/v2/base.py", line 503, in 
do_create
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >
request.context, reservatio

Re: [openstack-dev] [octavia] Proposing Nir Magnezi as Octavia core reviewer

[Adam Harwell]

+1

On Thu, Oct 5, 2017, 05:48 Daniel Mellado 
wrote:

> +1
>
> Go, Nir, Go!
>
> congrats!
>
> On 10/05/2017 03:51 AM, German Eichberger wrote:
> > +1
> >
> > Welcome Nir, well earned.
> >
> > German
> >
> > On 10/4/17, 4:28 PM, "Michael Johnson"  wrote:
> >
> > Hello OpenStack folks,
> >
> > I would like to propose Nir Magnezi as a core reviewer on the
> Octavia project.
> >
> > He has been an active contributor to the Octavia projects for a few
> > releases and has been providing solid patch review comments. His
> > review stats are also in line with other core reviewers.
> >
> > Octavia cores, please reply to this e-mail with your
> > agreement/disagreement to this proposal.
> >
> > Michael
> >
> >
>  __
> > 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
>
__
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] Proposing Nir Magnezi as Octavia core reviewer

[Michael Johnson]

Ok, that is quorum.

Congratulations Nir!

Michael


On Mon, Oct 9, 2017 at 3:18 PM, Adam Harwell  wrote:
> +1
>
>
> On Thu, Oct 5, 2017, 05:48 Daniel Mellado 
> wrote:
>>
>> +1
>>
>> Go, Nir, Go!
>>
>> congrats!
>>
>> On 10/05/2017 03:51 AM, German Eichberger wrote:
>> > +1
>> >
>> > Welcome Nir, well earned.
>> >
>> > German
>> >
>> > On 10/4/17, 4:28 PM, "Michael Johnson"  wrote:
>> >
>> > Hello OpenStack folks,
>> >
>> > I would like to propose Nir Magnezi as a core reviewer on the
>> > Octavia project.
>> >
>> > He has been an active contributor to the Octavia projects for a few
>> > releases and has been providing solid patch review comments. His
>> > review stats are also in line with other core reviewers.
>> >
>> > Octavia cores, please reply to this e-mail with your
>> > agreement/disagreement to this proposal.
>> >
>> > Michael
>> >
>> >
>> > __
>> > 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
>
>
> __
> 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] Supporting SSH host certificates

[Fox, Kevin M]

I don't think its unfair to compare against k8s in this case. You have to 
follow the same kinds of steps as an admin provisioning a k8s compute node as 
you do an openstack compute node. The main difference I think is they make use 
of the infrastructure that was put in place by the operator, making it 
available to the user in a more friendly way, while currently we ask the user 
to manually piece together a secure path themselves utilizing back channels 
that the operator secured (consoles)

As far as console scraping, as standard a practice as it is, isn't very well 
adopted. Most folks I've seen just ignore the ssh stuff entirely and live with 
the man in the middle risk. So, while a standard, its an infrequently used one, 
IMO.

Theres a temporal issue too. Standing up a new compute node happens rarely. 
Standing up a new vm should be relatively frequent. As an operator, I'd be ok 
taking on the one time cost burden of setup of the compute nodes if I didn't 
have to worry so much about users doing bad things with ssh.

Thanks,
Kevin

From: Clint Byrum [cl...@fewbar.com]
Sent: Monday, October 09, 2017 1:42 PM
To: openstack-dev
Subject: Re: [openstack-dev] Supporting SSH host certificates

And k8s has the benefit of already having been installed with certs that
had to get there somehow.. through a trust bootstrap.. usually SSH. ;)

Excerpts from Fox, Kevin M's message of 2017-10-09 17:37:17 +:
> Yeah, there is a way to do it today. it really sucks though for most users. 
> Due to the complexity of doing the task though, most users just have gotten 
> into the terrible habit of ignoring the "this host's ssh key changed" and 
> just blindly accepting the change. I kind of hate to say it this way, but 
> because of the way things are done today, OpenStack's training folks to 
> ignore man in the middle attacks. This is not good. We shouldn't just shrug 
> it off and say folks should be more careful. We should try and make the edge 
> less sharp so they are less likely to stab themselves, and later, give 
> OpenStack a bad name because OpenStack was involved.
>

I agree that we could do better.

I think there _is_ a standardized method which is to print the host
public keys to console, and scrape them out on first access.

> (Yeah, I get it is not exactly OpenStack's fault that they use it in an 
> unsafe manner. But still, if OpenStack can do something about it, it would be 
> better for everyone involved)
>

We could do better though. We could have an API for that.

> This is one thing I think k8s is doing really well. kubectl execuses 
> the chain of trust built up from user all the way to the pod. There isn't 
> anything manual the user has to do to secure the path. OpenStack really could 
> benefit from something similar for client to vm.
>

This is an unfair comparison. k8s is running in the user space, and as
such rides on the bootstrap trust of whatever was used to install it.

__
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-dev] [all][infra] Zuul v3 rollout, the sequel

[Jeremy Stanley]

The tl;dr is that we're planning to roll forward out of our partial
Zuul v3 rollback starting at 11:00 UTC on Wednesday October 11
(a little over 35 hours from now), so expect some CI downtime and
all of the benefits (though hopefully none of the drawbacks!) you
witnessed when we tried the first time.

It's been right at a week since we instituted a partial rollback of
our initial v3 roll-out. That week has been filled by diagnosing and
fixing all of the misbehaviors and performance degradation we
identified, including some new issues we discovered while running
under even heavier load and memory pressure artificially induced by
trying to fire check jobs for everything v2 was running but with
only a fraction of the node capacity. Numerous issues within the
translated legacy job configs were also fixed, and a bunch more of
them replaced by v3-native jobs.

We anticipate an outage for the CI system of somewhere between 30-60
minutes starting at 11:00 UTC on Wednesday October 11. Once
complete, we'll send a follow-up announcement along with a link to
where we're coordinating and triaging any newly observed issues. In
the meantime, if you've been digging into recent legacy job failures
for your projects you should consider trying to bring them to our
attention as soon as possible (in #openstack-infra on the Freenode
IRC network, or replying on-list to this announcement) and work on
fixing them if you're familiar enough with the failures to do so
yourself. We're assembling a sort of FAQ in the migration guide
here:

https://docs.openstack.org/infra/manual/zuulv3.html

...and we also have some more content in progress at:

https://etherpad.openstack.org/p/zuulv3-migration-faq

In summary, Zuul v3 is looking better than ever, and we hope you'll
be as pleased with it as we are!
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [oslo][mistral] Mistral expressions package

[HADDLETON, Robert W (Bob)]

On 10/9/2017 2:35 PM, Doug Hellmann wrote:

Excerpts from Bob Haddleton's message of 2017-10-09 11:35:16 -0500:

Hello Oslo team:

The Mistral project has an expressions package [0] that is used to
evaluate inline expressions using a context.  It has a pluggable
architecture that presently supports Jinja and YAQL expression
evaluation.  It also allows custom functions[1] to provide Python
implementations of functionality that is then made available to the
expression evaluation engines.

This functionality was originally developed to support dynamic
processing within Mistral workflows, but is also very useful in other
applications that use templates which require runtime evaluation of
expressions.

I'd like to explore extracting this functionality from mistral to make
it more widely available with minimal dependencies.

The expressions dependencies are pretty limited:

Jinja2
oslo.utils
oslo.log
stevedore
yaql

and since 60% are already oslo-maintained packages, it seemed like a
logical place to start.

I'd appreciate feedback on the topic.  There is no real OpenStack
dependency in the functionality, so maybe a standalone package on pypi
makes sense.

Thanks for your help,

Bob Haddleton


[0] https://github.com/openstack/mistral/tree/master/mistral/expressions
[1]
https://github.com/openstack/mistral/blob/master/mistral/utils/expression_utils.py#L63


Oslo is a good place for things like this that have no other obvious
home, but if the Mistral team is already managing the code is there any
reason they couldn't also manage the library after you pull it out of
the service? It's much easier for any project team to manage a library
now, and we have several other examples of that pattern already.

Doug

__
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

Hi Doug:

That's probably fine, we're just not sure what the process should be and 
where the library would land?  Do you have an example that we could use 
as a pattern?


Thanks

Bob

<>__
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] [Tripleo] Containerizing tempest

[Chandan kumar]

Hello,

I am planning to containerizing tempest for Tripleo.
Kolla project provides tempest kolla image [1.].
On a containerized Tripleo deployment, the Kolla tempest image will be
available on undercloud and the end user should able to run tempest
from there using tempest cli.

I need some help on how to proceed:
[1.] Where to make changes in Tripleo in order to make Kolla Tempest
image available on undercloud?
[2.] Since Tempest is not a service but an application, how to expose
tempest cli without tempest cli on undercloud without entering into
tempest kolla image?

Links:
[1.] https://github.com/openstack/kolla/tree/master/docker/tempest

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] Containerizing tempest

[Boris Pavlovic]

Chandan,

Not a big expert in Kola, but I have the same task for
containerizing  Rally.
The solution is simple, just use ENTRYPOINT like here:
https://github.com/openstack/rally/blob/master/Dockerfile#L38 (but for
tempest)


Best regards,
Boris Pavlovic

On Mon, Oct 9, 2017 at 10:08 PM, Chandan kumar  wrote:

> Hello,
>
> I am planning to containerizing tempest for Tripleo.
> Kolla project provides tempest kolla image [1.].
> On a containerized Tripleo deployment, the Kolla tempest image will be
> available on undercloud and the end user should able to run tempest
> from there using tempest cli.
>
> I need some help on how to proceed:
> [1.] Where to make changes in Tripleo in order to make Kolla Tempest
> image available on undercloud?
> [2.] Since Tempest is not a service but an application, how to expose
> tempest cli without tempest cli on undercloud without entering into
> tempest kolla image?
>
> Links:
> [1.] https://github.com/openstack/kolla/tree/master/docker/tempest
>
> 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
>
__
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