OpenStack - User contributions [en]

Consistent and Secure Default Policies Popup Team

2019-12-04T17:03:53Z

Ayoung: /* References */

== Problem Description ==

Existing policy defaults suffer from three major faults:

# the admin-ness problem: use of policy rules like 'is_admin' or hard-coded is-admin checks results in the admin-anywhere-admin-everywhere problem and drastically inhibits true multi-tenancy since by default customers cannot have admin rights on their own projects or domains
# insecure custom roles: many policy rules simply use "" as the rule, which means there is no rule: anyone can perform that action. This means creation of a custom role (say, "nova-autoscaler" requires editing every policy file across every service to block users with such a rule from performing actions unrelated to their role
# related to #2, no support for read-only roles: keystone now has a "reader" role that comes out of the box when keystone is bootstrapped, but it currently has very little value because of the use of empty rules in service policies: users with the "reader" role can still perform write actions on services if the policy rule for such an action is empty.

== Team Goal ==

The keystone project has migrated all of its default policies to 1) use oslo.policy's scope_types attribute, which allows the policy engine to understand "system scope" and distinguish between an admin role assignment on a project versus an admin role assignment on the entire system, 2) ensure all rules use one of the default roles (admin, member, and reader) which both ensures support for a read-only role and prevents custom roles from accidental over-permissiveness. Although the problems being solved are slightly different, the keystone team found it was easiest to migrate everything at once. The rest of the OpenStack services can use this migration as a template for securing their own policies.

== Popup Team Completion Criteria ==

This team will be disbanded after:

# The majority of the projects listed below have completed their policy migrations
# A document is published detailing any pitfalls, lessons learned, and best practices that other teams should be aware of
# A community goal is proposed and accepted by the TC

== Communication ==

Use topic:policy-popup in Gerrit.

Use subject tag [policy] for mailing list discussions.

Use #openstack-dev for synchronous discussions.

== Leads ==

# Colleen Murphy <colleen@gazlene.net> (cmurphy) [Seeking a replacement]
# Ghanshyam Mann <gmann@ghanshyammann.com> (gmann)

== Liaisons ==

* Barbican: Douglas Mendizábal (redrobot)
* Nova: Ghanshyam Mann (gmann)
* Neutron: Miguel Lavalle (mlavalle)
* Cinder: Brian Rosmaita (rosmaita)
* Cyborg: Yumeng Bao (yumeng_bao@yahoo.com)
* Manila: Goutham Pacha Ravi (gouthamr)

== Members ==

* Mohammed Naser <mnaser@vexxhost.com>
* Douglas Mendizábal (IRC: redrobot) - Barbican - We're supere interested in getting this implemented for Barbican
* Ade Lee (ade_lee) - barbican
* Miguel Lavalle (mlavalle) - neutron
* Chandan Kumar (chandankumar/raukadah)<chkumar@redhat.com> - Help on Tempest and Patrole side
* Akihiro Motoki (amotoki) - horizon (horizon needs to support the new mechanism of policy definitions. It is different from server side support, so the team needs to explore its own way)
* Tobias Rydberg (tobberydberg)
* Erik McCormick <emccormick@cirrusseven.com> (emccormick)
* Tergel Munkhbat tergel@fibo.cloud
* Ghanshyam Mann (gmann): Nova, QA adopt testing for the new roles.
* Vishakha Agarwal (vishakha)- Keystone

== Team Design Documents ==

=== Keystone (completed; use as a reference) ===

* http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-goals-and-roadmap.html
* https://bugs.launchpad.net/keystone/+bugs?field.status%3Alist=FIXRELEASED&field.tag=default-roles+system-scope&field.tags_combinator=ANY

=== Barbican ===

* https://wiki.openstack.org/wiki/Barbican/Policy

=== Nova ===

* https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/policy-defaults-refresh.html

=== Neutron ===

none yet

=== Cinder ===

none yet

=== Cyborg ===

none yet

=== Manila ===

none yet

== Progress ==

TBD - each project may have its own tracking mechanism, to be linked here

== Reviews ==

https://review.opendev.org/#/q/is:open+topic:policy-popup

== References ==

* All about scopes: https://docs.openstack.org/keystone/latest/contributor/services.html#authorization-scopes
* Default roles and scopes: https://docs.openstack.org/keystone/latest/admin/service-api-protection.html
* Tool to test custom policy : https://pagure.io/openstack-access-policy

Internship ideas

2016-09-12T02:22:24Z

Ayoung: /* Coding */

To submit new ideas please consider creating a new page and use the [[Template:InternshipIdea]] (instructions are provided on that page) and you can see how a [[Test idea|sample idea page]] would look like. The pages created with such template are listed on [[:Category:Internship_idea]].

= List of Ideas for Internships =

The OpenStack Foundation has multiple sources for internships, from [[Outreachy]] to [[:Category:GSoC|Google Summer of Code]] and other opportunities. This page collects the ideas for candidate interns to work on.

Applicants may not have ever worked on FLOSS before and have different levels of competence. Since we have different programs, add here ideas that can be completed by inexperienced contributors, developers or other fields (marketing, communication, graphic design, and anything that may be useful for OpenStack and to include new people in this community).

== Coding ==

{{InternshipIdea|
TITLE=Murano - Murano package validation tool |
DESCRIPTION=Murano cloud-ready applications are written in MuranoPL language and are packaged into zip packages, with certain prerequisites obligatory (manifest file, package structure, etc.). Having a murano package verification tool would speed up development and debugging of such apps greatly. Package verification tool should include tools for verifying that package structure is correct, all the class files mentioned in manifest file are present. It should also include MuranoPL linting code, to speed up MuranoPL-app development. Finally after the tool is ready — we should implement checks at import level (when importing a package to murano-api) and jobs at commit-time for murano-apps |
DIFFICULTY=Medium |
TOPICS=Murano |
SKILLS=Python |
EXTRA_SKILLS=YAML |
MENTORS=kzaitsev |
STATUS=Not Started |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Neutron - Metering agent add port statistics |
DESCRIPTION=Neutron the metering agent collects statistics regarding bandwidth usage. Right now it only measure the bandwidth used by routers. The idea is to extend it and provide statistics also for ports. In the first implementation only openvswitch will be supported, since we will use openvswitch tools to get the port statistics. The first step will be getting familiar with the metering agent and with Neutron in general. Then you will approach openvswitch tools and think about how to use them for this project. After that you can reach out to the community to collect and discuss ideas. Neutron folks are pretty active on #openstack-neutron channel most of the time and would be willing to share their opinions on this or any other project. You'll submit your code upstream and address the comments you get till your patch gets merged. |
DIFFICULTY=Medium-Advanced |
TOPICS=Neutron |
SKILLS=Python |
EXTRA_SKILLS=Networking, OVS |
MENTORS=rossella_s |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Neutron - ovsdb client monitor for Windows |
DESCRIPTION=The OVS agent monitors the ports that are added in the compute host to be able to wire them correctly. In Linux it uses the class InterfacePollingMinimizer that notifies the agent when a new port is plugged or unplugged and passes the related events (port added or deleted). For Windows it uses the class AlwaysPoll that doesn't notify any specific event, it returns always true. The OVS agent in Windows is forced to rescan the devices currently in the machine to infer which were added. This is because the current Windows implementation of the interface polling manager doesn't use ovsdb client monitor. The aim of this project is to use ovsdb client monitor also for Windows and make sure that the events are passed correctly to the OVS agent. This will improve the performance and will enable some clean up in the OVS agent code. The first step is getting familiar with the OVS agent and with Neutron in general. Then you will approach openvswitch tools and investigate how to use ovsdb monitor client in Windows. Neutron folks are pretty active on #openstack-neutron channel most of the time and would be willing to share their opinions on this or any other project. You'll submit your code upstream and address the comments you get till your patch gets merged. |
DIFFICULTY=Medium |
TOPICS=Neutron |
SKILLS=Python |
EXTRA_SKILLS=Networking, OVS |
MENTORS=rossella_s |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Glance - Extended support for requests library |
DESCRIPTION= You would be learning about glance-replicator, glance_store drivers and if time permits other modules. You are then expected to add support for requests library ( https://pypi.python.org/pypi/requests ) starting with glance-replicator. Although, supporting more than glance-replicator is not expected, more support you add the better your internship will be. You will also help with bug triage and optimizations around that code base as you add more support. |
DIFFICULTY=Medium |
TOPICS=Glance |
SKILLS=Python |
EXTRA_SKILLS=Good communication skills |
MENTORS=nikhil |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Glance - Develop a python based GLARE (GLance Artifacts REpository) client library and shell API |
DESCRIPTION= You will learn how python based clients are developed in the Openstack realm. You will be responsible for closely working with the Glare drivers to understand the requirements, API evolution and contribute ideas to the development of the Glare API. You should be able to set up the basic build structure, common interfaces, setup configs and infra jobs for the glareclient. Co-ordinate with the Glare drivers and infra team to setup repositories, documentation and test jobs for releases of this client. Also, based on the outcome and feedback from the Glare API discussions you will be responsible for keep evolving the client library. |
DIFFICULTY=Medium-Advanced |
TOPICS=Glance |
SKILLS=Python |
EXTRA_SKILLS=Shell scripting & packaging, good communication skills |
MENTORS=nikhil |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Searchlight - Extend automated functional testing for Searchlight plugins / Improve existing plugins |
DESCRIPTION= Searchlight is intended to dramatically improving the search capabilities and performance of various OpenStack cloud services by indexing their data into ElasticSearch using plugins. You will be learning the Searchlight fundamentals including indexing, searching, faceting, security, etc. You will also learn the APIs and data models of various other OpenStack services that are indexed into Searchlight. You will understand plugin design then explore all of the functional testing aspects mentioned above. You will be responsible for implementing complete coverage of functional testing for one big or two medium sized plugins. You will improve the existing plugins for any bugs or improvements you discover. |
DIFFICULTY=Medium |
TOPICS=Searchlight |
SKILLS=Python |
EXTRA_SKILLS=Basic understanding of ElasticSearch, good communication skills |
MENTORS=nikhil |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=OSprofiler - Implement new storage drivers for OSprofiler / add OSprofiler support to other OpenStack projects |
DESCRIPTION= OSprofiler is an Oslo library allowing to trace cross-project requests and identify the OpenStack performance bottlenecks via understanding what time was spent on each request stage, how many requests were used, etc. Lots of developing efforts might be found here, including writing new storage drivers for OSprofiler and adding its integration to other OpenStack projects. |
DIFFICULTY=Medium |
TOPICS=OSprofiler |
SKILLS=Python|
MENTORS=DinaBelova |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Magnum - Container Service for Magnum's Kubernetes Orchestration Engine |
DESCRIPTION= Magnum's client has several actions (create/delete/exec/logs/pause/reboot/start/stop/unpause) for containers, currently these commands work only for Docker Swarm COE. When a operator deploys a bay with either Kubernetes COE or the Mesos COE, these command line functionality is not available for the operator as there is not backend support for these operations. In this project, we will first add a concrete implementation for the Container Service that calls Kubernetes API appropriately, then we make sure that the magnum's client command lines work properly against this, just like this works when the operator deploys a bay using swarm COE. |
DIFFICULTY=Medium |
TOPICS=Magnum |
SKILLS=Python|
MENTORS=Dims |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Horizon- Context-sensitive help in openstack-dashboard|
DESCRIPTION=Context-sensitive Help allows the openstack-dashboard to dynamically provide users with links to relevant content, depending on the user's location in the dashboard (ie. their 'user context). This implementation should also allow developers to easily define links to serve for each specific context. For more details please check [https://blueprints.launchpad.net/horizon/+spec/context-sensitive-help this blueprint]|
DIFFICULTY=Medium|
TOPICS=Horizon|
SKILLS=Python|
EXTRA_SKILLS=Good communication skills|
MENTORS=sayalilunkad|
STATUS=Open|
PROGRAM=Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=[[#keystone-long-term-tokens | Keystone- Long Term Tokens ]]|
DESCRIPTION=We want to make a form of validation that will ignore expiration of tokens in order to support long running tasks.
DIFFICULTY=Easy. Shoulda been done already.
TOPICS=Keystone|
SKILLS=Python|
EXTRA_SKILLS=Keystone is its own thing, but we'll teach you|
MENTORS=ayoung|
STATUS=Open|
PROGRAM=Outreach May-Aug 2016
}}

== Documentation ==

{{InternshipIdea|
TITLE=Performance-docs - Add missing sections to http://docs.openstack.org/developer/performance-docs/# and identify the documentation gaps |
DESCRIPTION= Performance-docs is quite new initiative leaded and pushed by OpenStack Performance Working Group - https://wiki.openstack.org/wiki/Performance_Team - and we really need your help to work on adding test results, topologies and environments description, etc. to make this source valuable for all community. |
DIFFICULTY=Medium |
TOPICS=Performance-docs |
SKILLS=Good English and great communication skills to collect the information|
MENTORS=DinaBelova |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

[[Past internship ideas]]

[[Category: Internship]]

Meetings/KeystoneMeeting

2016-04-05T17:03:30Z

Ayoung: /* Main Agenda */

Meetings/KeystoneMeeting

2016-03-28T18:05:53Z

Ayoung: /* Main Agenda */

Meetings/KeystoneMeeting

2016-03-21T20:42:40Z

Ayoung: /* Main Agenda */

= Weekly Keystone team meeting =

If you're interested in identity, authentication, authorization, and/or policy for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, breton, browne, claudiub, davechen, david8hu, dolphm, dstanek, edmondsw, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, jorge_munoz, lbragstad, lhcheng, marekd, MaxPC, morganfainberg, nkinder, raildo, rodrigods, rderose, roxanaghe, samleon, samueldmq, shaleh, stevemar, tjcocozz, tsymanczyk, topol, vivekd, wanghong, xek

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

2016-03-22
* Keystone RC status - <code>stevemar</code>
** #link https://launchpad.net/keystone/+milestone/mitaka-rc1
* Docs - <code>stevemar</code>
** Use DocImpact again, it'll create a bug against keystone
** We can use that bug to create dev docs or retarget it against openstack-manuals if it affects install or other guides
** Always create release notes
* Define driver interface - <bknudson>
** Proposed review to document / define the driver interface - https://review.openstack.org/#/c/291950/
** Already ran into some oddities, like update_user behavior (raneme to same user doesn't raise).
** Worth it to continue on this? It's going to take a lot of work and no point if nobody's going to review it.
** Anybody else want to work on this with me?
* Opportunistic DB tests - <bknudson>
** See https://review.openstack.org/#/c/294246/ for WIP
* Specless bp for tempest plugin interface tests - <code>rodrigods</code>
** https://blueprints.launchpad.net/keystone/+spec/keystone-tempest-plugin-tests
* TLS Gate <code>rcritten</code> Discussion
** https://review.openstack.org/#/c/293090/
* Open discussion

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://openstack-weekly-reports.lbragstad.com/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].

Internship ideas

2016-03-08T23:01:12Z

Ayoung: /* Coding */

To submit new ideas please consider creating a new page and use the [[Template:InternshipIdea]] (instructions are provided on that page) and you can see how a [[Test idea|sample idea page]] would look like. The pages created with such template are listed on [[:Category:Internship_idea]].

= List of Ideas for Internships =

The OpenStack Foundation has multiple sources for internships, from [[Outreachy]] to [[:Category:GSoC|Google Summer of Code]] and other opportunities. This page collects the ideas for candidate interns to work on.

Applicants may not have ever worked on FLOSS before and have different levels of competence. Since we have different programs, add here ideas that can be completed by inexperienced contributors, developers or other fields (marketing, communication, graphic design, and anything that may be useful for OpenStack and to include new people in this community).

== Coding ==

{{InternshipIdea|
TITLE=Murano - Murano package validation tool |
DESCRIPTION=Murano cloud-ready applications are written in MuranoPL language and are packaged into zip packages, with certain prerequisites obligatory (manifest file, package structure, etc.). Having a murano package verification tool would speed up development and debugging of such apps greatly. Package verification tool should include tools for verifying that package structure is correct, all the class files mentioned in manifest file are present. It should also include MuranoPL linting code, to speed up MuranoPL-app development. Finally after the tool is ready — we should implement checks at import level (when importing a package to murano-api) and jobs at commit-time for murano-apps |
DIFFICULTY=Medium |
TOPICS=Murano |
SKILLS=Python |
EXTRA_SKILLS=YAML |
MENTORS=kzaitsev |
STATUS=Not Started |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Neutron - Metering agent add port statistics |
DESCRIPTION=Neutron the metering agent collects statistics regarding bandwidth usage. Right now it only measure the bandwidth used by routers. The idea is to extend it and provide statistics also for ports. In the first implementation only openvswitch will be supported, since we will use openvswitch tools to get the port statistics. The first step will be getting familiar with the metering agent and with Neutron in general. Then you will approach openvswitch tools and think about how to use them for this project. After that you can reach out to the community to collect and discuss ideas. Neutron folks are pretty active on #openstack-neutron channel most of the time and would be willing to share their opinions on this or any other project. You'll submit your code upstream and address the comments you get till your patch gets merged. |
DIFFICULTY=Medium-Advanced |
TOPICS=Neutron |
SKILLS=Python |
EXTRA_SKILLS=Networking, OVS |
MENTORS=rossella_s |
STATUS=None |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Neutron - ovsdb client monitor for Windows |
DESCRIPTION=The OVS agent monitors the ports that are added in the compute host to be able to wire them correctly. In Linux it uses the class InterfacePollingMinimizer that notifies the agent when a new port is plugged or unplugged and passes the related events (port added or deleted). For Windows it uses the class AlwaysPoll that doesn't notify any specific event, it returns always true. The OVS agent in Windows is forced to rescan the devices currently in the machine to infer which were added. This is because the current Windows implementation of the interface polling manager doesn't use ovsdb client monitor. The aim of this project is to use ovsdb client monitor also for Windows and make sure that the events are passed correctly to the OVS agent. This will improve the performance and will enable some clean up in the OVS agent code. The first step is getting familiar with the OVS agent and with Neutron in general. Then you will approach openvswitch tools and investigate how to use ovsdb monitor client in Windows. Neutron folks are pretty active on #openstack-neutron channel most of the time and would be willing to share their opinions on this or any other project. You'll submit your code upstream and address the comments you get till your patch gets merged. |
DIFFICULTY=Medium |
TOPICS=Neutron |
SKILLS=Python |
EXTRA_SKILLS=Networking, OVS |
MENTORS=rossella_s |
STATUS=None |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Glance - Extended support for requests library |
DESCRIPTION= You would be learning about glance-replicator, glance_store drivers and if time permits other modules. You are then expected to add support for requests library ( https://pypi.python.org/pypi/requests ) starting with glance-replicator. Although, supporting more than glance-replicator is not expected, more support you add the better your internship will be. You will also help with bug triage and optimizations around that code base as you add more support. |
DIFFICULTY=Medium |
TOPICS=Glance |
SKILLS=Python |
EXTRA_SKILLS=Good communication skills |
MENTORS=nikhil |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Glance - Develop a python based GLARE (GLance Artifacts REpository) client library and shell API |
DESCRIPTION= You will learn how python based clients are developed in the Openstack realm. You will be responsible for closely working with the Glare drivers to understand the requirements, API evolution and contribute ideas to the development of the Glare API. You should be able to set up the basic build structure, common interfaces, setup configs and infra jobs for the glareclient. Co-ordinate with the Glare drivers and infra team to setup repositories, documentation and test jobs for releases of this client. Also, based on the outcome and feedback from the Glare API discussions you will be responsible for keep evolving the client library. |
DIFFICULTY=Medium-Advanced |
TOPICS=Glance |
SKILLS=Python |
EXTRA_SKILLS=Shell scripting & packaging, good communication skills |
MENTORS=nikhil |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Searchlight - Extend automated functional testing for Searchlight plugins / Improve existing plugins |
DESCRIPTION= Searchlight is intended to dramatically improving the search capabilities and performance of various OpenStack cloud services by indexing their data into ElasticSearch using plugins. You will be learning the Searchlight fundamentals including indexing, searching, faceting, security, etc. You will also learn the APIs and data models of various other OpenStack services that are indexed into Searchlight. You will understand plugin design then explore all of the functional testing aspects mentioned above. You will be responsible for implementing complete coverage of functional testing for one big or two medium sized plugins. You will improve the existing plugins for any bugs or improvements you discover. |
DIFFICULTY=Medium |
TOPICS=Searchlight |
SKILLS=Python |
EXTRA_SKILLS=Basic understanding of ElasticSearch, good communication skills |
MENTORS=nikhil |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=OSprofiler - Implement new storage drivers for OSprofiler / add OSprofiler support to other OpenStack projects |
DESCRIPTION= OSprofiler is an Oslo library allowing to trace cross-project requests and identify the OpenStack performance bottlenecks via understanding what time was spent on each request stage, how many requests were used, etc. Lots of developing efforts might be found here, including writing new storage drivers for OSprofiler and adding its integration to other OpenStack projects. |
DIFFICULTY=Medium |
TOPICS=OSprofiler |
SKILLS=Python|
MENTORS=DinaBelova |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Magnum - Container Service for Magnum's Kubernetes Orchestration Engine |
DESCRIPTION= Magnum's client has several actions (create/delete/exec/logs/pause/reboot/start/stop/unpause) for containers, currently these commands work only for Docker Swarm COE. When a operator deploys a bay with either Kubernetes COE or the Mesos COE, these command line functionality is not available for the operator as there is not backend support for these operations. In this project, we will first add a concrete implementation for the Container Service that calls Kubernetes API appropriately, then we make sure that the magnum's client command lines work properly against this, just like this works when the operator deploys a bay using swarm COE. |
DIFFICULTY=Medium |
TOPICS=Magnum |
SKILLS=Python|
MENTORS=Dims |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Horizon- Context-sensitive help in openstack-dashboard|
DESCRIPTION=Context-sensitive Help allows the openstack-dashboard to dynamically provide users with links to relevant content, depending on the user's location in the dashboard (ie. their 'user context). This implementation should also allow developers to easily define links to serve for each specific context. For more details please check [https://blueprints.launchpad.net/horizon/+spec/context-sensitive-help this blueprint]|
DIFFICULTY=Medium|
TOPICS=Horizon|
SKILLS=Python|
EXTRA_SKILLS=Good communication skills|
MENTORS=sayalilunkad|
STATUS=Open|
PROGRAM=Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=[[#keystone-ldap | Keystone- LDAP Cleanup ]]|
DESCRIPTION=LDAP support is the last thing keeping Keystone from running on Python 3. In order to get there, we need to switch the LDAP code over to using a different LDAP Library, one that supportes Python3.
DIFFICULTY=Easy. Honest, its like a cakewalk|
TOPICS=Keystone|
SKILLS=Python|
EXTRA_SKILLS=LDAP will be learned, is not necessary ahead of time|
MENTORS=ayoung|
STATUS=Open|
PROGRAM=Outreach May-Aug 2016
}}

== Documentation ==

{{InternshipIdea|
TITLE=Performance-docs - Add missing sections to http://docs.openstack.org/developer/performance-docs/# and identify the documentation gaps |
DESCRIPTION= Performance-docs is quite new initiative leaded and pushed by OpenStack Performance Working Group - https://wiki.openstack.org/wiki/Performance_Team - and we really need your help to work on adding test results, topologies and environments description, etc. to make this source valuable for all community. |
DIFFICULTY=Medium |
TOPICS=Performance-docs |
SKILLS=Good English and great communication skills to collect the information|
MENTORS=DinaBelova |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

[[Past internship ideas]]

[[Category: Internship]]

Internship ideas

2016-03-08T22:57:28Z

Ayoung: /* Coding */

To submit new ideas please consider creating a new page and use the [[Template:InternshipIdea]] (instructions are provided on that page) and you can see how a [[Test idea|sample idea page]] would look like. The pages created with such template are listed on [[:Category:Internship_idea]].

= List of Ideas for Internships =

The OpenStack Foundation has multiple sources for internships, from [[Outreachy]] to [[:Category:GSoC|Google Summer of Code]] and other opportunities. This page collects the ideas for candidate interns to work on.

Applicants may not have ever worked on FLOSS before and have different levels of competence. Since we have different programs, add here ideas that can be completed by inexperienced contributors, developers or other fields (marketing, communication, graphic design, and anything that may be useful for OpenStack and to include new people in this community).

== Coding ==

{{InternshipIdea|
TITLE=Murano - Murano package validation tool |
DESCRIPTION=Murano cloud-ready applications are written in MuranoPL language and are packaged into zip packages, with certain prerequisites obligatory (manifest file, package structure, etc.). Having a murano package verification tool would speed up development and debugging of such apps greatly. Package verification tool should include tools for verifying that package structure is correct, all the class files mentioned in manifest file are present. It should also include MuranoPL linting code, to speed up MuranoPL-app development. Finally after the tool is ready — we should implement checks at import level (when importing a package to murano-api) and jobs at commit-time for murano-apps |
DIFFICULTY=Medium |
TOPICS=Murano |
SKILLS=Python |
EXTRA_SKILLS=YAML |
MENTORS=kzaitsev |
STATUS=Not Started |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Neutron - Metering agent add port statistics |
DESCRIPTION=Neutron the metering agent collects statistics regarding bandwidth usage. Right now it only measure the bandwidth used by routers. The idea is to extend it and provide statistics also for ports. In the first implementation only openvswitch will be supported, since we will use openvswitch tools to get the port statistics. The first step will be getting familiar with the metering agent and with Neutron in general. Then you will approach openvswitch tools and think about how to use them for this project. After that you can reach out to the community to collect and discuss ideas. Neutron folks are pretty active on #openstack-neutron channel most of the time and would be willing to share their opinions on this or any other project. You'll submit your code upstream and address the comments you get till your patch gets merged. |
DIFFICULTY=Medium-Advanced |
TOPICS=Neutron |
SKILLS=Python |
EXTRA_SKILLS=Networking, OVS |
MENTORS=rossella_s |
STATUS=None |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Neutron - ovsdb client monitor for Windows |
DESCRIPTION=The OVS agent monitors the ports that are added in the compute host to be able to wire them correctly. In Linux it uses the class InterfacePollingMinimizer that notifies the agent when a new port is plugged or unplugged and passes the related events (port added or deleted). For Windows it uses the class AlwaysPoll that doesn't notify any specific event, it returns always true. The OVS agent in Windows is forced to rescan the devices currently in the machine to infer which were added. This is because the current Windows implementation of the interface polling manager doesn't use ovsdb client monitor. The aim of this project is to use ovsdb client monitor also for Windows and make sure that the events are passed correctly to the OVS agent. This will improve the performance and will enable some clean up in the OVS agent code. The first step is getting familiar with the OVS agent and with Neutron in general. Then you will approach openvswitch tools and investigate how to use ovsdb monitor client in Windows. Neutron folks are pretty active on #openstack-neutron channel most of the time and would be willing to share their opinions on this or any other project. You'll submit your code upstream and address the comments you get till your patch gets merged. |
DIFFICULTY=Medium |
TOPICS=Neutron |
SKILLS=Python |
EXTRA_SKILLS=Networking, OVS |
MENTORS=rossella_s |
STATUS=None |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Glance - Extended support for requests library |
DESCRIPTION= You would be learning about glance-replicator, glance_store drivers and if time permits other modules. You are then expected to add support for requests library ( https://pypi.python.org/pypi/requests ) starting with glance-replicator. Although, supporting more than glance-replicator is not expected, more support you add the better your internship will be. You will also help with bug triage and optimizations around that code base as you add more support. |
DIFFICULTY=Medium |
TOPICS=Glance |
SKILLS=Python |
EXTRA_SKILLS=Good communication skills |
MENTORS=nikhil |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Glance - Develop a python based GLARE (GLance Artifacts REpository) client library and shell API |
DESCRIPTION= You will learn how python based clients are developed in the Openstack realm. You will be responsible for closely working with the Glare drivers to understand the requirements, API evolution and contribute ideas to the development of the Glare API. You should be able to set up the basic build structure, common interfaces, setup configs and infra jobs for the glareclient. Co-ordinate with the Glare drivers and infra team to setup repositories, documentation and test jobs for releases of this client. Also, based on the outcome and feedback from the Glare API discussions you will be responsible for keep evolving the client library. |
DIFFICULTY=Medium-Advanced |
TOPICS=Glance |
SKILLS=Python |
EXTRA_SKILLS=Shell scripting & packaging, good communication skills |
MENTORS=nikhil |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Searchlight - Extend automated functional testing for Searchlight plugins / Improve existing plugins |
DESCRIPTION= Searchlight is intended to dramatically improving the search capabilities and performance of various OpenStack cloud services by indexing their data into ElasticSearch using plugins. You will be learning the Searchlight fundamentals including indexing, searching, faceting, security, etc. You will also learn the APIs and data models of various other OpenStack services that are indexed into Searchlight. You will understand plugin design then explore all of the functional testing aspects mentioned above. You will be responsible for implementing complete coverage of functional testing for one big or two medium sized plugins. You will improve the existing plugins for any bugs or improvements you discover. |
DIFFICULTY=Medium |
TOPICS=Searchlight |
SKILLS=Python |
EXTRA_SKILLS=Basic understanding of ElasticSearch, good communication skills |
MENTORS=nikhil |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=OSprofiler - Implement new storage drivers for OSprofiler / add OSprofiler support to other OpenStack projects |
DESCRIPTION= OSprofiler is an Oslo library allowing to trace cross-project requests and identify the OpenStack performance bottlenecks via understanding what time was spent on each request stage, how many requests were used, etc. Lots of developing efforts might be found here, including writing new storage drivers for OSprofiler and adding its integration to other OpenStack projects. |
DIFFICULTY=Medium |
TOPICS=OSprofiler |
SKILLS=Python|
MENTORS=DinaBelova |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Magnum - Container Service for Magnum's Kubernetes Orchestration Engine |
DESCRIPTION= Magnum's client has several actions (create/delete/exec/logs/pause/reboot/start/stop/unpause) for containers, currently these commands work only for Docker Swarm COE. When a operator deploys a bay with either Kubernetes COE or the Mesos COE, these command line functionality is not available for the operator as there is not backend support for these operations. In this project, we will first add a concrete implementation for the Container Service that calls Kubernetes API appropriately, then we make sure that the magnum's client command lines work properly against this, just like this works when the operator deploys a bay using swarm COE. |
DIFFICULTY=Medium |
TOPICS=Magnum |
SKILLS=Python|
MENTORS=Dims |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Horizon- Context-sensitive help in openstack-dashboard|
DESCRIPTION=Context-sensitive Help allows the openstack-dashboard to dynamically provide users with links to relevant content, depending on the user's location in the dashboard (ie. their 'user context). This implementation should also allow developers to easily define links to serve for each specific context. For more details please check [https://blueprints.launchpad.net/horizon/+spec/context-sensitive-help this blueprint]|
DIFFICULTY=Medium|
TOPICS=Horizon|
SKILLS=Python|
EXTRA_SKILLS=Good communication skills|
MENTORS=sayalilunkad|
STATUS=Open|
PROGRAM=Outreach May-Aug 2016
}}

{{InternshipIdea|
TITLE=Keystone- LDAP Cleanup|
DESCRIPTION=LDAP support is the last thing keeping Keystone from running on Python 3. In order to get there, we need to switch the LDAP code over to using a different LDAP Library, one that supportes Python3.
DIFFICULTY=Easy. Honest, its like a cakewalk|
TOPICS=Keystone|
SKILLS=Python|
EXTRA_SKILLS=LDAP will be learned, is not necessary ahead of time|
MENTORS=ayoung|
STATUS=Open|
PROGRAM=Outreach May-Aug 2016
}}

== Documentation ==

{{InternshipIdea|
TITLE=Performance-docs - Add missing sections to http://docs.openstack.org/developer/performance-docs/# and identify the documentation gaps |
DESCRIPTION= Performance-docs is quite new initiative leaded and pushed by OpenStack Performance Working Group - https://wiki.openstack.org/wiki/Performance_Team - and we really need your help to work on adding test results, topologies and environments description, etc. to make this source valuable for all community. |
DIFFICULTY=Medium |
TOPICS=Performance-docs |
SKILLS=Good English and great communication skills to collect the information|
MENTORS=DinaBelova |
STATUS=Open |
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016
}}

[[Past internship ideas]]

[[Category: Internship]]

Meetings/KeystoneMeeting

2016-02-23T03:29:10Z

Ayoung: /* Agenda for next meeting */

Meetings/KeystoneMeeting

2016-02-02T16:33:11Z

Ayoung: /* Agenda for next meeting */

= Weekly Keystone team meeting =

If you're interested in identity, authentication, authorization, and/or policy for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek, MaxPC, tjcocozz

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

2016-02-02
* DocImpact <code>stevemar</code>
** using DocImpact will now create a bug against the keystone project
* ISO27001 Compliance <code>ayoung</code>
** Is SQL Backend compliance a requirement?
* Policy and RBAC <code>ayoung</code>
** Now that we have is_admin_project how do we deploy without breaking existing policy
** Can we do the equivalent of deprecations for the current policy.json file
** Can existing policy files should be limited to scope checks
** Can we layer new RBAC policy on top of existing policy without breaking?
** please approve Implied Roles. Any more nits should be filed as bugs. https://review.openstack.org/#/c/242614/
*** Expanding rules in the token can be disabled
*** Do we want to autogenerate a policy.json fragment?
*** Inference rules still required to break a large role down to smaller for least privilege.

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

* [https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller Return request Id to caller] <code>bknudson</code>

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://openstack-weekly-reports.lbragstad.com/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].

Meetings/KeystoneMeeting

2016-02-02T16:21:55Z

Ayoung: /* Main Agenda */

= Weekly Keystone team meeting =

If you're interested in identity, authentication, authorization, and/or policy for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek, MaxPC, tjcocozz

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

2016-02-02
* DocImpact <code>stevemar</code>
** using DocImpact will now create a bug against the keystone project
* Policy and RBAC <code>ayoung</code>
** Now that we have is_admin_project how do we deploy without breaking existing policy
** Can we do the equivalent of deprecations for the current policy.json file
** Can existing policy files should be limited to scope checks
** Can we layer new RBAC policy on top of existing policy without breaking?
** please approve Implied Roles. Any more nits should be filed as bugs. https://review.openstack.org/#/c/242614/
*** Expanding rules in the token can be disabled
*** Do we want to autogenerate a policy.json fragment?
*** Inference rules still required to break a large role down to smaller for least privilege.

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

* [https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller Return request Id to caller] <code>bknudson</code>

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://openstack-weekly-reports.lbragstad.com/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].

Meetings/KeystoneMeeting

2016-01-12T18:22:25Z

Ayoung: /* Main Agenda */

= Weekly Keystone team meeting =

If you're interested in identity, authentication, authorization, and/or policy for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rodrigods, roxanaghe, samueldmq, shaleh, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub, rderose, samleon, xek, MaxPC, tjcocozz

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

2016-01-12
* Bug 1490804: PKI Token Bypass <code>tjcocozz</code>
** Bug: https://bugs.launchpad.net/keystone/+bug/1490804
** Has a server side fix: https://review.openstack.org/#/q/Ifcf88f1158bebddc4f927121fbf4136fb53b659f,n,z
** Has a middleware fix: https://review.openstack.org/#/q/I483bc57bd38eb81a0905bcaf94e4ea82604919d6,n,z
** Can we make this change without making a fallback to using token_ids?
** Can we backport this without breaking folks that haven't updated their keystone?
** Affects Kilo and Liberty
* Bug 1527759: Revert domain ownership check <code>stevemar</code>
** Bug: https://bugs.launchpad.net/keystone/+bug/1527759
** Has a server side fix: https://review.openstack.org/#/q/I4a303a5fcc8c2dacef5960e9e26ad9402f34a790,n,z
** gyee has brought up issues with Swift and ACLs
** Affects Liberty only?
* v2 deprecation/v3 support<code>htruta, raildo</code>
** Where are we now? Tempest, make v3 default in devstack, make gate voting
** What can we do in Mitaka?
** Review: https://review.openstack.org/#/c/251530/
* Enforce token Bind based on Catalog<code>ayoung, gyee</code>
** Spec was approved https://github.com/openstack/keystone-specs/blob/master/specs/keystonemiddleware/endpoint-enforcement-middleware.rst
** Server side https://review.openstack.org/#/c/266137/
** Middleware side https://review.openstack.org/#/c/177661/

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

* [https://blueprints.launchpad.net/python-keystoneclient/+spec/return-request-id-to-caller Return request Id to caller] <code>bknudson</code>

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://openstack-weekly-reports.lbragstad.com/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].

Release Naming/N Proposals

2015-11-10T03:55:48Z

Ayoung: /* Proposed Names */

== N Release Naming ==

According to the [http://governance.openstack.org/reference/release-naming.html Release Naming Process], this page will contain a list of nominated names for the N release of OpenStack. We will accept nominations until 2015-11-15 23:59:59 UTC.

=== Release Name Criteria ===

* Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again.
* The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.
* The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process.
* The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so "Foo City" or "Foo Peak" would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may
make an exception for one or more of them to be considered in the
Condorcet poll. The naming official is responsible for presenting the
list of exceptional names for consideration to the TC before the poll
opens.

=== Exact Geographic Region ===

The Geographic Region from where names for the N release will come is the [https://en.wikipedia.org/wiki/Texas_Hill_Country Texas Hill Country]

=== Proposed Names ===
* Noxville, a ghost town in Kimble County [https://en.wikipedia.org/wiki/Noxville,_Texas]
* Nameless, a community in Travis County [https://www.tshaonline.org/handbook/online/articles/hrn39] (''After six names were rejected, residents wrote back saying, "Let the post office be nameless and be damned!" The department took them at their word.'')
* Nix, a ghost town in Lampasas Country [https://en.wikipedia.org/wiki/Nix,_Texas]
* Niederwald, located in Hays and Caldwell counties [https://en.wikipedia.org/wiki/Niederwald,_Texas], was established by German pioneers in the 1890’s. Built along the old Austin to San Antonio road known as the Camino Real
* Nueces, a river that runs through the Hill Country [https://en.wikipedia.org/wiki/Nueces_River]
* Null, Null Heights is a street in San Antonio, TX [https://www.google.com/maps/place/Null+Heights,+San+Antonio,+TX+78254/@29.522701,-98.6619825,18z/data=!4m2!3m1!1s0x865c6809e57308c7:0x94b6ec994231c66c]
* Nelson, Nelson Field is a stadium in Austin, TX [http://www.austintexas.org/listings/Nelson-Field/5750/]. Mostly Inspired by music scene in Austin including Willie Nelson [https://en.wikipedia.org/wiki/Willie_Nelson]
* Naruna, a small community about 70 miles northwest of Austin [https://tshaonline.org/handbook/online/articles/hnn01]
* Nada, a small town about 115 miles southeast of Austin [https://tshaonline.org/handbook/online/articles/HLn01]. The name is an American version of the Czechoslovakian word najda (hope)
* Nixon, a small town SE of San Antonio [https://en.wikipedia.org/wiki/Nixon,_Texas]
* Nacogdoches (Lake [https://tpwd.texas.gov/fishboat/fish/recreational/lakes/nacogdoches/])
* Nocona (Lake [https://tpwd.texas.gov/fishboat/fish/recreational/lakes/nocona/])
* Needle (Needle Peak [https://en.wikipedia.org/wiki/Needle_Peak_%28Presidio_County,_Texas%29])

Release Naming/N Proposals

2015-11-10T03:51:39Z

Ayoung: /* Proposed Names */

Release Naming/N Proposals

2015-11-10T03:49:56Z

Ayoung: /* Proposed Names */

Release Naming/N Proposals

2015-11-10T03:48:09Z

Ayoung: /* Proposed Names */

Release Naming/O Proposals

2015-11-10T03:40:15Z

Ayoung: /* Proposed Names */

== O Release Naming ==

According to the [http://governance.openstack.org/reference/release-naming.html Release Naming Process], this page will contain a list of nominated names for the O release of OpenStack. We will accept nominations until 2015-11-15 23:59:59 UTC.

=== Release Name Criteria ===

* Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again.
* The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.
* The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process.
* The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so "Foo City" or "Foo Peak" would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may
make an exception for one or more of them to be considered in the
Condorcet poll. The naming official is responsible for presenting the
list of exceptional names for consideration to the TC before the poll
opens.

=== Exact Geographic Region ===

The Geographic Region from where names for the O release will come is [https://en.wikipedia.org/wiki/Catalonia Catalonia]

=== Proposed Names ===
* Osona, a Catalan comarqua (district) and historic county [https://en.wikipedia.org/wiki/Osona] [https://www.flickr.com/photos/braid44/2189871003]
* Organyà, A Catalan municipality [https://en.wikipedia.org/wiki/Organy%C3%A0]
* Oliana, a Catalan municipality [https://en.wikipedia.org/wiki/Oliana]
* Olot, capital of the Catalan comarqua of Garrotxa [https://en.wikipedia.org/wiki/Olot] [http://www.catalonia-valencia.com/olot-catalonia-travel-guide.html]
* Ocean [https://en.wikipedia.org/wiki/Ocean] Catalonia is not on the Ocean, it is on the Mediterranian Sea.
* Osserà (town)
* Oristà (town)
* Odeillio (from Font Roma Odeillio-Via, in the French side of Catalonia.)
* Oveix (town)
* Orcau (town)
* Ogern (town)
* Oliona(town)
* Om (Carrer de l'Om)
* Ortigosa (Carrer de...)
* Ombriaga (mountain Puig d'Ombriaga)
* Obiol (mountain Puig de l'Obiol)
* Occitania, the unofficial region of Catalonia that speaks the Occitan language [https://en.wikipedia.org/wiki/Occitania]
* Ocata (Beach)

Release Naming/O Proposals

2015-11-10T02:46:31Z

Ayoung: /* Proposed Names */

Release Naming/O Proposals

2015-11-10T02:45:04Z

Ayoung: /* Proposed Names */

== O Release Naming ==

According to the [http://governance.openstack.org/reference/release-naming.html Release Naming Process], this page will contain a list of nominated names for the O release of OpenStack. We will accept nominations until 2015-11-15 23:59:59 UTC.

=== Release Name Criteria ===

* Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again.
* The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.
* The name must refer to the physical or human geography of the region encompassing the location of the OpenStack design summit for the corresponding release. The exact boundaries of the geographic region under consideration must be declared before the opening of nominations, as part of the initiation of the selection process.
* The name must be a single word with a maximum of 10 characters. Words that describe the feature should not be included, so "Foo City" or "Foo Peak" would both be eligible as "Foo".

Names which do not meet these criteria but otherwise sound really cool
should be added to a separate section of the wiki page and the TC may
make an exception for one or more of them to be considered in the
Condorcet poll. The naming official is responsible for presenting the
list of exceptional names for consideration to the TC before the poll
opens.

=== Exact Geographic Region ===

The Geographic Region from where names for the O release will come is [https://en.wikipedia.org/wiki/Catalonia Catalonia]

=== Proposed Names ===
* Osona, a Catalan comarqua (district) and historic county [https://en.wikipedia.org/wiki/Osona] [https://www.flickr.com/photos/braid44/2189871003]
* Organyà, A Catalan municipality [https://en.wikipedia.org/wiki/Organy%C3%A0]
* Oliana, a Catalan municipality [https://en.wikipedia.org/wiki/Oliana]
* Olot, capital of the Catalan comarqua of Garrotxa [https://en.wikipedia.org/wiki/Olot] [http://www.catalonia-valencia.com/olot-catalonia-travel-guide.html]
* Ocean [https://en.wikipedia.org/wiki/Ocean]
* Osserà
* Oristà
* Odeillio (from Font Roma Odeillio-Via, in the French side of Catalonia.)
* Oveix
* Orcau
* Ogern
* Oliona
* Om (Carrer de l'Om)
* Ortigosa (Carrer de...)
* Ombriaga (mountain Puig d'Ombriaga)
* Obiol (mountain Puig de l'Obiol)

Meetings/KeystoneMeeting

2015-10-12T20:17:16Z

Ayoung: /* Main Agenda */

= Weekly Keystone team meeting =

If you're interested in identity, authentication, authorization, and/or policy for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rharwood, rodrigods, roxanaghe, samueldmq, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

2015-10-13
* [from the previous meeting] For auth plugins in keystoneauth: Separate repo or use setuptools "extras"?
** https://review.openstack.org/#/c/177227/
* Functional tests in keystone - shall we hold on or start coding/revieving? <code>marekd</code>
* Supressing admin role for non-admin projects<code>ayoung</code>
** https://review.openstack.org/#/c/233480
** Solution to https://bugs.launchpad.net/keystone/+bug/968696

2015-10-06
* RC status <code>stevemar</code>
* Design session planning <code>stevemar</code>
* If you're interesting in asking operator questions <code>stevemar</code>
** Comment here: https://etherpad.openstack.org/p/TYO-ops-feedback-into-PWG
** Add this to your schedule: http://mitakadesignsummit.sched.org/event/1cdd373e1128b6c5f9536c00f461947a#.VhCyIhNVhBc
* Last call for Release Notes <code>stevemar</code>
** https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Identity_.28Keystone.29
* For auth plugins in keystoneauth: Separate repo or use setuptools "extras"?
** https://review.openstack.org/#/c/177227/

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

==== Roles ====
Please keep this as a standing topic until we have consensus on direction
* [https://blueprints.launchpad.net/keystone/+spec/virtual-roles Support for Virtual Roles]<code>henrynash, ayoung</code>

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].

Meetings/KeystoneMeeting

2015-10-06T17:53:37Z

Ayoung: /* Agenda for next meeting */

= Weekly Keystone team meeting =

If you're interested in identity, authentication, authorization, and/or policy for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, breton, browne, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rharwood, rodrigods, roxanaghe, samueldmq, stevemar, tsymanczyk, topol, vivekd, wanghong, claudiub

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

2015-10-06
* RC status <code>stevemar</code>
* Design session planning <code>stevemar</code>
* If you're interesting in asking operator questions <code>stevemar</code>
** Comment here: https://etherpad.openstack.org/p/TYO-ops-feedback-into-PWG
** Add this to your schedule: http://mitakadesignsummit.sched.org/event/1cdd373e1128b6c5f9536c00f461947a#.VhCyIhNVhBc
* Last call for Release Notes <code>stevemar</code>
** https://wiki.openstack.org/wiki/ReleaseNotes/Liberty#OpenStack_Identity_.28Keystone.29
* For auth plugins in keystoneauth: Separate repo or use setuptools "extras"?
** https://review.openstack.org/#/c/177227/

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

==== Roles ====
Please keep this as a standing topic until we have consensus on direction
* [https://blueprints.launchpad.net/keystone/+spec/virtual-roles Support for Virtual Roles]<code>henrynash, ayoung</code>

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].

2015-05-05T18:04:50Z

Ayoung: /* Registration */

Meetings/KeystoneMeeting

2015-05-05T18:02:03Z

Ayoung: /* Agenda for next meeting */

= Weekly Keystone team meeting =

If you're interested in identity for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

ajayaa, amakarov, ayoung, bknudson, breton, davechen, david8hu, dolphm, dstanek, ericksonsantos, geoffarnold, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, lbragstad, lhcheng, marekd, morganfainberg, nkinder, raildo, rharwood, rodrigods, roxanaghe, samueldmq, stevemar, topol, wanghong

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

*5/5
** Reminder: No Meeting 5/19 or 5/26 (Summit and Tuesday post summit) (<code>morganfainberg</code>)
** Midcyle Meetup Wiki Page: [[Sprints/KeystoneLibertySprint|Liberty MidCycle Meetup]] (<code>morganfainberg</code>, <code>ayoung</code>)
** First Pass on Summit Sessions: [https://libertydesignsummit.sched.org/type/design+summit/Keystone Summit Schedule Keystone Track] (<code>morganfainberg</code>)

==== Test Scripts ====
* posting upstream test scripts on etherpad
* example for HMT: https://etherpad.openstack.org/p/hierarchical-projects
* Need org structure

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].

Meetings/KeystoneMeeting

2015-04-27T18:04:06Z

Ayoung: /* Main Agenda */

= Weekly Keystone team meeting =

If you're interested in identity for OpenStack, we hold public meetings weekly on [[IRC]] in <code><nowiki>#openstack-meeting</nowiki></code>, on [https://www.google.com/search?q=current+utc+time Tuesdays at 18:00 UTC]. Please feel free to add items to the agenda below with your name and we'll cover them.

== Regular attendees ==

Add yourself to this list to be pinged prior to each meeting:

dolphm, ayoung, dstanek, jamielennox, morganfainberg, stevemar, gyee, henrynash, topol, marekd, lbragstad, joesavak, shardy, fabiog, nkinder, lloydm, shrekuma, ksavich, hrybacki, rharwood, grantbow, vdreamarkitex, raildo, rodrigods, amakarov, ajayaa, hogepodge, breton, lhcheng, nonameentername, samueldmq, htruta, amolock, wanghong, fmarco76, davechen, dims, ericksonsantos, erictchiu

== Agenda for next meeting ==

==== Main Agenda ====
Please add agenda items to the bottom of this section's list (be sure to include your <code>irc_handle</code>!).

4/28
* Rollcall (3 of 3)
** If you are not around for at least 1 roll call for the first 3 meetings of the cycle, your name will be trimmed from the "ping" list for this meeting
** Current new list: rodrigods, davechen, gyee, lbragstad, ayoung, morganfainberg, lhcheng, ajayaa, dstanek, dolphm, topol, joesavak, amakarov, henrynash, raildo, stevemar, htruta, marekd, david8hu, samueldmq, ericksonsantos, jamielennox, rharwood, raildo
* [https://etherpad.openstack.org/p/keystone-liberty-priority-specs Liberty Priorities] (<code>morganfainberg</code>)
* Dynamic Policy(<code>ayoung</code>)
** Hierarchical Roles Henry Nash has -2 on this...need to agree on the approach
** Fine grained API for modifying policy.
* [https://etherpad.openstack.org/p/Keystone-liberty-summit-brainstorm Summit planning] (<code>morganfainberg</code>)
* Midcycle Update (<code>ayoung</code>)
* For stevedore, should I assume no extensions? (<code>bknudson</code>)
** Affects https://review.openstack.org/#/c/166543/16/keystone/contrib/endpoint_policy/core.py
** Since not an extension, would use <code>keystone.endpoint_policy</code> instead of <code>keystone.contrib.endpoint_policy</code>
** Seems like it would be easier to do this now rather than later.

==== Review of Keystone Blueprints for No-Spec Requires Status ====
Please add BPs to the bottom of this sections list that should be reviewed as not requiring a spec (include your <code>irc_handle</code>!).

==== Keystone Weekly Bug Reports ====
Bugs for the various Keystone repositories are collects and published to the following links. (<code>lbragstad</code>)
* [http://keystone-weekly-bug-report.tempusfrangit.org/weekly-bug-reports/keystone-weekly-bug-report.html Keystone Weekly Bug Report]

== Previous meetings ==

Logs and meeting summaries of previous meetings are located [http://eavesdrop.openstack.org/meetings/keystone/ here].