https://wiki.openstack.org/w/api.php?action=feedcontributions&user=Rossella&feedformat=atomOpenStack - User contributions [en]2024-03-29T11:08:05ZUser contributionsMediaWiki 1.28.2https://wiki.openstack.org/w/index.php?title=Network/Meetings&diff=145075Network/Meetings2016-12-13T19:21:00Z<p>Rossella: </p>
<hr />
<div><br />
The OpenStack Networking Team ([[Neutron]]) holds public meetings as advertised on [http://eavesdrop.openstack.org/#Neutron_Team_Meeting OpenStack IRC Meetings Calendar]. If you are unable to attend, please check the most recent [http://eavesdrop.openstack.org/meetings/networking/ logs.]<br />
<br />
=== Announcements / Reminders ===<br />
<br />
* Allowing Teams Based on Vendor-specific Drivers http://lists.openstack.org/pipermail/openstack-dev/2016-November/108074.html<br />
<br />
=== Blueprints ===<br />
<br />
Current milestone: https://launchpad.net/neutron/+milestone/ocata-2<br />
<br />
==== OVO/no API downtime ====<br />
<br />
List here patches/topics that need core reviewer attention.<br />
<br />
* add your patch here<br />
<br />
=== Bugs and Gate issues ===<br />
<br />
Approximate stats for the current cycle:<br />
<br />
* From the beginning of Ocata (Sept-16-2016):<br />
** Total reports: '''329'''<br />
*** Fix released: '''170'''<br />
*** Unassigned: '''123'''<br />
**** New: '''27'''<br />
**** Incomplete: '''25'''<br />
**** Confirmed: '''26'''<br />
**** Triaged: '''4'''<br />
<br />
* [https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.tag=gate-failure Confirmed gate failures]<br />
* [https://bugs.launchpad.net/neutron/+bugs?field.tag=needs-attention Bugs that need attention]<br />
* [https://bugs.launchpad.net/neutron/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.tag=deprecation All bug reports associated to deprecation issues]<br />
* [https://goo.gl/KtEwbL Bugs Sheet]<br />
* [http://grafana.openstack.org/dashboard/db/neutron-failure-rate Grafana dashboards]<br />
<br />
==== Bug deputy ==== <br />
<br />
Use this section to keep track of who volunteers for the 'bug deputy' role. Instructions and pointers available at:<br />
<br />
http://docs.openstack.org/developer/neutron/policies/bugs.html#neutron-bug-deputy<br />
<br />
This is usually edited at the end of the IRC Meeting.<br />
<br />
Previous deputies in order per week: iharchys, regXboi, markmcclain, armax, mestery, mangelajo, garyk, rosella_s, dougwig, HenryG, carl_baldwin, amotoki, kevinbenton, amuller, Zzelle, mlavalle, njohnston, mhickey, rosella_s, dasm, scheuran, HenryG, Amotoki, reedip, blogan, dougwig, armax, regXboi, haleyb, hichihara, carl_baldwin, kevinbenton, mangelajo, dasm, john-davidge, rossella_s, johndperkins, blogan, mlavalle, jlibosva, electrocucaracha, njohnston, armax, haleyb, jschwarz, hichihara, ihrachys, ihrachys, dougwig, john-davidge, dasanind_, dasm, dougwig<br />
<br />
Next weeks:<br />
<br />
{| class="wikitable" style="text-align: center;"<br />
|-<br />
! Date !! who <br />
|-<br />
| Nov-7-2016 || andreas_s<br />
|-<br />
| Nov-14-2016 || electrocucaracha<br />
|-<br />
| Nov-21-2016 || kevinbenton<br />
|-<br />
| Nov-28-2016 || ihrachys<br />
|-<br />
| Dec-05-2016 || haleyb<br />
|-<br />
| Dec-12-2016 || mlavalle<br />
|-<br />
| Dec-12-2016 || john-davidge<br />
|-<br />
| Dec-26-2016 || armax<br />
|}<br />
<br />
=== Docs ===<br />
<br />
* The future of OpenStack documentation - http://lists.openstack.org/pipermail/openstack-dev/2016-July/099012.html<br />
* Documentation bugs - https://bugs.launchpad.net/neutron/+bugs?field.tag=doc<br />
<br />
=== Transition to OSC ===<br />
Status of changes to deliver OSC<br />
* http://docs.openstack.org/developer/python-neutronclient/devref/transition_to_osc.html<br />
<br />
=== Neutron-lib, planned refactoring and other impacts ===<br />
<br />
List here any planned potential disruption that may be caused by a new neutron-lib release and adoption of its latest features.<br />
<br />
* UpgradeImpact changes: https://review.openstack.org/#/q/status:open+message:%22UpgradeImpact%22+project:openstack/neutron<br />
* periodic neutron-lib check: http://grafana.openstack.org/dashboard/db/neutron-lib-failure-rate?panelId=4&fullscreen<br />
* Open issues: https://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%22<br />
* Past issues: https://review.openstack.org/#/q/status:merged+message:%22NeutronLibImpact%22<br />
* Removal of *_MAX_LEN constants, use db *_FIELD_SIZE constants from neutron-lib instead. (These reviews are based on top of remove-PLURALS reviews.)<br />
* Core patch: https://review.openstack.org/399891<br />
* Subprojects: https://review.openstack.org/#/q/status:open+topic:use-db-field-sizes<br />
* See also: http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.html<br />
* Removal of long-since deprecated model_base mixins from neutron core.<br />
* Core patch: https://review.openstack.org/403329<br />
* Subprojects: https://review.openstack.org/#/q/status:open+topic:use-lib-model_base<br />
* <Highlight patch(es) here for discussion><br />
<br />
=== On Demand Agenda ===<br />
<br />
We can only pick one or two topics we can talk in the time left of the meeting. People should add ideas to the topics section. We will select one or two topics we can chew during the next meeting. Please follow the template below:<br />
<br />
* Topic for the meeting (keep this template, please):<br />
** (your nickname): brief description.<br />
*** More details<br />
<br />
== Previous meeting logs ==<br />
* Previous meetings, with their notes and logs, can be found [http://eavesdrop.openstack.org/meetings/networking/ here].<br />
** [http://eavesdrop.openstack.org/meetings/networking/2016/?C=M;O=D networking-2016]<br />
** [http://eavesdrop.openstack.org/meetings/networking/2015/?C=M;O=D networking-2015]<br />
** [http://eavesdrop.openstack.org/meetings/networking/2014/?C=M;O=D networking-2014]<br />
** [http://eavesdrop.openstack.org/meetings/networking/2013/?C=M;O=D networking-2013]<br />
** [http://eavesdrop.openstack.org/meetings/quantum/2013/?C=M;O=D quantum-2013]<br />
** [http://eavesdrop.openstack.org/meetings/quantum/2012/?C=M;O=D quantum-2012]<br />
* Older meeting notes are here: ../MeetingLogs.</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=126338Meetings/Neutron-Upgrades-Subteam2016-06-06T15:30:28Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
** catch-all bug for OVO work created: https://bugs.launchpad.net/neutron/+bug/1541928<br />
* March code sprint<br />
** Sprint in Europe to speed up the adoption of OVO: March 14-16, Brno, Czech Republic, Red Hat office.<br />
*** etherpad with details: https://etherpad.openstack.org/p/code-sprint-neutron-objects-brno<br />
*** report: http://lists.openstack.org/pipermail/openstack-dev/2016-March/089769.html<br />
*** ML: http://lists.openstack.org/pipermail/openstack-dev/2016-January/085328.html<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** '''All patches tracked under 'ovo' topic:''' https://review.openstack.org/#/q/topic:ovo<br />
** Ongoing work:<br />
*** (rossella_s) WIP Port patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
*** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
*** (slunkad) WIP Port securitygroup extension https://review.openstack.org/#/c/275664/<br />
*** (electrocucaracha) WIP Flavor OVO https://review.openstack.org/#/c/306685<br />
*** (dguitarbite) port security<br />
*** (ihrachysk) Usage of SubnetPool OVO https://review.openstack.org/#/c/300056/<br />
** Done patches:<br />
*** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
*** (jlibosva) Add standard attributes to OVO objects https://review.openstack.org/#/c/292829/<br />
*** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
*** (rossella_s) handle synthetic fields in a general way: https://review.openstack.org/#/c/283711/<br />
*** (korzen) IPv6 mode field: https://review.openstack.org/273517<br />
*** (korzen) support for composite primary keys: https://review.openstack.org/275790<br />
*** (mhickey) Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
*** (electrocucaracha) SubnetPool OVO: https://review.openstack.org/#/c/275789/<br />
*** (hdaniel) rbac metaclass for objects: https://review.openstack.org/#/c/250081/<br />
*** (saisriki) IP address Custom types in Sqlalchemy for Neutron DB https://review.openstack.org/#/c/277558/<br />
*** (korzen) CIDR custom type in Sqlachemy: https://review.openstack.org/#/c/285349<br />
*** (saisriki) MACAddress custom type in Sqlalchemy: https://review.openstack.org/#/c/286347<br />
*** https://review.openstack.org/#/c/281850 Create a hook in base object to modify the fields before DB operations (korzen)<br />
<br />
<br />
* Other patches on review<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** rpc callbacks rolling upgrade Part 1: https://review.openstack.org/265347 (ajo)<br />
** rpc callbacks rolling upgrade Part 2: https://review.openstack.org/268040 (ajo)<br />
<br />
<br />
* Open discussion<br />
** Start working on using the Neutron objects in code base<br />
<br />
== Backlog ==<br />
* complete the sec group extensions object https://review.openstack.org/284738<br />
* complete the port object https://review.openstack.org/253641<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* Introduce the custom SQL types in Neutron database schema<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Object adoption check list =<br />
<br />
At the moment, the main focus of the team is on adoption of oslo.versionedobjects library for all database interactions. This is to open the door for alembic-less data migrations in next cycles.<br />
<br />
To adopt the library for a resource, the following should be made:<br />
* the object itself is introduced in the tree: https://review.openstack.org/#/c/275789/<br />
* the object is adopted in all database code that currently uses SQLAlchemy models directly: https://review.openstack.org/#/c/300056/<br />
* if the resource supports sorting/pagination on API level, corresponding API tests should be added BEFORE database code is switched to its object: https://review.openstack.org/#/c/306272/</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=126337Meetings/Neutron-Upgrades-Subteam2016-06-06T15:27:48Z<p>Rossella: /* Backlog */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
** catch-all bug for OVO work created: https://bugs.launchpad.net/neutron/+bug/1541928<br />
* March code sprint<br />
** Sprint in Europe to speed up the adoption of OVO: March 14-16, Brno, Czech Republic, Red Hat office.<br />
*** etherpad with details: https://etherpad.openstack.org/p/code-sprint-neutron-objects-brno<br />
*** report: http://lists.openstack.org/pipermail/openstack-dev/2016-March/089769.html<br />
*** ML: http://lists.openstack.org/pipermail/openstack-dev/2016-January/085328.html<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** '''All patches tracked under 'ovo' topic:''' https://review.openstack.org/#/q/topic:ovo<br />
** Ongoing work:<br />
*** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
*** (rossella_s) WIP Port patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
*** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
*** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
*** (slunkad) WIP Port securitygroup extension https://review.openstack.org/#/c/275664/<br />
*** (electrocucaracha) WIP Flavor OVO https://review.openstack.org/#/c/306685<br />
*** (jlibosva) Add standard attributes to OVO objects https://review.openstack.org/#/c/292829/<br />
*** (dguitarbite) port security<br />
*** (ihrachysk) Usage of SubnetPool OVO https://review.openstack.org/#/c/300056/<br />
** Done patches:<br />
*** (rossella_s) handle synthetic fields in a general way: https://review.openstack.org/#/c/283711/<br />
*** (korzen) IPv6 mode field: https://review.openstack.org/273517<br />
*** (korzen) support for composite primary keys: https://review.openstack.org/275790<br />
*** (mhickey) Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
*** (electrocucaracha) SubnetPool OVO: https://review.openstack.org/#/c/275789/<br />
*** (hdaniel) rbac metaclass for objects: https://review.openstack.org/#/c/250081/<br />
*** (saisriki) IP address Custom types in Sqlalchemy for Neutron DB https://review.openstack.org/#/c/277558/<br />
*** (korzen) CIDR custom type in Sqlachemy: https://review.openstack.org/#/c/285349<br />
*** (saisriki) MACAddress custom type in Sqlalchemy: https://review.openstack.org/#/c/286347<br />
*** https://review.openstack.org/#/c/281850 Create a hook in base object to modify the fields before DB operations (korzen)<br />
<br />
<br />
* Other patches on review<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** rpc callbacks rolling upgrade Part 1: https://review.openstack.org/265347 (ajo)<br />
** rpc callbacks rolling upgrade Part 2: https://review.openstack.org/268040 (ajo)<br />
<br />
<br />
* Open discussion<br />
** Start working on using the Neutron objects in code base<br />
<br />
== Backlog ==<br />
* complete the sec group extensions object https://review.openstack.org/284738<br />
* complete the port object https://review.openstack.org/253641<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* Introduce the custom SQL types in Neutron database schema<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Object adoption check list =<br />
<br />
At the moment, the main focus of the team is on adoption of oslo.versionedobjects library for all database interactions. This is to open the door for alembic-less data migrations in next cycles.<br />
<br />
To adopt the library for a resource, the following should be made:<br />
* the object itself is introduced in the tree: https://review.openstack.org/#/c/275789/<br />
* the object is adopted in all database code that currently uses SQLAlchemy models directly: https://review.openstack.org/#/c/300056/<br />
* if the resource supports sorting/pagination on API level, corresponding API tests should be added BEFORE database code is switched to its object: https://review.openstack.org/#/c/306272/</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Internship_ideas&diff=122469Internship ideas2016-03-17T13:05:31Z<p>Rossella: /* List of Ideas for Internships */</p>
<hr />
<div><!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas --><br />
<br />
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]].<br />
<br />
<br />
= List of Ideas for Internships =<br />
<br />
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. <br />
<br />
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).<br />
<br />
<br />
== Coding ==<br />
<br />
{{InternshipIdea|<br />
TITLE=Murano - Murano package validation tool |<br />
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 |<br />
DIFFICULTY=Medium |<br />
TOPICS=Murano |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=YAML |<br />
MENTORS=kzaitsev |<br />
STATUS=Not Started |<br />
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Neutron - Metering agent add port statistics |<br />
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. |<br />
DIFFICULTY=Medium-Advanced |<br />
TOPICS=Neutron |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Networking, OVS |<br />
MENTORS=rossella_s |<br />
STATUS=Open |<br />
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Neutron - ovsdb client monitor for Windows |<br />
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. |<br />
DIFFICULTY=Medium |<br />
TOPICS=Neutron |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Networking, OVS |<br />
MENTORS=rossella_s |<br />
STATUS=Open |<br />
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Glance - Extended support for requests library |<br />
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. |<br />
DIFFICULTY=Medium |<br />
TOPICS=Glance |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Good communication skills |<br />
MENTORS=nikhil |<br />
STATUS=Open |<br />
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Glance - Develop a python based GLARE (GLance Artifacts REpository) client library and shell API |<br />
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. |<br />
DIFFICULTY=Medium-Advanced |<br />
TOPICS=Glance |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Shell scripting & packaging, good communication skills |<br />
MENTORS=nikhil |<br />
STATUS=Open |<br />
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Searchlight - Extend automated functional testing for Searchlight plugins / Improve existing plugins |<br />
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. |<br />
DIFFICULTY=Medium |<br />
TOPICS=Searchlight |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Basic understanding of ElasticSearch, good communication skills |<br />
MENTORS=nikhil |<br />
STATUS=Open |<br />
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=OSprofiler - Implement new storage drivers for OSprofiler / add OSprofiler support to other OpenStack projects |<br />
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. |<br />
DIFFICULTY=Medium |<br />
TOPICS=OSprofiler |<br />
SKILLS=Python|<br />
MENTORS=DinaBelova |<br />
STATUS=Open |<br />
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Magnum - Container Service for Magnum's Kubernetes Orchestration Engine |<br />
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. |<br />
DIFFICULTY=Medium |<br />
TOPICS=Magnum |<br />
SKILLS=Python|<br />
MENTORS=Dims |<br />
STATUS=Open |<br />
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Horizon- Context-sensitive help in openstack-dashboard|<br />
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]|<br />
DIFFICULTY=Medium|<br />
TOPICS=Horizon|<br />
SKILLS=Python|<br />
EXTRA_SKILLS=Good communication skills|<br />
MENTORS=sayalilunkad|<br />
STATUS=Open|<br />
PROGRAM=Outreach May-Aug 2016<br />
}}<br />
<br />
<br />
{{InternshipIdea|<br />
TITLE=[[#keystone-ldap | Keystone- LDAP Cleanup ]]|<br />
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.<br />
DIFFICULTY=Easy. Honest, its like a cakewalk|<br />
TOPICS=Keystone|<br />
SKILLS=Python|<br />
EXTRA_SKILLS=LDAP will be learned, is not necessary ahead of time|<br />
MENTORS=ayoung|<br />
STATUS=Open|<br />
PROGRAM=Outreach May-Aug 2016<br />
}}<br />
<br />
== Documentation ==<br />
<br />
{{InternshipIdea|<br />
TITLE=Performance-docs - Add missing sections to http://docs.openstack.org/developer/performance-docs/# and identify the documentation gaps |<br />
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. |<br />
DIFFICULTY=Medium |<br />
TOPICS=Performance-docs |<br />
SKILLS=Good English and great communication skills to collect the information|<br />
MENTORS=DinaBelova |<br />
STATUS=Open |<br />
PROGRAM=Google Summer of Code 2016 / Outreach May-Aug 2016<br />
}}<br />
<br />
[[Past internship ideas]]<br />
<br />
[[Category: Internship]]</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=104548Meetings/Neutron-Upgrades-Subteam2016-02-19T11:33:18Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
** catch-all bug for OVO work created: https://bugs.launchpad.net/neutron/+bug/1541928<br />
* March code sprint<br />
** Sprint in Europe to speed up the adoption of OVO: March 14-16, Brno, Czech Republic, Red Hat office.<br />
*** etherpad with details: https://etherpad.openstack.org/p/code-sprint-neutron-objects-brno<br />
*** ML: http://lists.openstack.org/pipermail/openstack-dev/2016-January/085328.html<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
** (korzen) IPv6 mode field: https://review.openstack.org/273517<br />
** (korzen) support for composite primary keys: https://review.openstack.org/275790<br />
** (mhickey) Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
** (electrocucaracha) WIP SubnetPool OVO: https://review.openstack.org/#/c/275789/<br />
** (slunkad) WIP Port securitygroup extension https://review.openstack.org/#/c/275664/<br />
** (hdaniel) rbac metaclass for objects: https://review.openstack.org/#/c/250081/<br />
** (rossella_s) handle synthetic fields in a general way<br />
** (dguitarbite) port security<br />
** (saisriki) WIP for Custom types in Sqlalchemy for Neutron DB https://review.openstack.org/#/c/277558/<br />
* Other patches on review<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** rpc callbacks rolling upgrade Part 1: https://review.openstack.org/265347 (ajo)<br />
** rpc callbacks rolling upgrade Part 2: https://review.openstack.org/268040 (ajo)<br />
** https://review.openstack.org/#/c/281850 Create a hook in base object to modify the fields before DB operations (korzen)<br />
<br />
* Open discussion<br />
** how to move forward? Delay merges or create a branch for ovo work ?<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=104137Meetings/Neutron-Upgrades-Subteam2016-02-15T15:13:39Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
** catch-all bug for OVO work created: https://bugs.launchpad.net/neutron/+bug/1541928<br />
* March code sprint<br />
** Sprint in Europe to speed up the adoption of OVO: March 14-16, Brno, Czech Republic, Red Hat office.<br />
*** etherpad with details: https://etherpad.openstack.org/p/code-sprint-neutron-objects-brno<br />
*** ML: http://lists.openstack.org/pipermail/openstack-dev/2016-January/085328.html<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
** (korzen) IPv6 mode field: https://review.openstack.org/273517<br />
** (korzen) support for composite primary keys: https://review.openstack.org/275790<br />
** (mhickey) Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
** (electrocucaracha) WIP SubnetPool OVO: https://review.openstack.org/#/c/275789/<br />
** (slunkad) WIP Port securitygroup extension https://review.openstack.org/#/c/275664/<br />
** (hdaniel) rbac metaclass for objects: https://review.openstack.org/#/c/250081/<br />
** (rossella_s) handle synthetic fields in a general way<br />
** (dguitarbite) port security<br />
** (saisriki) WIP for Custom types in Sqlalchemy for Neutron DB https://review.openstack.org/#/c/277558/<br />
* Other patches on review<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** rpc callbacks rolling upgrade Part 1: https://review.openstack.org/265347 (ajo)<br />
** rpc callbacks rolling upgrade Part 2: https://review.openstack.org/268040 (ajo)<br />
<br />
* Open discussion<br />
** create a topic branch for OVO<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* create an hook to modify the object field before writing in the DB (see https://review.openstack.org/#/c/264273 )<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=102937Meetings/Neutron-Upgrades-Subteam2016-02-03T11:51:25Z<p>Rossella: /* Backlog */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
** Sprint in Europe to speed up the adoption of OVO?<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
**(mhickey) Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
** (dguitarbite) Port Security<br />
** (rossella_s) handle synthetic fields in a general way<br />
** (saisriki) take care of special DB fields like IPNetworkField the way Nova does, that is defining them like it's done in nova/db/sqlalchemy/types<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** https://review.openstack.org/#/c/273517 OVO common enum classes for IP version and IPv6 modes (korzen)<br />
** https://review.openstack.org/#/c/273072/ Port Extra Dhcp Opt to OVO (mhickey)<br />
* Open discussion<br />
** create an RFE bug for OVO work?<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* (korzen) SubnetPool OVO can be taken out of Subnet OVO patch - https://review.openstack.org/#/c/264273/10/neutron/objects/subnet.py<br />
* (korzen) Add support for multiple primary key support in base OVO<br />
* for the port object we still need the following extensions: security groups. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
* create an hook to modify the object field before writing in the DB (see https://review.openstack.org/#/c/264273 )<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=102936Meetings/Neutron-Upgrades-Subteam2016-02-03T11:48:30Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
** Sprint in Europe to speed up the adoption of OVO?<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
**(mhickey) Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
** (dguitarbite) Port Security<br />
** (rossella_s) handle synthetic fields in a general way<br />
** (saisriki) take care of special DB fields like IPNetworkField the way Nova does, that is defining them like it's done in nova/db/sqlalchemy/types<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** https://review.openstack.org/#/c/273517 OVO common enum classes for IP version and IPv6 modes (korzen)<br />
** https://review.openstack.org/#/c/273072/ Port Extra Dhcp Opt to OVO (mhickey)<br />
* Open discussion<br />
** create an RFE bug for OVO work?<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* (korzen) SubnetPool OVO can be taken out of Subnet OVO patch - https://review.openstack.org/#/c/264273/10/neutron/objects/subnet.py<br />
* (korzen) Add support for multiple primary key support in base OVO<br />
* for the port object we still need the following extensions: security groups. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
* handle composite keys in a general way (see https://review.openstack.org/#/c/264273)<br />
* create an hook to modify the object field before writing in the DB (see https://review.openstack.org/#/c/264273 )<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=102935Meetings/Neutron-Upgrades-Subteam2016-02-03T11:45:45Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
** Sprint in Europe to speed up the adoption of OVO?<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
**(mhickey) Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
** (dguitarbite) Port Security<br />
** (rossella_s) handle synthetic fields in a general way <br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** https://review.openstack.org/#/c/273517 OVO common enum classes for IP version and IPv6 modes (korzen)<br />
** https://review.openstack.org/#/c/273072/ Port Extra Dhcp Opt to OVO (mhickey)<br />
* Open discussion<br />
** create an RFE bug for OVO work?<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* (korzen) SubnetPool OVO can be taken out of Subnet OVO patch - https://review.openstack.org/#/c/264273/10/neutron/objects/subnet.py<br />
* (korzen) Add support for multiple primary key support in base OVO<br />
* for the port object we still need the following extensions: security groups. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
* take care of special DB fields like IPNetworkField the way Nova does, that is defining them like it's done in nova/db/sqlalchemy/types<br />
* handle composite keys in a general way (see https://review.openstack.org/#/c/264273)<br />
* create an hook to modify the object field before writing in the DB (see https://review.openstack.org/#/c/264273 )<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=102934Meetings/Neutron-Upgrades-Subteam2016-02-03T11:45:20Z<p>Rossella: /* Backlog */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
** Sprint in Europe to speed up the adoption of OVO?<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
**(mhickey) Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
** (dguitarbite) Port Security<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** https://review.openstack.org/#/c/273517 OVO common enum classes for IP version and IPv6 modes (korzen)<br />
** https://review.openstack.org/#/c/273072/ Port Extra Dhcp Opt to OVO (mhickey)<br />
* Open discussion<br />
** create an RFE bug for OVO work?<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* (korzen) SubnetPool OVO can be taken out of Subnet OVO patch - https://review.openstack.org/#/c/264273/10/neutron/objects/subnet.py<br />
* (korzen) Add support for multiple primary key support in base OVO<br />
* for the port object we still need the following extensions: security groups. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
* take care of special DB fields like IPNetworkField the way Nova does, that is defining them like it's done in nova/db/sqlalchemy/types<br />
* handle composite keys in a general way (see https://review.openstack.org/#/c/264273)<br />
* create an hook to modify the object field before writing in the DB (see https://review.openstack.org/#/c/264273 )<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=102933Meetings/Neutron-Upgrades-Subteam2016-02-03T11:42:52Z<p>Rossella: /* Backlog */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
** Sprint in Europe to speed up the adoption of OVO?<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
**(mhickey) Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
** (dguitarbite) Port Security<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** https://review.openstack.org/#/c/273517 OVO common enum classes for IP version and IPv6 modes (korzen)<br />
** https://review.openstack.org/#/c/273072/ Port Extra Dhcp Opt to OVO (mhickey)<br />
* Open discussion<br />
** create an RFE bug for OVO work?<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* (korzen) SubnetPool OVO can be taken out of Subnet OVO patch - https://review.openstack.org/#/c/264273/10/neutron/objects/subnet.py<br />
* (korzen) Add support for multiple primary key support in base OVO<br />
* for the port object we still need the following extensions: security groups. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
* take care of special DB fields like IPNetworkField the way Nova does, that is defining them like it's done in nova/db/sqlalchemy/types<br />
* handle composite keys in a general way (see https://review.openstack.org/#/c/264273)<br />
* handle synthetic fields in a general way <br />
* create an hook to modify the object field before writing in the DB (see https://review.openstack.org/#/c/264273 )<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=102585Meetings/Neutron-Upgrades-Subteam2016-02-01T16:17:40Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
** Sprint in Europe to speed up the adoption of OVO?<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
**(mhickey) WIP Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
** (dguitarbite) Port Security<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** https://review.openstack.org/#/c/273517 OVO common enum classes for IP version and IPv6 modes (korzen)<br />
* Open discussion<br />
** create an RFE bug for OVO work?<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* (korzen) SubnetPool OVO can be taken out of Subnet OVO patch - https://review.openstack.org/#/c/264273/10/neutron/objects/subnet.py<br />
* (korzen) Add support for multiple primary key support in base OVO<br />
* for the port object we still need the following extensions: security groups. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=102396Meetings/Neutron-Upgrades-Subteam2016-01-28T15:08:30Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
** Sprint in Europe to speed up the adoption of OVO?<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/264273<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
**(mhickey) WIP Port Extra Dhcp Opt to OVO: https://review.openstack.org/#/c/273072/<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/#/c/270309/ Update Neutron with temporary registry pattern from VersionedObjectRegistry (mhickey, depends on new o.vo release)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
** https://review.openstack.org/#/c/273517 OVO common enum classes for IP version and IPv6 modes (korzen)<br />
* Open discussion<br />
** create an RFE bug for OVO work?<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* for the port object we need to port several extension: security groups, port security. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=101898Meetings/Neutron-Upgrades-Subteam2016-01-22T09:43:56Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
** Sprint in Europe to speed up the adoption of OVO?<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/269056<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/248190 has_offline_migrations CLI for neutron-db-manage (mhickey, WIP)<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/258026 versioned objects hasher test (mhickey)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
* Open discussion<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* for the port object we need to port several extension: security groups, port security, extra dhcp opt. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=101897Meetings/Neutron-Upgrades-Subteam2016-01-22T09:43:32Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
** Sprint in Europe to speed up the adoption of ovo?<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** (korzen) WIP Subnet OVO: https://review.openstack.org/#/c/269056<br />
** (korzen) WIP Network OVO: https://review.openstack.org/#/c/269658<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/248190 has_offline_migrations CLI for neutron-db-manage (mhickey, WIP)<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/258026 versioned objects hasher test (mhickey)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
** https://review.openstack.org/#/c/269056 Add Oslo Version serializer for RPC messages (korzen)<br />
* Open discussion<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* for the port object we need to port several extension: security groups, port security, extra dhcp opt. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=101450Meetings/Neutron-Upgrades-Subteam2016-01-18T15:12:53Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** network (korzen): too complex subtree to unravel; we need the tree documented to move the ball<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/248190 has_offline_migrations CLI for neutron-db-manage (mhickey, WIP)<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/258026 versioned objects hasher test (mhickey)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
** https://review.openstack.org/#/c/268273/ Handle OVO that don't have ID as primary key (rossella_s)<br />
* Open discussion<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* for the port object we need to port several extension: security groups, port security, extra dhcp opt. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=101447Meetings/Neutron-Upgrades-Subteam2016-01-18T13:49:23Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** network (korzen): too complex subtree to unravel; we need the tree documented to move the ball<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/248190 has_offline_migrations CLI for neutron-db-manage (mhickey, WIP)<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/258026 versioned objects hasher test (mhickey)<br />
** https://review.openstack.org/#/c/268274/ allowed address pais extension (rossella_s)<br />
* Open discussion<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* for the port object we need to port several extension: security groups, port security, extra dhcp opt. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=101446Meetings/Neutron-Upgrades-Subteam2016-01-18T13:47:53Z<p>Rossella: /* Agenda */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
<br />
* Apologies for Absence<br />
* Announcements<br />
* Organisational matters<br />
* Partial Multinode Grenade (assert:supports-rolling-upgrade)<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
** LP bug: https://bugs.launchpad.net/neutron/+bug/1527675<br />
* Object implementation<br />
** (rossella_s) allowed address pairs extension ported to OVO https://review.openstack.org/#/c/268274/ <br />
** (rossella_s) WIP patch https://review.openstack.org/#/c/253641/ tests are passing, more extensions need to be ported, see backlog<br />
** network (korzen): too complex subtree to unravel; we need the tree documented to move the ball<br />
* Patches on review<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (merged). Need to ask @ajo if there is code to review.<br />
** https://review.openstack.org/248190 has_offline_migrations CLI for neutron-db-manage (mhickey, WIP)<br />
** https://review.openstack.org/#/c/253641/ port object (rossella, very WIP)<br />
** https://review.openstack.org/258026 versioned objects hasher test (mhickey)<br />
* Open discussion<br />
** data disruption issues with features that integrate with ovs agent on agent restart: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Backlog ==<br />
* think of validating migration rules with real resources (there should be an oslo.db fixture for that);<br />
* investigate the list of resources we migrate in grenade, maybe add more;<br />
* job that runs expand from master, then leave the cloud on N-1 release and run tempest;<br />
* for the port object we need to port several extension: security groups, port security, extra dhcp opt. An example of porting an extension https://review.openstack.org/#/c/268274/<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Meetings/Neutron-Upgrades-Subteam&diff=98849Meetings/Neutron-Upgrades-Subteam2015-12-04T18:35:34Z<p>Rossella: /* Meeting November 30th, 2015 */</p>
<hr />
<div><br />
= Meetings =<br />
<br />
* Weekly on Mon at 1500 UTC<br />
* IRC channel: <code><nowiki>#openstack-meeting-alt</nowiki></code> on [https://freenode.net/ freenode]<br />
* Chair: Ihar Hrachyshka (ihrachys)<br />
* Meetings, with their notes and logs, will be found under http://eavesdrop.openstack.org/meetings/neutron_upgrades<br />
<br />
= Agenda =<br />
<br />
== Meeting November 30th, 2015 ==<br />
* Apologies for Absence<br />
** Ihar Hrachyshka: will be offline all the week<br />
* Announcements<br />
** upgrade tags added to governance repo: assert:supports-upgrade https://review.openstack.org/239771 assert:supports-rolling-upgrade: https://review.openstack.org/239778<br />
* Organisational matters<br />
** Do we need a Launchpad tag?<br />
* Partial Multinode Grenade<br />
** email thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/079344.html<br />
** first experimental results: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080503.html<br />
* Object implementation<br />
** Ihar talked to Armando on how we proceed with OVO adoption: no spec needed, RFE may not be needed; devref documenting conversion process is required; one or two objects to be chosen for Mitaka cycle<br />
** port (rossella) WIP patch https://review.openstack.org/#/c/253641/<br />
** network (korzen)<br />
* Patches on review<br />
** https://review.openstack.org/246242 adding assert:supports-upgrade tag to neutron (merged)<br />
** https://review.openstack.org/245862 adding multinode grenade job to experimental (merged)<br />
** https://review.openstack.org/241687 devref page on upgrades (merged)<br />
** https://review.openstack.org/241154 devref update with the upgrade plan for RPC callbacks (ready to merge)<br />
** https://review.openstack.org/248190 has_offline_migrations CLI for neutron-db-manage (WIP)<br />
** https://review.openstack.org/#/c/253641/ port object (very WIP)<br />
* Open discussion<br />
** [ihrachys] some attention in terms of data plane non-disruption on OVS agent restart (upgrade) is due for: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081264.html<br />
<br />
== Meeting commands ==<br />
<br />
<nowiki>/join #openstack-meeting-alt</nowiki><br /><br />
<nowiki>#startmeeting neutron_upgrades</nowiki><br /><br />
<nowiki>#topic Announcements</nowiki><br /><br />
<nowiki>#undo topic</nowiki><br /><br />
<nowiki>#link https://wiki.openstack.org/wiki/Meetings/Neutron-Upgrades-Subteam</nowiki><br /><br />
<nowiki> #action ihrachys will get something specific done this week</nowiki><br /><br />
<nowiki>#endmeeting</nowiki><br /><br />
<br />
= Sub-team Charter =<br />
<br />
Enhances the upgrade story for Neutron (all things upgrade: cold, rolling, alembic, grenade, ...).<br />
<br />
= Bugs =<br />
<br />
== Critical ==<br />
<br />
== High ==</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Internship_ideas&diff=95522Internship ideas2015-11-04T14:46:49Z<p>Rossella: </p>
<hr />
<div><!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas --><br />
<br />
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]].<br />
<br />
= List of Ideas for Internships =<br />
<br />
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. <br />
<br />
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).<br />
<br />
== Coding ==<br />
<br />
{{InternshipIdea|<br />
TITLE=Trove - Users and databases CRUD operations for CouchDB |<br />
DESCRIPTION=Add basic support for user and databases management in CouchDB |<br />
DIFFICULTY=Medium |<br />
TOPICS=Trove |<br />
SKILLS=Python |<br />
EXTRA_SKILLS= NoSQL |<br />
MENTORS=vkmc |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Zaqar - Implement support for binary data in the websocket transport |<br />
DESCRIPTION=Enable Zaqar to store and forward messages with binary content through the websocket transport |<br />
DIFFICULTY=Medium |<br />
TOPICS=Zaqar |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Websocket |<br />
MENTORS=vkmc |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Murano - Implementation of tagging heat stacks, created by murano |<br />
DESCRIPTION=Allow attributing a set of simple string-based tags to stacks to easily manage their life-cycle. |<br />
DIFFICULTY=Medium |<br />
TOPICS=Murano |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=REST API|<br />
MENTORS=efedorova |<br />
STATUS=Started |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Murano - Full i18n and l10n support for murano projects |<br />
DESCRIPTION=Allow users of murano, murano-dashboard, python-muranoclient, and murano-agent to translate messages using translate.openstack.org and import translated messages, to allow them to use murano in their own language |<br />
DIFFICULTY=Medium |<br />
TOPICS=Murano |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Unicode|<br />
MENTORS=kzaitsev |<br />
STATUS=Not Started |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Sahara - Improve anti-affinity behavior for cluster creation |<br />
DESCRIPTION=Enable sahara to distribute node creation in a more equitable manner with respect to compute hardware affinity. This will involve examining how sahara currently places nodes requesting anti-affinity into a server group, and then creating a solution for distributing the requested nodes. One possibility is for sahara to create more server groups and place nodes in those groups in a round-robin fashion. |<br />
DIFFICULTY=Medium-Advanced |<br />
TOPICS=Sahara |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Distributed computing |<br />
MENTORS=elmiko |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Neutron - Metering agent add port statistics |<br />
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. |<br />
DIFFICULTY=Medium-Advanced |<br />
TOPICS=Neutron |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Networking, OVS |<br />
MENTORS=rossella_s |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Neutron - ovsdb client monitor for Windows |<br />
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. |<br />
DIFFICULTY=Medium |<br />
TOPICS=Neutron |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Networking, OVS |<br />
MENTORS=rossella_s |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Neutron - Pluggable IPAM support for host-dependent IP address allocation |<br />
DESCRIPTION=Some use cases would like the IP address(es) that Neutron allocates to a VM to depend on the compute host that Nova chooses for that VM. For example, in the Calico approach where data is routed between compute hosts, it's desirable for the IP addresses that are used on a given host (or rack) to be clustered within a small IP prefix, so that the routes to those IP addresses can be aggregated. Neutron's new pluggable IPAM facility is the main ingredient needed for this, but two other ingredients are needed as well. (1) Review, understanding and enhancement of the port setup exchange between Nova and Neutron, such that Neutron can choose an IP address _after_ Nova has chosen the compute host. (2) Design and coding of a way to pass the chosen host into the pluggable IPAM module, so that the module can take the host into account. Demonstration of this all working will also require (3) A sample pluggable IPAM module that allocates IP addresses in some host-aware way.<br />
<br />
This is a challenging but interesting project. Stages of the work will include becoming familiar with the relevant parts of Neutron; writing a spec for the work, and evolving this as feedback is received; and coding, and again evolving this as comments are received, until it's all done! |<br />
DIFFICULTY=Medium-Advanced |<br />
TOPICS=Neutron |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Networking |<br />
MENTORS=neiljerram |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
[[Past internship ideas]]<br />
<br />
[[Category: Internship]]</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Internship_ideas&diff=92051Internship ideas2015-10-08T20:43:12Z<p>Rossella: /* Coding */</p>
<hr />
<div><!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas --><br />
<br />
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]].<br />
<br />
= List of Ideas for Internships =<br />
<br />
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. <br />
<br />
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).<br />
<br />
== Coding ==<br />
<br />
{{InternshipIdea|<br />
TITLE=Trove - Users and databases CRUD operations for CouchDB |<br />
DESCRIPTION=Add basic support for user and databases management in CouchDB |<br />
DIFFICULTY=Medium |<br />
TOPICS=Trove |<br />
SKILLS=Python |<br />
EXTRA_SKILLS= NoSQL |<br />
MENTORS=vkmc |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Zaqar - Implement support for binary data in the websocket transport |<br />
DESCRIPTION=Enable Zaqar to store and forward messages with binary content through the websocket transport |<br />
DIFFICULTY=Medium |<br />
TOPICS=Zaqar |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Websocket |<br />
MENTORS=vkmc |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Murano - Implementation of tagging heat stacks, created by murano |<br />
DESCRIPTION=Allow attributing a set of simple string-based tags to stacks and optionally the ability to hide stacks with certain tags by default |<br />
DIFFICULTY=Medium |<br />
TOPICS=Murano |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=REST API|<br />
MENTORS=efedorova |<br />
STATUS=Started |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Sahara - Improve anti-affinity behavior for cluster creation |<br />
DESCRIPTION=Enable sahara to distribute node creation in a more equitable manner with respect to compute hardware affinity. This will involve examining how sahara currently places nodes requesting anti-affinity into a server group, and then creating a solution for distributing the requested nodes. One possibility is for sahara to create more server groups and place nodes in those groups in a round-robin fashion. |<br />
DIFFICULTY=Medium-Advanced |<br />
TOPICS=Sahara |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Distributed computing |<br />
MENTORS=elmiko |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
{{InternshipIdea|<br />
TITLE=Neutron - Metering agent add port statistics |<br />
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. |<br />
DIFFICULTY=Medium-Advanced |<br />
TOPICS=Neutron |<br />
SKILLS=Python |<br />
EXTRA_SKILLS=Networking, OVS |<br />
MENTORS=rossella_s |<br />
STATUS=None |<br />
PROGRAM=Outreach Dec-Apr 2016<br />
}}<br />
<br />
[[Past internship ideas]]<br />
<br />
[[Category: Internship]]</div>Rossellahttps://wiki.openstack.org/w/index.php?title=FeatureFreeze&diff=75939FeatureFreeze2015-03-19T16:26:02Z<p>Rossella: /* Exception procedure */</p>
<hr />
<div>__NOTOC__<br />
[[FeatureFreeze]] (FF) happens when we tag the last development milestone in a cycle. It generally happens between the Tuesday and the Thursday on the corresponding milestone delivery week.<br />
<br />
=== Freeze ===<br />
<br />
Once FF kicks in, you are no longer allowed to accept proposed changes containing new features into the current development release. Such proposed changes should be rejected by the review team and postponed until the next series development opens (which should happen when RC1 is published).<br />
<br />
=== Rationale ===<br />
<br />
FF ensures that sufficient share of the [[ReleaseCycle]] is dedicated to QA, until we produce the first release candidates. Limiting the changes that affect the behavior of the software allow for consistent testing and efficient bugfixing.<br />
<br />
=== Exception procedure ===<br />
<br />
If you want to propose changes containing a feature (that you believe has an acceptable importance/risk_of_regression ratio) for merging into the development release after FF, follow those steps:<br />
<br />
* Make sure all your change has thorough unit tests, ''especially'' if your patch touches an area of the code that currently is not well-tested<br />
* Make sure the proposed change is linked to the associated blueprint (if any)<br />
* Propose your change for merging<br />
* In a specific comment on the review, provide the following information:<br />
** Benefit of the change<br />
** Risk of regression<br />
* In the review, request the advice of the Release Manager by adding his name using "Add reviewer"<br />
<br />
<br />
Feature Freeze exceptions have 4 dimensions to consider:<br />
* how disruptive the change is (and therefore likely to break other teams that try to test the RC)<br />
* how much time it will take (and therefore likely to disrupt other teams for a longer time)<br />
* how many FFE there are for one project (since that will distract reviewers from RC bugfixing/testing)<br />
* finally, how broken the release is without it<br />
<br />
<br />
You can check who is the current Release Manager by looking at the current [[Releases|Release schedule]].<br />
<br />
The Release manager, with the assistance of the core developers of the associated product, will evaluate the request and grant or deny the exception. The farther we are in the release cycle, the less likely it is for the exception to be granted. Remember that the next cycle is just a month away :)<br />
<br />
[[Category: ContribDocs]]</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Internship_ideas&diff=75187Internship ideas2015-03-06T17:29:59Z<p>Rossella: </p>
<hr />
<div><!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas --><br />
= Outreachy Ideas List =<br />
<br />
The GNOME Foundation provides an outreach program for women. You can learn more here: https://www.gnome.org/outreachy/.<br />
<br />
OpenStack would like to participate as a project for the May 2015 to August 2015 round. We are still identifying mentors and have sponsorship from the OpenStack Foundation. This page should collect the ideas for applicants to work on. <br />
<br />
Outreachy emphasizes that applicants may not have ever worked on FLOSS before. There are several stages to the program, but the first stage is to mentor during the application process itself. Joining mailing lists, IRC, understanding the channels of communication are good first steps. Logging bugs and fixing bugs are also good ideas. <br />
<br />
Interns are expected to spend 40 hours a week on the project. <br />
<br />
So, feel free to list ideas here:<br />
<br />
== Coding ==<br />
<br />
=== Zaqar: zaqar-pythonclient support for Zaqar API v1.1 ===<br />
<br />
Mentor: [[User:Vkmc|Victoria Martinez de la Cruz]]<br />
<br />
Currently there are three versions of Zaqar API: v1, v1.1 and v2.0 (under heavy development). zaqar-pythonclient has full support for all the features in API v1, but its missing support for some features in API v1.1. This task would require to learn and understand the new features provided in API v1.1 and add support for them client side.<br />
<br />
Difficulty: Normal<br />
Required skills: Python<br />
<br />
=== Zaqar: Creation of a Zaqar panel for Horizon ===<br />
<br />
Mentor: [[User:Vkmc|Victoria Martinez de la Cruz]]<br />
<br />
Right now the only way to use Zaqar is through the API. The creation of a panel for Horizon would make Zaqar more user friendly. This task would require to learn and understand how panels are created in Horizon, to select Zaqar features to expose, to create a UI for it and do the implementation afterwards.<br />
<br />
Difficulty: Hard<br />
Required skills: Python, Django, Javascript<br />
<br />
=== Neutron - metering agent add port statistics ===<br />
<br />
Description: <br />
<br />
In Neutron the metering agent [https://wiki.openstack.org/wiki/Neutron/Metering/Bandwidth] 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. <br />
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.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/neutron/+spec/port-statistics<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Openvswitch<br />
<br />
Mentors: [[User:Rossella|Rossella Sblendido]]<br />
<br />
== Documentation ==<br />
<br />
Mentors:<br />
** loquacities on IRC / lana dot brindley at rackspace dot com<br />
** asettle on IRC/ alexandra dot settle at rackspace dot com<br />
<br />
* Assist with the RST conversion of the Admin User Guide<br />
<br />
* Help with the Networking Guide: either with content, copyediting, or the RST conversion.<br />
<br />
* General bug work (find something interesting and work on it). This would look great on her resume as it's a solid visible contribution, but would also hopefully pay down some of our technical debt.<br />
<br />
* Choose a book/section of interest, and research and update that section. A good candidate here would be the API guides.<br />
<br />
<big>'''Ideas below this point correspond to the last Outreachy round (December 2014 - March 2015). This means that they may not be available anymore. Please ask the mentor listed about it'''</big><br />
<br />
<br />
== Community ==<br />
<br />
* Write puppet scripts to automatically deploy/manage Ask OpenStack<br />
<br />
Mentors:<br />
** hodepodge on IRC / chris at openstack org<br />
** EmilienM on IRC / emilien at redhat com<br />
<br />
== Coding ==<br />
<br />
=== Ceilometer ===<br />
<br />
Mentor: [[DinaBelova|Dina Belova]]<br />
<br />
Ceilometer team is currently working on new Time-Series storage concept for metrics. For now Gnocchi (Telemetry Stackforge project where we're trying to implement this kind of effort) lacks of the backend support (only Swift in place, InfluxDB and OpenTSDB still in progress). There is some interest to use Ceph directly instead of it. So we need direct-to-ceph usage from<br />
Gnocchi, possibly via the rados gateway REST API (as opposed to ceph-sitting-behind-swift-proxy as an alternative storage driver for Swift itself).<br />
<br />
=== Zaqar: Split data/control planes ===<br />
<br />
Mentor: [[User:flaper87|Flavio Percoco]]<br />
<br />
Zaqar has 2 different logical "data-planes". One is used to control the state of the system and other administrative operations - pools, flavors, etc - and the other is used for the actual data going through Zaqar - queues, messages, etc. These 2 data planes currently share lots of things like config options, modules and more. The team has been willing to split these 2 logically different planes into isolated modules and configs.<br />
<br />
This task will give the mentee great insights on Zaqar's architecture, logic and also more general information on how some messaging patterns are implemented in the system. This task is a great intro to Zaqar, to OpenStack and to messaging technologies with enough complexity to help the mentee grow.<br />
<br />
* Expected Results: Both planes should be completely separate<br />
* Required Knowedge: Python<br />
<br />
=== Trove ===<br />
<br />
Mentor: [[User:iccha-sethi|Iccha Sethi]]<br />
<br />
Description: MySQL replication enhancements<br />
<br />
Work on trove enhancements for mysql replication.<br />
<br />
=== Glance - Implement Tasks scrubber ===<br />
<br />
Description: Glance Tasks are currently never deleted. This project would involve writing a scrubber logic for soft-deleting tasks as a part of Glance codebase.<br />
<br />
Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
Please reach out on IRC to get a detailed information on this.<br />
<br />
Initial blueprint: https://blueprints.launchpad.net/glance/+spec/async-glance-workers . A new BP would be needed to get this implemented. It would also be a responsibility of the candidate.<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Glance - Swift ranged uploads ===<br />
<br />
Note(nikhil_k): This is a really challenging project. It would need a lot of research and motivation from candidate to perform the tasks. The tasks would also need to be defined by the candidate themselves to have a good "concurrent" distributed system as a end-result.<br />
<br />
Description: We currently retry the entire upload process if it fails. Need to add the ranged uploads logic from swift store to improve performance. Target repo - openstack/glance_store<br />
<br />
Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
Please reach out on IRC to get a detailed information on this.<br />
<br />
Related blueprint: TBA<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Swift - storage server OPTIONS support and checker tool ===<br />
<br />
Many times new deployers get mysterious errors after first setting up their Swift clusters. Most of the time, the errors are because the values in the ring are incorrect (e.g. a bad port number). We need a way to validate that the rings actually match the deployment.<br />
<br />
http://tools.ietf.org/html/rfc7231#section-4.3.7 talks about the OPTIONS verb. Swift's proxy server already supports OPTIONS, but the storage nodes do not. The first task is to implement OPTIONS on the account, container, and object servers.<br />
<br />
Once the "OPTIONS *" functionality is implemented, swift-recon can be updated to include a ring checker. This checker would look at the ring and validate that there is something running on the server endpoints listed in the ring. Furthermore it would be able to actually check that the endpoint, if it's a real endpoint, is the right kind of endpoint (e.g. actually check that it's an object server). swift-recon would then generate a report of any found issues in the cluster.<br />
<br />
Expected results: patches written, submitted for review, and reviewed by the community<br />
<br />
Knowledge prerequisites: Python programming knowledge<br />
<br />
Nice-to-have knowledge: familiarity with HTTP protocols<br />
<br />
Mentors: [[User:notmyname|John Dickinson]]<br />
<br />
WIP Schedule: https://etherpad.openstack.org/p/iaR4TQZ7NP<br />
<br />
<br />
=== Swift - Improving the security of Swift's internal network ===<br />
<br />
Today all internal messages within a Swift cluster are unencrypted and unsigned. This means that all Swift deployments must be configured with a private, secure network for internal requests. This project is to add a cryptographic signature to all messages sent between Swift processes.<br />
<br />
Blueprint: https://blueprints.launchpad.net/swift/+spec/secure-internal-network-requests<br />
<br />
Expected results: patches written, submitted for review, and reviewed by the community<br />
<br />
Knowledge prerequisites: good Python programming knowledge, Swift's architecture, familiarity with HTTP<br />
<br />
Nice-to-have knowledge: familiarity with PKI<br />
<br />
Mentors: [[User:notmyname|John Dickinson]]<br />
<br />
WIP Schedule: https://etherpad.openstack.org/p/Wp3Hn7YY8p<br />
<br />
<br />
=== Swift/Swift3 - Improve S3 compatibility layer ===<br />
<br />
Improve the Swift3 middleware to get better S3 API coverage<br />
<br />
https://github.com/stackforge/swift3<br />
<br />
Mentors: [[User:notmyname|John Dickinson]]<br />
<br />
=== Proposed by applicants ===<br />
<br />
==== Keystone - Implementation of Attribute and Graph Based Access Control Model (AGBAC) for Openstack ====<br />
<br />
Proposed by: Tahmina Ahmed - Tahmina<br />
<br />
Description: The Core Openstack Access Control Module according to identity API V3 (user, token,project, domain, group, role association) [0] can be abstracted as a graph:<br />
<br /><br />
<br />
[[File:OSACFinal.jpg|Openstack Access Control According to Identity API V3 ]]<br />
<br /><br />
<br />
Attribute of different entities and the relationship between them and attribute of the relationship can be expressed through property graph [2] where entities are nodes and relationships are edges and both nodes and edges has attribute. Using entities and their attributes and relationship between entities and attribute of relationship to specify authorization policy will allow a system to have more finer grained access control model. For this representation, OpenStack entities (user, group, role, project, domain) are represented as nodes in the graph and the attributes and association between any two of them can be depicted as attributed edges. Given that a role is associated with a user and a project where the association is temporal, if we can say that the association is only active from 8am to 5pm this is something to say about the user- project- role association. We can express this as an attribute of the user- project and project - role association edge and use this for authorization to findout active roles. <br />
<br />
This implementation plan is to make minimum impact on services outside keystone.So the plan is to like computing authorization path specification for a certain time when user requests for a token and and return a list of active roles. In that case this extension to the authorization model is transparent to all other openstack services like nova, glance, cynder etc. <br />
<br />
Steps to Implement AGBAC in Openstack <br />
<br />
1. Define API and Storage for Specifying Attributes of different entities <br />
2. Define storage Assignment Attributes.<br />
3. Define API to set the entity attributes<br />
4. Define API to set the association attributes<br />
5. A Policy specification storage that would specify path based policy to compute roles.<br />
6. A Compute function that would compute the roles using entites, their attributes relationship between entities attribute of relationships and policy.<br />
<br />
[0] Bo Tang and Ravi Sandhu, Extending Openstack Access Control With Domain Trust. In Proceedings 8th International Conference on Network and System Security (NSS 2014), Xi'an, China, October 15-17, 2014, 15 pages<br />
<br />
[1] http://neo4j.com/<br />
<br />
[2] Rodriguez, Marko A., and Peter Neubauer. "Constructions from dots and lines." Bulletin of the American Society for Information Science and Technology 36.6 (2010): 35-41.<br />
<br />
== Design ==<br />
<br />
=== Persona research and design for Horizon UI ===<br />
<br />
Description: <br />
There has been some initial work done in a few different areas around generating Personas for the Horizon UI. This task/project would allow someone to lead the effort to pull the research together, perhaps perform further end-user interviews or surveys, analyze data, form groups of personas, and put together an initial set of target Horizon personas that we can use during requirements gathering, design phases, and general discussion.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/horizon-personas<br />
<br />
Expected results: Initial set of Personas for people to use during requirements gathering, design phases, and general discussion of our target Horizon users.<br />
<br />
Knowledge prerequisites: basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:julim|Ju Lim]]<br />
<br />
=== Redesign for the Object Storage -> Containers section in Horizon ===<br />
<br />
Description: <br />
<br />
Currently, there is a section under the Object Storage panel that allows users (e.g. Consumers and/or Project Administrators) to Create, Delete, and Edit Containers. It would be great to do a little bit of research into identifying the use cases around these features and then proposing a redesign of these features based on the findings. This will include learning some basic Usability best practices and applying them to a design. The design would be done in wireframe format, so it could be done in any tool that allows for this. The design would be reviewed on the UX AskBot site, a new blueprint would need to be created as well. This would take a new designer through the process that currently exists for proposing an updated design to a current feature in Horizon.<br />
<br />
Related blueprint: N/A (To be created by intern as part of process)<br />
<br />
Expected results: Redesign of "Containers" section in Object Storage panel proposed and approved by Horizon community.<br />
<br />
Knowledge prerequisites: basic sketching or wireframing skills<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:julim|Ju Lim]]<br />
<br />
=== Horizon Concept Review and Usability Testing ===<br />
<br />
Description: There has been very little work done around Horizon UI concept reviews and usability testing. This task/project would allow someone to lead the effort to put together a test plan, identify customers as test participants, conduct (contextual) inquiry / interview, survey users, analyze data to share results / findings with the community findings regarding how current production OpenStack users are using the software, their use cases, and whether the Horizon UI meets their needs. Along the way, you may identify areas of improvement, concepts that need further refinement, and new use cases or opportunities that have not yet been addressed.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/ux-users-community-testing<br />
<br />
Expected results: (1) Identify a community of users willing to participate in Horizon UI usability testing and participate in various OpenStack concept reviews. (2) Share usability test findings with the community that will be used for design and general Horizon discussions.<br />
<br />
Knowledge prerequisites: usability testing skills, basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings, ability to analyze data to find patterns.<br />
<br />
Nice-to-have knowledge: User Experience Design and/or User Research basics<br />
<br />
Mentors: [[User:julim|Ju Lim]]</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Women_of_OpenStack&diff=67803Women of OpenStack2014-11-13T09:42:23Z<p>Rossella: </p>
<hr />
<div>Welcome to the Women of OpenStack directory!<br />
<br />
Feel free to add yourself to the list. For your Contact info, use whatever you're most comfortable with—Facebook or LinkedIn, Launchpad profile page, IRC handle, etc. <br />
<br />
You may also want to join the [http://www.linkedin.com/groups/Women-OpenStack-WOS-4681909 Women in OpenStack LinkedIn group]. If you're an IRC user, join '''#openstack-opw'''. <br />
<br />
{| class="wikitable"<br />
|-<br />
! Name !! Contact !! Role !! Area(s) of Interest<br />
|-<br />
| Jane Example Stacker || IRC: JaneS <br /> [https://www.linkedin.com/ LinkedIn] <br /> [http://facebook.com Facebook] || Developer || Nova, Neutron<br />
|-<br />
|Malini Bhandaru || IRC: malini1 <br /> [http://www.linkedin.com/pub/malini-bhandaru/0/578/43a/ LinkedIn] <br /> malini dot k dot bhandaru at intel dot com || Architect & Manager - Intel Open Source Technology Center || Security, Advanced Network Services, Glance, Keystone <br />
|-<br />
| Lana Brindley || IRC: loquacities <br /> || Docs Core & Rackspace Private Cloud Docs || All projects<br />
|-<br />
| Anne Gentle || IRC: annegentle <br /> || Docs PTL, Technical Committee || All projects<br />
|-<br />
| Karin Levenstein || IRC: KLevenstein || Docs Writer (Information Developer)<br /> Rackspace Private Cloud docs || OpenStack Core projects<br />
|-<br />
| Alexandra Settle || IRC: asettle <br /> || Docs Writer (Information Developer) || OpenStack Core projects<br />
|-<br />
| Sayali Lunkad || IRC: sayalilunkad <br /> || training-guides core || training-guides, horizon<br />
|-<br />
| Irena Berezovsky || IRC: irenab <br /> || Architect || neutron, nova, SDN, NFV<br />
|-<br />
| Rossella Sblendido || IRC: rossella_s <br /> || Software Engineer || Neutron<br />
|}</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Internship_ideas&diff=63816Internship ideas2014-09-26T12:46:04Z<p>Rossella: /* Neutron - metering agent add port statistics */</p>
<hr />
<div><br />
<!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas --><br />
== Outreach Program for Women Ideas List ==<br />
<br />
The GNOME Foundation provides an outreach program for women. You can learn more here: https://live.gnome.org/OutreachProgramForWomen. <br />
<br />
OpenStack would like to participate as a project for the Dec. 2014 to March 2015 session. We are still identifying mentors and have sponsorship from the OpenStack Foundation. This page should collect the ideas for applicants to work on. <br />
<br />
GNOME OPW emphasizes that applicants may not have ever worked on FLOSS before. There are several stages to the program, but the first stage is to mentor during the application process itself. Joining mailing lists, IRC, understanding the channels of communication are good first steps. Logging bugs and fixing bugs are also good ideas. <br />
<br />
Interns are expected to spend 40 hours a week on the project. <br />
<br />
So, feel free to list ideas here:<br />
<br />
== Documentation ==<br />
<br />
== Community ==<br />
<br />
'''''Outdated: Waiting for mentor confirmation'''''<br />
<br />
* Build a supply-chain management system to distribute merchandising to OpenStack User Groups around the world [reed on IRC / stefano at openstack org] [[Community/CollateralMgmt|Details]]<br />
* Add audio and video real time collaboration capabilities to OpenStack User Groups portal [reed on IRC / stefano at openstack org]<br />
* Write puppet scripts to automatically deploy/manage Ask OpenStack [reed on IRC / stefano at openstack org]<br />
<br />
== Coding ==<br />
<br />
=== Zaqar: TBD ===<br />
<br />
Mentor: [[User:flaper87|Flavio Percoco]]<br />
<br />
<br />
=== Trove ===<br />
<br />
Mentor: [[User:iccha-sethi|Iccha Sethi]]<br />
<br />
Description: MySQL replication enhancements<br />
<br />
Work on trove enhancements for mysql replication.<br />
<br />
=== Glance - adding NoSQL support ===<br />
<br />
'''''Outdated: Waiting for mentor confirmation'''''<br />
<br />
Description: Glance is used as metadata repository management tool within OpenStack for server Images. NoSQL can be really useful for DB backend for Glance.<br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/glance/+spec/enable-mongo-db<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, NoSQL<br />
<br />
Mentors: [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Glance - Implement Tasks scrubber ===<br />
<br />
'''''Outdated: Waiting for mentor confirmation'''''<br />
<br />
Description: Glance Tasks are currently never deleted. This project would involve writing a scrubber logic for soft-deleting tasks as a part of Glance codebase.<br />
<br />
Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
Please reach out to me on IRC to get a detailed information on this.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/glance/+spec/async-glance-workers<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Glance - Swift ranged uploads ===<br />
<br />
'''''Outdated: Waiting for mentor confirmation'''''<br />
<br />
Description: We currently retry the entire upload process if it fails. Need to add the ranged uploads logic from swift store to improve performance.<br />
<br />
Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
Please reach out to me on IRC to get a detailed information on this.<br />
<br />
Related blueprint: TBA<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:nikhil|Nikhil Komawar]]<br />
<br />
<br />
=== Swift - storage server OPTIONS support and checker tool ===<br />
<br />
Many times new deployers get mysterious errors after first setting up their Swift clusters. Most of the time, the errors are because the values in the ring are incorrect (e.g. a bad port number). We need a way to validate that the rings actually match the deployment.<br />
<br />
http://tools.ietf.org/html/rfc7231#section-4.3.7 talks about the OPTIONS verb. Swift's proxy server already supports OPTIONS, but the storage nodes do not. The first task is to implement OPTIONS on the account, container, and object servers.<br />
<br />
Once the "OPTIONS *" functionality is implemented, swift-recon can be updated to include a ring checker. This checker would look at the ring and validate that there is something running on the server endpoints listed in the ring. Furthermore it would be able to actually check that the endpoint, if it's a real endpoint, is the right kind of endpoint (e.g. actually check that it's an object server). swift-recon would then generate a report of any found issues in the cluster.<br />
<br />
Expected results: patches written, submitted for review, and reviewed by the community<br />
<br />
Knowledge prerequisites: Python programming knowledge<br />
<br />
Nice-to-have knowledge: familiarity with HTTP protocols<br />
<br />
Mentors: [[User:notmyname|John Dickinson]]<br />
<br />
=== Neutron - metering agent add port statistics ===<br />
<br />
Description: <br />
<br />
In Neutron the metering agent [https://wiki.openstack.org/wiki/Neutron/Metering/Bandwidth] 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. <br />
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.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/neutron/+spec/port-statistics<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Openvswitch<br />
<br />
Mentors: [[User:Rossella|Rossella Sblendido]]<br />
<br />
=== Ceilometer - Period-spanning statistics ===<br />
<br />
'''''Outdated: Waiting for mentor confirmation'''''<br />
<br />
Description: Currently, in Ceilometer, statistical aggregates are calculated over discrete periods. However, there are many interesting statistical techniques that naturally span across multiple periods. Examples range from simple moving averages to more sophisticated exponential smoothing with the potential for forecasting & prediction bands. This project would involve designing the method for calculating period-spanning statistics and implementing period-spanning statistics in the storage drivers (MongoDB, SQL, etc.)<br />
<br />
Related blueprint: https://blueprints.launchpad.net/ceilometer/+spec/period-spanning-statistics<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have-knowledge: Python, MongoDB, SQL, basic statistics<br />
<br />
Mentors: [[User:eglynn|Eoghan Glynn]]<br />
<br />
=== Proposed by applicants ===<br />
<br />
==== Keystone - Implementation of Attribute and Graph Based Access Control Model (AGBAC) for Openstack ====<br />
<br />
Proposed by: Tahmina Ahmed - Tahmina<br />
<br />
Description: The Core Openstack Access Control Module according to identity API V3 (user, token,project, domain, group, role association) [0] can be abstracted as a graph:<br />
<br />
[[File:OSAC.jpg|center]]<br />
<br />
Using a property graph database (where both nodes and edges have attributes) as a backend for identity, we can express contextual association between any two entities of OpenStack. For this representation, OpenStack entities (user, group, role, project, domain) are represented as nodes in the graph and the attributes and association between any two of them can be depicted as attributed edges. Given that a project is associated with a domain and this association is temporal, if we can say that the association is only active from 8am to 5pm this is something to say about the project-domain association. We can express this as an attribute of the project-domain association edge and use this for access control perspective. Incorporating a property graph database like Neo4j [1] to the OpenStack Identity backend can give us the flexibility to express contextual association of different entities in OpenStack. <br />
<br />
Steps to Implement AGBAC in Openstack <br />
<br />
1. Add support for an open source graph database Neo4j [1] in the OpenStack Identity backend.<br />
2. In policy specification use path expression based policy. <br />
3. Make a policy analyzer that translates the path expression based policy to “Cypher” query for Neo4j.<br />
<br />
[0] Bo Tang and Ravi Sandhu, Extending Openstack Access Control With Domain Trust. In Proceedings 8th International Conference on Network and System Security (NSS 2014), Xi'an, China, October 15-17, 2014, 15 pages<br />
<br />
[1] http://neo4j.com/<br />
<br />
== Design ==<br />
<br />
=== Persona research and design for Horizon UI ===<br />
<br />
'''''Outdated: Waiting for mentor confirmation'''''<br />
<br />
Description: <br />
There has been some initial work done in a few different areas around generating Personas for the Horizon UI. This task/project would allow someone to lead the effort to pull the research together, perhaps perform further end-user interviews or surveys, analyze data, form groups of personas, and put together an initial set of target Horizon personas that we can use during requirements gathering, design phases, and general discussion.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/horizon-personas<br />
<br />
Expected results: Initial set of Personas for people to use during requirements gathering, design phases, and general discussion of our target Horizon users.<br />
<br />
Knowledge prerequisites: basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:Liz_Blanchard|Liz Blanchard]], [[User:julim|Ju Lim]]<br />
<br />
=== Redesign for the Object Storage -> Containers section in Horizon ===<br />
<br />
'''''Outdated: Waiting for mentor confirmation'''''<br />
<br />
Description: <br />
<br />
Currently, there is a section under the Object Storage panel that allows users (e.g. Consumers and/or Project Administrators) to Create, Delete, and Edit Containers. It would be great to do a little bit of research into identifying the use cases around these features and then proposing a redesign of these features based on the findings. This will include learning some basic Usability best practices and applying them to a design. The design would be done in wireframe format, so it could be done in any tool that allows for this. The design would be reviewed on the UX AskBot site, a new blueprint would need to be created as well. This would take a new designer through the process that currently exists for proposing an updated design to a current feature in Horizon.<br />
<br />
Related blueprint: N/A (To be created by intern as part of process)<br />
<br />
Expected results: Redesign of "Containers" section in Object Storage panel proposed and approved by Horizon community.<br />
<br />
Knowledge prerequisites: basic sketching or wireframing skills<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:Liz_Blanchard|Liz Blanchard]], [[User:julim|Ju Lim]]<br />
<br />
=== Horizon Concept Review and Usability Testing ===<br />
<br />
'''''Outdated: Waiting for mentor confirmation'''''<br />
<br />
Description: There has been very little work done around Horizon UI concept reviews and usability testing. This task/project would allow someone to lead the effort to put together a test plan, identify customers as test participants, conduct (contextual) inquiry / interview, survey users, analyze data to share results / findings with the community findings regarding how current production OpenStack users are using the software, their use cases, and whether the Horizon UI meets their needs. Along the way, you may identify areas of improvement, concepts that need further refinement, and new use cases or opportunities that have not yet been addressed.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/ux-users-community-testing<br />
<br />
Expected results: (1) Identify a community of users willing to participate in Horizon UI usability testing and participate in various OpenStack concept reviews. (2) Share usability test findings with the community that will be used for design and general Horizon discussions.<br />
<br />
Knowledge prerequisites: usability testing skills, basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings, ability to analyze data to find patterns.<br />
<br />
Nice-to-have knowledge: User Experience Design and/or User Research basics<br />
<br />
Mentors: [[User:julim|Ju Lim]], [[User:Liz_Blanchard|Liz Blanchard]]</div>Rossellahttps://wiki.openstack.org/w/index.php?title=OldMentorListing&diff=59207OldMentorListing2014-07-28T09:19:57Z<p>Rossella: </p>
<hr />
<div>{| class="wikitable sortable"<br />
|-<br />
! Name !! Area of expertise !! Availability !! Contact<br />
|-<br />
| Davanum Srinivas || Oslo, Nova || 1 or 2 hours per week (EDT) || IRC nick - dims<br />
|-<br />
| Joshua Harlow || TaskFlow, Oslo, Anvil, Cloud-init; Parts of cinder ... || 3 or 4 hours per week (EDT) || IRC nick - harlowja<br />
|-<br />
| Ajaya Agrawal || Keystone || 1 or 2 hours per week (IST) || IRC nick - ajayaa<br />
|-<br />
| Rossella Sblendido || Neutron || 2 hours per week (CET) || IRC nick - rossella_s<br />
|-<br />
|}</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Outreachy/Mentors&diff=47599Outreachy/Mentors2014-04-03T08:41:10Z<p>Rossella: </p>
<hr />
<div><br />
<!-- ## page was renamed from [[GnomeOutreachWomen]]/Mentors --><br />
== Welcome Outreach Mentors! ==<br />
<br />
Please let the coordinator of this program for OpenStack, Stefano Maffulli and Anne Gentle, know if you would like to help out mentoring for the program.<br />
<br />
All applicants are required to make a small contribution to the project they are applying to work on. As a mentor, you will need to help applicants identify a suitable first task and help them out with it during the application process.<br />
<br />
Please discuss with the applicants the details of the work they'll be doing during the internship period. It is best if the accepted participants work as part of the team, starting with smaller tasks (i.e. bugs) and progressing over time to more complex tasks (i.e. blueprints), with each task being suggested by you based on the current priorities of the team. So the applicants just need to know what areas of the project they are likely to work on and a tentative timeline.<br />
<br />
The project should consist of manageable and relevant tasks that can be incorporated into the project throughout the internship period. Stand-alone projects proposed by an applicant are not suitable at all for people who are not established contributors. Please try to avoid situations when participants work on features that are not yet designed or agreed-upon, have too many moving parts, and would only land in the main code-base after the internship is over as a best-case scenario. This rarely works out. Instead, look for agreed-upon manageable bugs and small features that have a shared theme and would allow the participant to feel the satisfaction of landing her changes throughout the internship.<br />
<br />
Good mentorship is a cornerstone of this program. These resources are very useful for prospective mentors to review prior to participating in the program for the first time:<br />
<br />
* [http://people.gnome.org/~federico/docs/summer-of-code-mentoring-howto/index.html Federico Mena-Quintero's Mentoring HOWTO]<br />
* [https://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors Advice for Google Summer of Code mentors]<br />
* [https://flossmanuals.net/GSoCMentoring/ Google Summer of Code Mentor's Guide]<br />
<br />
So far the identified mentors are. Please add your name and contact information to this list!<br />
* Julie Pichon, Developer, Red Hat<br />
* Flavio Percoco, Red Hat<br />
* Nikhil Komawar, Software Developer, Rackspace. Email: nikhil.komawar@rackspace.com<br />
* Liz Blanchard, Senior Interaction Designer, Red Hat. Email: lblanchard at redhat dot com<br />
* Ju Lim, Member of the Technical Staff, Red Hat. Email: julim at redhat dot com<br />
* David Cramer, Developer, Rackspace<br />
* Rossella Sblendido, Software Developer, SUSE. Email: rsblendido at suse dot com <br />
<br />
Volunteer administrators are:<br />
* Anne Gentle, Documentation Coordinator, Rackspace. Email: anne dot gentle at rackspace dot com<br />
* Stefano Maffulli, Community Manager, [[OpenStack]] Foundation. Email: stef at openstack dot org</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Network/Meetings&diff=46464Network/Meetings2014-03-24T20:48:41Z<p>Rossella: </p>
<hr />
<div><br />
{{:Network/Header}}<br />
<br />
The OpenStack Networking Team ([[Neutron]]) holds public meetings in <code><nowiki>#openstack-meeting</nowiki></code>. Everyone is encouraged to attend.<br />
<br />
== Apologies for Absence ==<br />
* March 10 Kyle Mestery (mestery) - Thawing out on vacation.<br />
* March 10, Sean Collins (sc68cal) - traveling<br />
<br />
== Agenda for Next Neutron Team Meeting ==<br />
<br />
=== Announcements / Reminders ===<br />
* --[[User:Markmcclain|markmcclain]] ([[User talk:Markmcclain|talk]]) 21:00, 17 March 2014 (UTC)<br />
* [https://launchpad.net/neutron/+milestone/icehouse-rc1 Icehouse-rc1].<br />
* We are in stability phase of the cycle.<br />
** Only bug fixes and FFEs will be merged.<br />
** Other contributions will be given temporary -2 until tree opens for Juno.<br />
<br />
=== Bugs ===<br />
* Stable branch is still having stability problems in the test runs.<br />
* [https://bugs.launchpad.net/neutron/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Confirmed&field.status=Triaged&field.status=In+Progress Critical Open Bugs]<br />
** [https://bugs.launchpad.net/neutron/+bug/1112912 get_firewall_required should use VIF parameter from neutron] - nati_ueno<br />
** [https://bugs.launchpad.net/neutron/+bug/1280464 grenade-dsvm-neutron Failure in upgrade-swift] - jlibosva<br />
** [https://bugs.launchpad.net/neutron/+bug/1288427 Unsequenced alembic migration files block the gate] - markmcclain<br />
** [https://bugs.launchpad.net/neutron/+bug/1265495 Error reading SSH protocol banner] - markmcclain<br />
** [https://bugs.launchpad.net/neutron/+bug/1230407 VMs can't progress through state changes because Neutron is deadlocking] - markmcclain<br />
** [https://bugs.launchpad.net/neutron/+bug/1253896 Attempts to verify guests are running via SSH fails. SSH connection to guest does not work] - salv-orlando<br />
<br />
<br />
<br />
This bugs are in nova that are related to neutron that would be great if we could get neutron reviews on:<br />
** [https://review.openstack.org/#/c/80760/] Remove unneeded call to fetch network info on shutdown - arosen<br />
** [https://review.openstack.org/#/c/81674/] remove unneeded call to network_api on detach_interface - arosen<br />
** [https://review.openstack.org/#/c/81681/] remove unneeded call to network_api on rebuild_instance - arosen<br />
** [https://review.openstack.org/#/c/80055/] Optimize validate_networks to query neutron only when needed - arosen<br />
** [https://review.openstack.org/#/c/80412/] deallocate_for_instance should delete all neutron ports on error - arosen<br />
** [https://review.openstack.org/#/c/59578/] Fix port_security_enabled neutron extension - arosen<br />
** [https://review.openstack.org/#/c/77043/] Fix pre-created ports in neutron from being deleted by nova - arosen<br />
<br />
=== Docs (emagana)===<br />
<br />
* Network Documentation Wiki (Refactoring of the installation guide)<br />
** https://wiki.openstack.org/wiki/Documentation/InstallGuideChanges<br />
* BPs associated:<br />
** [1] https://blueprints.launchpad.net/openstack-manuals/+spec/networking-install-guide-improvements<br />
** [2] https://blueprints.launchpad.net/openstack-manuals/+spec/improve-networking-cloud-admin-guide<br />
** [3] https://blueprints.launchpad.net/openstack-manuals/+spec/create-networking-guide<br />
<br />
* HA Neutron - Proposal<br />
** http://lists.openstack.org/pipermail/openstack-docs/2014-January/003689.html<br />
<br />
* Current list of bugs against neutron docs: https://bugs.launchpad.net/openstack-manuals/+bugs?field.tag=neutron<br />
<br />
<br />
High Priority Tickets:<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1099574 - Unassigned - Invalid<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1179046 - Unassigned - This bug will be cover in this BP [1]<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1203230 - Martin Lopes - Partially fixed and requesting feedback if another patch is needed or we can close it<br />
** Fixed by: https://review.openstack.org/76455 <br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1230276 - Martin Lopes - Partially fixed and requesting feedback if another patch is needed or we can close it <br />
** Fixed by: https://review.openstack.org/79228<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1260129 - Summer Long - Requested a status update<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1273412 - Edgar Magana - In Review<br />
<br />
<br />
Medium Priority Tickets:<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1026745 - Unassigned - Request sent to Mate Lakat to help on this one<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1087586 - Edgar Magana - In Review<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1106428 - Edgar Magana - WIP<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1112866 - Edgar Magana - WIP<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1224160 - Phil Hopkins - Requested a status update<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1226279 - Aaron Rosen - WIP<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1226394 - Unassigned - - Request sent to Aaron Rosen to help on this one<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1226889 - Edgar Magana - This bug will be covered in this BP [2]<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1259576 - Unassigned - Request sent to Oleg Bondarev to help on this one<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1283334 - Unassigned - Request sent to Irena B. to help on this one<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1283930 - Unassigned - Request sent to Itsuro Oda to help on this one<br />
* https://bugs.launchpad.net/openstack-manuals/+bug/1286593 - Mohammad Banikazemi - WIP<br />
<br />
=== Nova Parity (beagles) ===<br />
<br />
(updated March 24, 2014)<br />
<br />
Resurrected issues mentioned reported last week:<br />
<br />
* https://bugs.launchpad.net/nova/+bug/1269060 Calls to get_fixed_ip are not implemented when using neutron.<br />
* https://bugs.launchpad.net/nova/+bug/1269061 Calls to get_vifs_by_instance are not implemented when using neutron.<br />
* https://bugs.launchpad.net/nova/+bug/1269062 Call to get_vif_by_mac_address is not implemented when using neutron.<br />
* https://bugs.launchpad.net/nova/+bug/1293539 NeutronV2 API is missing associate method.<br />
<br />
An issue that just showed up on my radar is also parity related:<br />
<br />
* https://bugs.launchpad.net/neutron/+bug/1274034 Neutron firewall anti-spoofing does not prevent ARP poisoning<br />
<br />
=== Neutron Tempest (mlavalle) ===<br />
* Full Tempest Test Update (salv-orlando)<br />
** [http://lists.openstack.org/pipermail/openstack-dev/2014-February/027797.html ML Thread for Full Tempest]<br />
** [http://lists.openstack.org/pipermail/openstack-dev/2014-March/030907.html Latest analysis of the failures]<br />
* Tempest cores reviewing and approving api tests more actively:<br />
** 4 patchsets are listed as abandoned in Gerrit. On 3/20, an email was sent to their authors requesting permission to assign the work to other contributors <br />
** As of 3/20 The following patchsets require just on more +2 to merge. They were brought to the attention of the Tempest core reviewers during their IRC meeting on 3/20:<br />
*** https://review.openstack.org/#/c/71251<br />
*** https://review.openstack.org/#/c/68597<br />
*** https://review.openstack.org/#/c/63999<br />
** Patchsets merged between 3/18 aqnd 3/24<br />
*** https://review.openstack.org/#/c/66796 Elena Ezhova (Add api tests for load balancer's VIPs and health monitors)<br />
*** https://review.openstack.org/#/c/66921 Sukhdev Kapur (Networks,Ports: delete with subnet, port with no IP)<br />
*** https://review.openstack.org/#/c/63999 Ann Kamyshnikova (Add tests for external network extension)<br />
** Patchsets merged between 3/11 and 3/17<br />
*** https://review.openstack.org/#/c/61118 Ann Kamyshnikova (Verify more information in API tests for LBaaS)<br />
*** https://review.openstack.org/#/c/68626 Nanya Patel (Adds L3 agent test case to test_l3_agent_schedule)<br />
*** https://review.openstack.org/#/c/64271 Elena Ezhova (Add tests for binding extended attributes for ports)<br />
** Patchsets merged between 3/3 and 3/10<br />
*** https://review.openstack.org/#/c/69561 Nanya Patel (Test to update neutron security group)<br />
*** https://review.openstack.org/#/c/64130 Ann Kamyshnikova (Add namespaces to xml in Network client)<br />
** Patchsets merged between 2/25 and 3/2<br />
*** https://review.openstack.org/#/c/74744 Jun Xie (test create router setting tenant_id)<br />
*** https://review.openstack.org/#/c/73789 Dong Liu (test more attributes for routers operation)<br />
*** https://review.openstack.org/#/c/69829 Nanya Patel (json and xml client refactoring for security group operations)<br />
** Patchsets merged between 2/17 and 2/24<br />
*** https://review.openstack.org/#/c/67210 Henry Gessau (Network API framework: default to ipv4, add ipv6 tests)<br />
*** https://review.openstack.org/#/c/65120 Miguel Lavalle (lbaas agent scheduler)<br />
*** https://review.openstack.org/#/c/67741 Miguel Lavalle (Neutron Extra DHCP Options API test)<br />
*** https://review.openstack.org/#/c/66143 Emilien Macchi (api metering labels and rules)<br />
** In review cycle:<br />
*** https://review.openstack.org/#/c/63723/ Ann Kamyshnikova (api floating ip)<br />
*** https://review.openstack.org/#/c/61118/ Ann Kamyshnikova (api lbaas)<br />
*** https://review.openstack.org/#/c/63627/ yfried (scenario floating ip's)<br />
*** https://review.openstack.org/#/c/58697/ Elena Ezhova (scenario lbaas)<br />
*** https://review.openstack.org/#/c/55146/ yfried (scenario network connectivity)<br />
*** https://review.openstack.org/#/c/62962/ salv-orlando (make router creation for tenant isolation optional)<br />
*** https://review.openstack.org/#/c/60008/ Evgeny Fedoruk (Extending quota support for neutron LBaaS entities)<br />
*** https://review.openstack.org/#/c/50542/ ChenZheng (Test for the neutron api with provider extension)<br />
*** https://review.openstack.org/#/c/63625/ QianLin <br />
*** https://review.openstack.org/#/c/63999/2 Ann Kamyshnikova (external network extension)<br />
*** https://review.openstack.org/#/c/64271 Elena Ezhova (api binding extended attributes for ports)<br />
*** https://review.openstack.org/#/c/65515 Joris Roovers (VPNaaS scenario test)<br />
*** https://review.openstack.org/#/c/65350 Joris Roovers (VPNaas API test enhancement)<br />
*** https://review.openstack.org/#/c/66259 Miguel Lavalle (Allowed Address Pair API test)<br />
*** https://review.openstack.org/#/c/66854 Joris Roovers (Network Scenario Tests Directory Restructuring)<br />
*** https://review.openstack.org/#/c/67312 Edgar Magana (Add test for subnet gateway IPv4 and IPv6)<br />
*** https://review.openstack.org/#/c/66921 Sukhdev Kapur (Test all attributes in network)<br />
*** https://review.openstack.org/#/c/67547 Dane LeBlanc (Add API test for create/delete/update port with 2 IP addresses)<br />
*** https://review.openstack.org/#/c/66541 Ann Kamyshnikova (api LBaaS admin operations)<br />
*** https://review.openstack.org/#/c/65943 Ann Kamyshnikova (api LBaaS complete coverage)<br />
*** https://review.openstack.org/#/c/66796 Elena Ezhova (api. Increase coverage of VIP and health monitor testing)<br />
*** https://review.openstack.org/#/c/68626 Nayna Patel (api L3 agent schduler)<br />
*** https://review.openstack.org/#/c/66921 Sukhdev Kapur (api networks shared, other tenants, delete with subnet, create port with no ip)<br />
*** https://review.openstack.org/#/c/69561 Nayna Patel (api security groups update)<br />
*** https://review.openstack.org/#/c/71251 Ann Kamyshnikova (api: Verify more information in floating ip tests(part2))<br />
*** https://review.openstack.org/#/c/65744 Emilien Macchi (api: fwaas)<br />
*** https://review.openstack.org/#/c/66454 Sylvain Afchain (api: ExtraRoute)<br />
*** https://review.openstack.org/#/c/68597 Nanya Patel (dhcp agent scheduler)<br />
<br />
=== API (salv-orlando) ===<br />
No report<br />
<br />
=== L3 (carl_baldwin) ===<br />
(updated 2014-03-24)<br />
<br />
See [[Meetings/Neutron-L3-Subteam]] for detail.<br />
<br />
* [[Meetings/Neutron-L3-Subteam|Team meeting]] on Thursdays at 1500 UTC.<br />
* Active Projects<br />
** l3-high-availability<br />
*** [https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/l3-high-availability,n,z Patches are submitted]. Needs review.<br />
** neutron-ovs-dvr<br />
*** [[Meetings/Distributed-Virtual-Router|DVR meeting]] is still going on.<br />
*** Documentation on ML2 and L3 agent changes is available. Need help reviewing.<br />
**** [https://docs.google.com/document/d/1depasJSnGZPOnRLxEC_PYsVLcGVFXZLqP52RFTe21BE/edit#heading=h.5w7clq272tji DVR-L2-Agent Blueprint]<br />
**** [https://docs.google.com/document/d/1jCmraZGirmXq5V1MtRqhjdZCbUfiwBhRkUjDXGt5QUQ/edit DVR-L3-Agent Blueprint]<br />
*** Discussion started about how to integrate l3-high-availability for HA in centralized services<br />
** bgp-dynamic-routing<br />
*** Discussed running dynamic routing process outside of Neutron router namespace.<br />
*** carl_baldwin to attempt to clarify use cases<br />
** L3 Agent Performance with Wrapper Overhead<br />
*** https://etherpad.openstack.org/p/neutron-agent-exec-performance<br />
*** For Icehouse, I want to look in to documenting patches to sudo and iproute that improve the overhead situation.<br />
*** There is interest in developing a root wrap agent (YorikSar) and possibly back-porting to Icehouse.<br />
* New blueprints for Juno.<br />
** Fixing/enabling DNS lookup of instance hostnames<br />
*** carl_baldwin wrapping up a blueprint for this<br />
** Please bring other potential blueprints to the discussion at the meeting<br />
*** decentralized-snat, l3-high-availability active/active, router-port-forwarding<br />
<br />
=== IPv6 (sc68cal) ===<br />
* [https://review.openstack.org/#/c/52983/ Two new attributes for Subnets for IPv6 configuration ] - core input appreciated.<br />
* [https://review.openstack.org/#/c/70649/3 Add support for IPv6 attributes to the DCHP agent]<br />
<br />
=== ML2 (mestery/rkukura) ===<br />
* Weekly [[Meetings/ML2]] are held, please attend if interested!<br />
** Tracking status of open BPs, including new drivers - owners should try to attend<br />
* Migration tool BP: https://blueprints.launchpad.net/neutron/+spec/ml2-deprecated-plugin-migration<br />
** High priority, in review: https://review.openstack.org/#/c/76533/ (FFE granted)<br />
* Two bug fixes for port binding:<br />
** https://bugs.launchpad.net/neutron/+bug/1276395 - binding details<br />
*** https://review.openstack.org/#/c/79511 - needs one more core review<br />
** https://bugs.launchpad.net/neutron/+bug/1276391 - bind_port() called in transaction<br />
*** partially addressed by https://review.openstack.org/#/c/79511<br />
*** final patch almost ready<br />
<br />
=== Group Policy (mestery) ===<br />
* Weekly meeting here: https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy<br />
** Continuing to make progress on the API patches thanks to SumitNaiksatam.<br />
** Group Policy model document here: https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit?usp=sharing<br />
** Making progress on the DB object model code thanks to banix.<br />
** Will implement Group Policies as new Core Plugin initially<br />
<br />
=== VPN (nachi) ===<br />
* SSL-VPN<br />
** API patch https://review.openstack.org/#/c/58897/<br />
** Agent https://review.openstack.org/#/c/70274/<br />
** How to test ssl-vpn https://wiki.openstack.org/wiki/Neutron/VPNaaS/SSLVPN/HowToUse<br />
** API specification https://wiki.openstack.org/wiki/Neutron/VPNaaS/SSLVPN<br />
*STF for VPN https://review.openstack.org/#/c/41827/<br />
* Doc bugs<br />
** Manual https://bugs.launchpad.net/openstack-manuals/+bug/1284301<br />
** API https://bugs.launchpad.net/openstack-api-site/+bug/1284302<br />
̽<br />
<br />
=== FWaaS (snaiksat) ===<br />
Bug fixes are being merged<br />
<br />
<br />
Waiting for gate to open for following:<br />
* Service Insertion Context, and Firewall insertion: https://review.openstack.org/#/c/62599 (RajeshMohan)<br />
* Service Insertion Context Client and CLI - https://review.openstack.org/#/c/74290/<br />
* Service/Application Objects to configure FWaaS rules - https://review.openstack.org/#/c/67784 (yisun)<br />
<br />
<br />
Waiting for further discussion<br />
* Service Type frame work patch - https://review.openstack.org/#/c/60699 ( garyduan )<br />
<br />
<br />
Pending:<br />
* Turning FWaaS on in the gate - awaiting direction on this<br />
:SridarK has done investigation and posted results: https://wiki.openstack.org/wiki/Quantum/FWaaS/Testing<br />
:http://lists.openstack.org/pipermail/openstack-dev/2013-December/023217.html - would like to get the opinion of the team if this is a good time to do it.<br />
<br />
=== LBaaS (enikanorov) ===<br />
tbd<br />
<br />
=== 3rd Party Testing ===<br />
* Update on voting responsibilities<br />
<br />
=== Other team reports (e.g. Open Source Plugins) ===<br />
<br />
=== Open Discussion ===<br />
<br />
== Previous meeting logs ==<br />
* Previous meetings, with their notes and logs, can be found [http://eavesdrop.openstack.org/meetings/networking/ here].<br />
** [http://eavesdrop.openstack.org/meetings/networking/2014/?C=M;O=D networking-2014]<br />
** [http://eavesdrop.openstack.org/meetings/networking/2013/?C=M;O=D networking-2013]<br />
** [http://eavesdrop.openstack.org/meetings/quantum/2013/?C=M;O=D quantum-2013]<br />
** [http://eavesdrop.openstack.org/meetings/quantum/2012/?C=M;O=D quantum-2012]<br />
* Older meeting notes are here: ../MeetingLogs.</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Outreachy&diff=45511Outreachy2014-03-14T12:03:20Z<p>Rossella: </p>
<hr />
<div><!-- ## page was renamed from [[GnomeOutreachWomen]] --><br />
== Welcome to the Outreach Program for Women! ==<br />
<br />
OpenStack provides open source software for building public and private clouds. We are constantly moving and growing and very excited to invite newcomers to our community. To this end, the OpenStack Foundation has joined the [https://live.gnome.org/OutreachProgramForWomen GNOME Outreach Program for Women].<br />
<br />
<br />
<br />
== Background ==<br />
<br />
GNOME Foundation has found that [https://live.gnome.org/OutreachProgramForWomen the program] has dramatically improved the participation by women in their community. For example, at GUADEC they went from having around 4% women to around 17% in just a few years. Representation of women among free and open source participants has been cited at 3% [1], [2] as contrasted with the percentages of computing degrees earned by women (all at over 10% higher) in the US. <br />
<br />
At the October 2012 OpenStack Summit, [[AnneGentle|Anne Gentle]] led an unconference session about including more women in OpenStack and identified one of the goals as bringing more newcomers to OpenStack. The GNOME Outreach program is an excellent way to meet that inclusion goal. At the October 2013 OpenStack Summit, mentors and interns presented about their experiences in "[[https://www.openstack.org/summit/portland-2013/session-videos/presentation/what-everyone-ought-to-know-about-openstack-internships|What Everyone Ought to Know about OpenStack Internships]]" <br />
<br />
The program offers a good match for efforts to improve our community for women and all newcomers in OpenStack, making it more welcoming for all. The GNOME program specifically seems to be a perfect fit for OpenStack because it matches mentors with newcomers. Another expected effect is to increase women's attendance at the Summit, maybe in conjunction with scholarships and/or employer support. Contrary to Google Summer of Code, which is aimed only at developers, this program results in many strong applicants because it reaches and is suitable for many people with interests in coding, documentation, design, or marketing.<br />
<br />
The [http://www.linkedin.com/groups/Women-OpenStack-WOS-4681909 Women in OpenStack group] has already found 4-6 mentors for the program. Each internship requires $6,250 from OpenStack sponsors or by the Foundation. We have funding from the Foundation for one intern for the May 19 to August 18 internship period. More funding is welcomed.<br />
<br />
1. http://www.eskar.dk/andreas/output/PersonalProfile.HTM<br />
2. http://survey.perlfoundation.org/Data-PerlSurvey-2010/R/<br />
<br />
== Schedule ==<br />
<br />
The application deadline for OPW will be March 19 and for GSoC March 21. The internship period spans from May 19 to August 18, so the results of the internships will be ready by Fall 2014 OpenStack Summit.<br />
<br />
* February 24: program announced and application form made available<br />
* February 24-March 19: applicants need to get in touch with at least one project and make a contribution to it<br />
* March 19: application deadline at 7pm UTC<br />
* April 21: accepted participants announced on the [[https://wiki.gnome.org/OutreachProgramForWomen/2014/MayAugust|GNOME page]] at 7pm UTC<br />
* May 19 to August 18: internship period<br />
* November 2014: OpenStack Summit<br />
<br />
== Participants: What the heck is [[OpenStack]]? ==<br />
<br />
In a sentence, OpenStack provides open source software for building public and private clouds. What does that mean? We're a collection of open source projects that integrate to help organizations deploy and run clouds for computing, networking, and storage (both block storage for providing volumes to VMs and object storage for storing objects such as images or music files). With OpenStack, you can control large pools of compute, storage, and networking resources throughout a data center, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface. The [http://www.openstack.org/software/start/ Start page] on openstack.org has more details.<br />
<br />
We have in-person [[Summit|Summits]] in the fall and spring. We're a community of a lot of companies and individual contributors with a Foundation providing governance and oversight. We collaborate together to build cloud software that's free from vendor lock-in.<br />
<br />
[[File:openstack_summit_spring2012.jpg]]<br />
<br />
'''Community members at the spring 2012 Design Summit in the Developer Lounge ([https://secure.flickr.com/photos/annegentle/6945924486/in/photostream/ Flickr:thegentles])'''<br />
<br />
With the help of a mentor, you can navigate these projects to find out more specifics on the types of work available.<br />
<br />
There are currently several components of OpenStack: Compute, Object Storage, Identity, Dashboard, Block Storage, Network and Image Service. Let's look at each in turn.<br />
<br />
* Block Storage (codenamed [[Cinder|"Cinder"]]) provides persistent block storage to guest VMs. This project was born from code originally in Nova (the nova-volume service described below). In the Folsom release, both the nova-volume service and the separate volume service are available.<br />
* Compute (codenamed [[Nova|"Nova"]]) provides virtual servers upon demand. Rackspace and HP provide commercial compute services built on Nova and it is used internally at many companies.<br />
* Dashboard (codenamed [[Horizon|"Horizon"]]) provides a modular web-based user interface for all the OpenStack services. With this web GUI, you can perform most operations on your cloud like launching an instance, assigning IP addresses and setting access controls.<br />
* Identity (codenamed [[Keystone|"Keystone"]]) provides authentication and authorization for all the OpenStack services. It also provides a service catalog of services within a particular OpenStack cloud.<br />
* Image (codenamed [[Glance|"Glance"]]) provides a catalog and repository for virtual disk images. These disk images are mostly commonly used in OpenStack Compute. While this service is technically optional, any cloud of size will require it.<br />
* Network (codenamed [[Neutron|"Neutron"]]) provides "network connectivity as a service" between interface devices managed by other OpenStack services (most likely Nova). The service works by allowing users to create their own networks and then attach interfaces to them. Quantum has a pluggable architecture to support many popular networking vendors and technologies.<br />
* Object Store (codenamed [[Swift|"Swift"]]) provides object storage. It allows you to store or retrieve files (but not mount directories like a fileserver). Several companies provide commercial storage services based on Swift. These include KT, Rackspace (from which Swift originated) and Internap. Swift is also used internally at many large companies to store their data.<br />
* Telemetry Service (codenamed [[Ceilometer|"Ceilometer"]]) aggregates usage and performance data across the services deployed in an OpenStack cloud. This powerful capability provides visibility and insight into the usage of the cloud across dozens of data points and allows cloud operators to view metrics globally or by individual deployed resources.<br />
* Orchestration Service (codenamed [[Heat|"Heat"]]) is a template-driven engine that allows application developers to describe and automate the deployment of infrastructure. The flexible template language can specify compute, storage and networking configurations as well as detailed post-deployment activity to automate the full provisioning of infrastructure as well as services and applications. Through integration with the Telemetry service, the Orchestration engine can also perform auto-scaling of certain infrastructure elements.<br />
<br />
OpenStack stages integrated releases every six months, named according to a voted-upon geographic location nearest to the next Summit. Don't let all these crazy names (release names, project names, oh my!) stop you from jumping in though. We have a lot of fun in the cloud with names and word play.<br />
<br />
== Participants: How can I learn even more? ==<br />
<br />
Read the project's page on Launchpad.<br />
<br />
We communicate a lot on IRC and all the channels are listed at http://wiki.openstack.org/IRC. You can go to the project's IRC channel, such as #openstack-dev (where the developers are), #openstack (where the deployers are), and for each project you can also find channels with the project name like nova is at #openstack-nova, swift is at #openstack-swift, and so on. You can read the conversation there and jump in when you are ready.<br />
<br />
As a prospective applicant, you should consider joining the #openstack-opw channel, where you can meet mentors, interns past and present, as well as other helpful members of the community.<br />
<br />
If you are applying for a software development internship, run [http://devstack.org DevStack] in a VM on your laptop to run all the integrated projects in one location. Do ask your mentor or people on IRC for help if you encounter any problems running DevStack.<br />
<br />
Look at the open bugs for the project Launchpad, the pattern is http://bugs.launchpad.net/nova where nova is the project name. There are many projects that are not completely code-related. For example, doc bugs are at http://bugs.launchpad.net/openstack-manuals, API doc bugs are at http://bugs.launchpad.net/openstack-api-site, continuous integration bugs are tracked at http://bugs.launchpad.net/openstack-ci, and quality assurance tooling bugs are at http://bugs.launchpad.net/tempest.<br />
<br />
Look at the recent changes in the project's Git repository, for example https://github.com/openstack/glance/ shows the most recent changes to the Image service project, Glance.<br />
<br />
Read about our use of Gerrit for code reviews at [[GerritWorkflow]].<br />
<br />
Read the documentation at http://docs.openstack.org, which is built from https://github.com/openstack/openstack-manuals Git repository.<br />
<br />
Read the recent discussion on the project's mailing list, such as http://lists.openstack.org/pipermail/openstack-dev/.<br />
<br />
Read the blogs of the project's mentor and other project contributors (you can learn who they are when looking at the Git repository). Many contributor's blogs are collected at http://planet.openstack.org.<br />
<br />
Introduce yourself to the project's mentor and discuss what your tasks during the internship program would be.<br />
<br />
== Participants: How do I apply? ==<br />
<br />
The application process is to send an application containing the following information to a mailing list set up just for reviewing applications. Read more at https://wiki.gnome.org/OutreachProgramForWomen#Send_in_an_Application to apply. <br />
Please be available and responsive throughout the application period so we can work with you on improving your application.<br />
<br />
== Participants: What if I have a question about [[OpenStack]]? ==<br />
<br />
With a large collection of projects, just finding out where to ask (or who) can be intimidating. We want you to feel free to contact anyone in the community, and for direct contact, talk to Anne Gentle via email at anne at openstack dot org or Stefano Maffuli at stefano at openstack dot org if you have any questions during the application process. There are also mailing lists available at http://wiki.openstack.org/MailingLists with many purposes.<br />
<br />
== Mentors ==<br />
For information about expectations for mentors and to volunteer to be a mentor, see [[OutreachProgramForWomen/Mentors]].<br />
<br />
The identified volunteer mentors are:<br />
<br />
* Julie Pichon, Developer, Red Hat. Email: jpichon at redhat dot com. IRC: jpich<br />
* Ladislav Smola, Developer, Red Hat. Email: lsmola at redhat dot com. IRC: lsmola<br />
* Flavio Percoco, Developer, Red Hat. Email: flavio at redhat dot com. IRC: flaper87<br />
* Stefano Maffulli, Community Manager, OpenStack Foundation. Reed on IRC. Email: stefano at openstack dot org IRC: reed<br />
* Liz Blanchard, Senior Interaction Designer, Red Hat. Email: lblanchard at redhat dot com. IRC: lblanchard<br />
* Ju Lim, Member of the Technical Staff, Red Hat. Email: julim at redhat dot com. IRC: julim<br />
* Nikhil Komawar, Software Developer, Rackspace. nikhil on IRC Email: nikhil.komawar at rackspace dot com<br />
* David Cramer, Software Developer, Rackspace. dcramer on IRC Email: david dot cramer at rackspace dot com<br />
* Rossella Sblendido, Software Developer, SUSE, Email: rsblendido at suse dot com IRC: rossella_s<br />
<br />
Volunteer administrators are:<br />
<br />
* Anne Gentle, Documentation Coordinator, Rackspace. Email: anne dot gentle at rackspace dot com<br />
* Stefano Maffulli, Community Manager, OpenStack Foundation. Reed on IRC. Email: stefano at openstack dot org<br />
<br />
== Projects ==<br />
<br />
Please see the [[OutreachProgramForWomen/Ideas|Ideas page]].</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Internship_ideas&diff=43509Internship ideas2014-02-26T21:34:29Z<p>Rossella: /* Neutron - add an extension for port statistics */</p>
<hr />
<div><br />
<!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas --><br />
== Outreach Program for Women Ideas List ==<br />
<br />
The GNOME Foundation provides an outreach program for women. You can learn more here: https://live.gnome.org/OutreachProgramForWomen. <br />
<br />
OpenStack would like to participate as a project for the Dec. 2013 to March 2014 session. We have identified some mentors and have sponsorship from the OpenStack Foundation, Rackspace and HP to participate in this program. This page should collect the ideas for applicants to work on. <br />
<br />
GNOME OPW emphasizes that applicants may not have ever worked on FLOSS before. There are several stages to the program, but the first stage is to mentor during the application process itself. Joining mailing lists, IRC, understanding the channels of communication are good first steps. Logging bugs and fixing bugs are also good ideas. <br />
<br />
Interns are expected to spend 40 hours a week on the project. <br />
<br />
So, feel free to list ideas here:<br />
<br />
== Documentation ==<br />
<br />
OpenStack documentation is highly technical and processed like the code itself. See below for ideas on how to participate as a doc contributor.<br />
<br />
=== Improved OpenStack API Reference and Guide Documentation ===<br />
<br />
Description: Enhance API Complete Reference pages and create comprehensive API Guide. <br />
<br />
While I will focus on [[Blueprint-os-api-docs#Goal_1_-_New_API_Guide|goal #1]], <br />
the intern's focus will be on [[Blueprint-os-api-docs#https://wiki.openstack.org/wiki/Blueprint-os-api-docs#Goal_2_-_Improved_API_Reference_pages|goal #2]] and [[Blueprint-os-api-docs#Goal_3_-_Move_API_Specs_to_project_repositories_and_off_docs_landing_page|goal #3]] in the blueprint [https://wiki.openstack.org/w/index.php?title=Blueprint-os-api-docs#Goals goals.] list. Specifically, the intern will help move information from existing API specs into API reference page WADLs, and test revised WADLs to ensure they produce correct output. (2 months). After WADLs are updated, the intern will move existing source specs into appropriate project repositories and delete API specs from docs landing page (1 month).<br />
<br />
Blueprint: https://wiki.openstack.org/w/index.php?title=Blueprint-os-api-docs<br />
<br />
Expected results: Improved API Reference pages. Single, comprehensive API Guide on the api.openstack.org/ site that provides conceptual information and guidance for multiple OpenStack APIs. <br />
<br />
Knowledge Prerequisites: XML, HTML, build automation, APIs, javascript<br />
Nice-to-have knowledge: WADL, REST API, JSON, programming, Git<br />
<br />
Mentor: [[User:DianeFleming|Diane Fleming]]<br />
<br />
== Community ==<br />
* Build a supply-chain management system to distribute merchandising to OpenStack User Groups around the world [reed on IRC / stefano at openstack org] [[Community/CollateralMgmt|Details]]<br />
* Write a mobile app for tablets to create a paperless kiosk for marketing collateral at events [reed on IRC / stefano at openstack org] [[Community/PaperlessKiosk|Details]]<br />
* Add audio (video?) real time collaboration capabilities to OpenStack User Groups portal [reed on IRC / stefano at openstack org]<br />
<br />
== Coding ==<br />
<br />
=== Reporting Framework for Ceilometer based on Oslo Reporting ===<br />
<br />
Description: we need a way to store summary reports generated by Ceilometer. These would be stored as special Events in the CM database and accessable via the CM API. It would be nice to leverage the report work underway in Oslo, if possible. <br />
<br />
Existing Reporting BP: https://wiki.openstack.org/wiki/GuruMeditationReport<br />
<br />
New Reporting BP: https://blueprints.launchpad.net/ceilometer/+spec/add-ceilometer-reporter<br />
<br />
Discussion: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016122.html<br />
<br />
Related work: https://github.com/openstack/oslo-incubator/tree/master/openstack/common/report<br />
<br />
Expected results: patches to Ceilometer to support the creation of Report Events. <br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:SandyWalsh|Sandy Walsh]], [[User:JulienDanjou|Julien Danjou]]<br />
<br />
=== Marconi WebSocket Transport ===<br />
<br />
Description: Marconi, a queuing service for OpenStack, is in its early ages and some of its areas are still being designed and developed from scratch. It is a great opportunity for interns to learn about queuing systems, OpenStack architecture and development methodologies. The proposed project is to help developing a WebSocket based transport for Marconi. <br />
<br />
Related blueprint: https://blueprints.launchpad.net/marconi/+spec/websocket-endpoint<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: RESTFul APIs, HTTP, MongoDB<br />
<br />
Mentor: [[User:flaper87|Flavio Percoco]]<br />
<br />
=== Marconi API Spec ===<br />
<br />
Description: Marconi is a queuing service for OpenStack. it's grown very fast, since it was kicked off in late Grizzly. This growth has allowed it to be incubated and to support multiple technologies under the same API and goal. However, there are still some areas that could be more generic and improved. One of those areas is the API specification. As for now, an API is specified within the transport itself. A transport is a frontend plugin that adds support for a specific protocol to Marconi - wsgi, zmq, tcp.<br />
<br />
This project is about creating a generic enough API spec that can be interpreted by every transport and that will also allow to have extensions and versioning without sacrificing Marconi's API stability.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/marconi/+spec/cross-transport-api-spec<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members. Blueprint draft completion and good development progress.<br />
Nice-to-have Knowledge: RESTFul APIs, HTTP.<br />
<br />
Mentor: [[User:flaper87|Flavio Percoco]]<br />
<br />
=== Sparklines in Horizon ===<br />
<br />
Description: A lot of work is currently being done to integrate metering (Ceilometer) better with the web dashboard (Horizon). One nice addition would be to add "sparklines" (for an example of what a sparkline is, [http://www.bissantz.de/site_images/tufte/sparklines.jpg see this]) to some of the tables in Horizon, so that they poll the data from Ceilometer. The Line Charts library should already provide asynchronous polling.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/horizon/+spec/sparklines<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Django<br />
<br />
Mentors: [[User:Jpichon|Julie Pichon]], [[User:Lsmola|Ladislav Smola]]<br />
<br />
=== Surface the "Instance Actions" Information ===<br />
<br />
''This project is taken.''<br />
<br />
Description: In the web dashboard (Horizon), it is possible to see information about the instances currently running. It would be nice to be able to see the instance history when clicking on the details, e.g. to figure out when an instance was shut down and by whom, etc. This information is already provided by an API in the compute service (Nova), and needs to be surfaced both for the user (who can see the history for their own instances) and the admin (who can see the history for everyone). This will probably require using Horizon Tabs and TabGroups, adding it to the instance details and finding a nice way to display the data. <br />
<br />
Related blueprint: https://blueprints.launchpad.net/horizon/+spec/instance-actions-dashboard<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Django, Selenium/UI Testing<br />
<br />
Mentors: [[User:Jpichon|Julie Pichon]]<br />
<br />
=== Glance - adding MongoDB support ===<br />
<br />
Description: Glance is used as metadata repository management tool within OpenStack for server Images. NoSQL can be really useful for DB backend for Glance.<br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/glance/+spec/enable-mongo-db<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, MongoDB<br />
<br />
Mentors: [[User:IcchaSethi|Iccha Sethi]], [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Glance - add memcache support for backend upload/download ===<br />
<br />
Description: <br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/glance/+spec/glance-upload-memcache , https://blueprints.launchpad.net/glance/+spec/glance-download-memcache<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:IcchaSethi|Iccha Sethi]], [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Neutron - add an extension for port statistics ===<br />
<br />
Description: <br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to 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.<br />
<br />
You´ll create an extension for Neutron [https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions] to be able to expose monitoring data regarding ports (byte or packets transmitted or received). You´ll provide an implementation of the extension using the ML2 framework [https://wiki.openstack.org/wiki/Neutron/ML2] and openvswitch. This feature will be implemented end to end, from api design to unit testing.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/neutron/+spec/port-statistics<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Openvswitch<br />
<br />
Mentors: [[User:Rossella|Rossella Sblendido]]<br />
<br />
== Design ==<br />
<br />
=== Persona research and design for Horizon UI ===<br />
<br />
Description: <br />
There has been some initial work done in a few different areas around generating Personas for the Horizon UI. This task/project would allow someone to lead the effort to pull the research together, perhaps perform further end-user interviews or surveys, analyze data, form groups of personas, and put together an initial set of target Horizon personas that we can use during requirements gathering, design phases, and general discussion.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/horizon-personas<br />
<br />
Expected results: Initial set of Personas for people to use during requirements gathering, design phases, and general discussion of our target Horizon users.<br />
<br />
Knowledge prerequisites: basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:Liz_Blanchard|Liz Blanchard]], [[User:julim|Ju Lim]]<br />
<br />
=== Redesign for the Object Storage -> Containers section in Horizon ===<br />
<br />
Description: <br />
<br />
Currently, there is a section under the Object Storage panel that allows users (e.g. Consumers and/or Project Administrators) to Create, Delete, and Edit Containers. It would be great to do a little bit of research into identifying the use cases around these features and then proposing a redesign of these features based on the findings. This will include learning some basic Usability best practices and applying them to a design. The design would be done in wireframe format, so it could be done in any tool that allows for this. The design would be reviewed on the UX AskBot site, a new blueprint would need to be created as well. This would take a new designer through the process that currently exists for proposing an updated design to a current feature in Horizon.<br />
<br />
Related blueprint: N/A (To be created by intern as part of process)<br />
<br />
Expected results: Redesign of "Containers" section in Object Storage panel proposed and approved by Horizon community.<br />
<br />
Knowledge prerequisites: basic sketching or wireframing skills<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:Liz_Blanchard|Liz Blanchard]], [[User:julim|Ju Lim]]<br />
<br />
<br />
=== Horizon Concept Review and Usability Testing ===<br />
<br />
Description: There has been very little work done around Horizon UI concept reviews and usability testing. This task/project would allow someone to lead the effort to put together a test plan, identify customers as test participants, conduct (contextual) inquiry / interview, survey users, analyze data to share results / findings with the community findings regarding how current production OpenStack users are using the software, their use cases, and whether the Horizon UI meets their needs. Along the way, you may identify areas of improvement, concepts that need further refinement, and new use cases or opportunities that have not yet been addressed.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/ux-users-community-testing<br />
<br />
Expected results: (1) Identify a community of users willing to participate in Horizon UI usability testing and participate in various OpenStack concept reviews. (2) Share usability test findings with the community that will be used for design and general Horizon discussions.<br />
<br />
Knowledge prerequisites: usability testing skills, basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings, ability to analyze data to find patterns.<br />
<br />
Nice-to-have knowledge: User Experience Design and/or User Research basics<br />
<br />
Mentors: [[User:julim|Ju Lim]], [[User:Liz_Blanchard|Liz Blanchard]]</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Internship_ideas&diff=43503Internship ideas2014-02-26T21:29:56Z<p>Rossella: </p>
<hr />
<div><br />
<!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas --><br />
== Outreach Program for Women Ideas List ==<br />
<br />
The GNOME Foundation provides an outreach program for women. You can learn more here: https://live.gnome.org/OutreachProgramForWomen. <br />
<br />
OpenStack would like to participate as a project for the Dec. 2013 to March 2014 session. We have identified some mentors and have sponsorship from the OpenStack Foundation, Rackspace and HP to participate in this program. This page should collect the ideas for applicants to work on. <br />
<br />
GNOME OPW emphasizes that applicants may not have ever worked on FLOSS before. There are several stages to the program, but the first stage is to mentor during the application process itself. Joining mailing lists, IRC, understanding the channels of communication are good first steps. Logging bugs and fixing bugs are also good ideas. <br />
<br />
Interns are expected to spend 40 hours a week on the project. <br />
<br />
So, feel free to list ideas here:<br />
<br />
== Documentation ==<br />
<br />
OpenStack documentation is highly technical and processed like the code itself. See below for ideas on how to participate as a doc contributor.<br />
<br />
=== Improved OpenStack API Reference and Guide Documentation ===<br />
<br />
Description: Enhance API Complete Reference pages and create comprehensive API Guide. <br />
<br />
While I will focus on [[Blueprint-os-api-docs#Goal_1_-_New_API_Guide|goal #1]], <br />
the intern's focus will be on [[Blueprint-os-api-docs#https://wiki.openstack.org/wiki/Blueprint-os-api-docs#Goal_2_-_Improved_API_Reference_pages|goal #2]] and [[Blueprint-os-api-docs#Goal_3_-_Move_API_Specs_to_project_repositories_and_off_docs_landing_page|goal #3]] in the blueprint [https://wiki.openstack.org/w/index.php?title=Blueprint-os-api-docs#Goals goals.] list. Specifically, the intern will help move information from existing API specs into API reference page WADLs, and test revised WADLs to ensure they produce correct output. (2 months). After WADLs are updated, the intern will move existing source specs into appropriate project repositories and delete API specs from docs landing page (1 month).<br />
<br />
Blueprint: https://wiki.openstack.org/w/index.php?title=Blueprint-os-api-docs<br />
<br />
Expected results: Improved API Reference pages. Single, comprehensive API Guide on the api.openstack.org/ site that provides conceptual information and guidance for multiple OpenStack APIs. <br />
<br />
Knowledge Prerequisites: XML, HTML, build automation, APIs, javascript<br />
Nice-to-have knowledge: WADL, REST API, JSON, programming, Git<br />
<br />
Mentor: [[User:DianeFleming|Diane Fleming]]<br />
<br />
== Community ==<br />
* Build a supply-chain management system to distribute merchandising to OpenStack User Groups around the world [reed on IRC / stefano at openstack org] [[Community/CollateralMgmt|Details]]<br />
* Write a mobile app for tablets to create a paperless kiosk for marketing collateral at events [reed on IRC / stefano at openstack org] [[Community/PaperlessKiosk|Details]]<br />
* Add audio (video?) real time collaboration capabilities to OpenStack User Groups portal [reed on IRC / stefano at openstack org]<br />
<br />
== Coding ==<br />
<br />
=== Reporting Framework for Ceilometer based on Oslo Reporting ===<br />
<br />
Description: we need a way to store summary reports generated by Ceilometer. These would be stored as special Events in the CM database and accessable via the CM API. It would be nice to leverage the report work underway in Oslo, if possible. <br />
<br />
Existing Reporting BP: https://wiki.openstack.org/wiki/GuruMeditationReport<br />
<br />
New Reporting BP: https://blueprints.launchpad.net/ceilometer/+spec/add-ceilometer-reporter<br />
<br />
Discussion: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016122.html<br />
<br />
Related work: https://github.com/openstack/oslo-incubator/tree/master/openstack/common/report<br />
<br />
Expected results: patches to Ceilometer to support the creation of Report Events. <br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:SandyWalsh|Sandy Walsh]], [[User:JulienDanjou|Julien Danjou]]<br />
<br />
=== Marconi WebSocket Transport ===<br />
<br />
Description: Marconi, a queuing service for OpenStack, is in its early ages and some of its areas are still being designed and developed from scratch. It is a great opportunity for interns to learn about queuing systems, OpenStack architecture and development methodologies. The proposed project is to help developing a WebSocket based transport for Marconi. <br />
<br />
Related blueprint: https://blueprints.launchpad.net/marconi/+spec/websocket-endpoint<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: RESTFul APIs, HTTP, MongoDB<br />
<br />
Mentor: [[User:flaper87|Flavio Percoco]]<br />
<br />
=== Marconi API Spec ===<br />
<br />
Description: Marconi is a queuing service for OpenStack. it's grown very fast, since it was kicked off in late Grizzly. This growth has allowed it to be incubated and to support multiple technologies under the same API and goal. However, there are still some areas that could be more generic and improved. One of those areas is the API specification. As for now, an API is specified within the transport itself. A transport is a frontend plugin that adds support for a specific protocol to Marconi - wsgi, zmq, tcp.<br />
<br />
This project is about creating a generic enough API spec that can be interpreted by every transport and that will also allow to have extensions and versioning without sacrificing Marconi's API stability.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/marconi/+spec/cross-transport-api-spec<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members. Blueprint draft completion and good development progress.<br />
Nice-to-have Knowledge: RESTFul APIs, HTTP.<br />
<br />
Mentor: [[User:flaper87|Flavio Percoco]]<br />
<br />
=== Sparklines in Horizon ===<br />
<br />
Description: A lot of work is currently being done to integrate metering (Ceilometer) better with the web dashboard (Horizon). One nice addition would be to add "sparklines" (for an example of what a sparkline is, [http://www.bissantz.de/site_images/tufte/sparklines.jpg see this]) to some of the tables in Horizon, so that they poll the data from Ceilometer. The Line Charts library should already provide asynchronous polling.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/horizon/+spec/sparklines<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Django<br />
<br />
Mentors: [[User:Jpichon|Julie Pichon]], [[User:Lsmola|Ladislav Smola]]<br />
<br />
=== Surface the "Instance Actions" Information ===<br />
<br />
''This project is taken.''<br />
<br />
Description: In the web dashboard (Horizon), it is possible to see information about the instances currently running. It would be nice to be able to see the instance history when clicking on the details, e.g. to figure out when an instance was shut down and by whom, etc. This information is already provided by an API in the compute service (Nova), and needs to be surfaced both for the user (who can see the history for their own instances) and the admin (who can see the history for everyone). This will probably require using Horizon Tabs and TabGroups, adding it to the instance details and finding a nice way to display the data. <br />
<br />
Related blueprint: https://blueprints.launchpad.net/horizon/+spec/instance-actions-dashboard<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Django, Selenium/UI Testing<br />
<br />
Mentors: [[User:Jpichon|Julie Pichon]]<br />
<br />
=== Glance - adding MongoDB support ===<br />
<br />
Description: Glance is used as metadata repository management tool within OpenStack for server Images. NoSQL can be really useful for DB backend for Glance.<br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/glance/+spec/enable-mongo-db<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, MongoDB<br />
<br />
Mentors: [[User:IcchaSethi|Iccha Sethi]], [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Glance - add memcache support for backend upload/download ===<br />
<br />
Description: <br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/glance/+spec/glance-upload-memcache , https://blueprints.launchpad.net/glance/+spec/glance-download-memcache<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:IcchaSethi|Iccha Sethi]], [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Neutron - add an extension for port statistics ===<br />
<br />
Description: <br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to 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.<br />
<br />
You´ll create an extension for Neutron [https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions] to be able to expose monitoring data regarding ports (byte or packets transmitted or received). You´ll provide an implementation of the extension using the ML2 framework [https://wiki.openstack.org/wiki/Neutron/ML2] and openvswitch. This feature will be implemented end to end, from api design to unit testing.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/neutron/+spec/port-statistics<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Openvswitch<br />
<br />
Mentors: [[User:Rossella|Rossella Sblendido]]<br />
== Design ==<br />
<br />
=== Persona research and design for Horizon UI ===<br />
<br />
Description: <br />
There has been some initial work done in a few different areas around generating Personas for the Horizon UI. This task/project would allow someone to lead the effort to pull the research together, perhaps perform further end-user interviews or surveys, analyze data, form groups of personas, and put together an initial set of target Horizon personas that we can use during requirements gathering, design phases, and general discussion.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/horizon-personas<br />
<br />
Expected results: Initial set of Personas for people to use during requirements gathering, design phases, and general discussion of our target Horizon users.<br />
<br />
Knowledge prerequisites: basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:Liz_Blanchard|Liz Blanchard]], [[User:julim|Ju Lim]]<br />
<br />
=== Redesign for the Object Storage -> Containers section in Horizon ===<br />
<br />
Description: <br />
<br />
Currently, there is a section under the Object Storage panel that allows users (e.g. Consumers and/or Project Administrators) to Create, Delete, and Edit Containers. It would be great to do a little bit of research into identifying the use cases around these features and then proposing a redesign of these features based on the findings. This will include learning some basic Usability best practices and applying them to a design. The design would be done in wireframe format, so it could be done in any tool that allows for this. The design would be reviewed on the UX AskBot site, a new blueprint would need to be created as well. This would take a new designer through the process that currently exists for proposing an updated design to a current feature in Horizon.<br />
<br />
Related blueprint: N/A (To be created by intern as part of process)<br />
<br />
Expected results: Redesign of "Containers" section in Object Storage panel proposed and approved by Horizon community.<br />
<br />
Knowledge prerequisites: basic sketching or wireframing skills<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:Liz_Blanchard|Liz Blanchard]], [[User:julim|Ju Lim]]<br />
<br />
<br />
=== Horizon Concept Review and Usability Testing ===<br />
<br />
Description: There has been very little work done around Horizon UI concept reviews and usability testing. This task/project would allow someone to lead the effort to put together a test plan, identify customers as test participants, conduct (contextual) inquiry / interview, survey users, analyze data to share results / findings with the community findings regarding how current production OpenStack users are using the software, their use cases, and whether the Horizon UI meets their needs. Along the way, you may identify areas of improvement, concepts that need further refinement, and new use cases or opportunities that have not yet been addressed.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/ux-users-community-testing<br />
<br />
Expected results: (1) Identify a community of users willing to participate in Horizon UI usability testing and participate in various OpenStack concept reviews. (2) Share usability test findings with the community that will be used for design and general Horizon discussions.<br />
<br />
Knowledge prerequisites: usability testing skills, basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings, ability to analyze data to find patterns.<br />
<br />
Nice-to-have knowledge: User Experience Design and/or User Research basics<br />
<br />
Mentors: [[User:julim|Ju Lim]], [[User:Liz_Blanchard|Liz Blanchard]]</div>Rossellahttps://wiki.openstack.org/w/index.php?title=Internship_ideas&diff=43502Internship ideas2014-02-26T21:28:01Z<p>Rossella: </p>
<hr />
<div><br />
<!-- ## page was renamed from [[GnomeOutreachWomen]]/Ideas --><br />
== Outreach Program for Women Ideas List ==<br />
<br />
The GNOME Foundation provides an outreach program for women. You can learn more here: https://live.gnome.org/OutreachProgramForWomen. <br />
<br />
OpenStack would like to participate as a project for the Dec. 2013 to March 2014 session. We have identified some mentors and have sponsorship from the OpenStack Foundation, Rackspace and HP to participate in this program. This page should collect the ideas for applicants to work on. <br />
<br />
GNOME OPW emphasizes that applicants may not have ever worked on FLOSS before. There are several stages to the program, but the first stage is to mentor during the application process itself. Joining mailing lists, IRC, understanding the channels of communication are good first steps. Logging bugs and fixing bugs are also good ideas. <br />
<br />
Interns are expected to spend 40 hours a week on the project. <br />
<br />
So, feel free to list ideas here:<br />
<br />
== Documentation ==<br />
<br />
OpenStack documentation is highly technical and processed like the code itself. See below for ideas on how to participate as a doc contributor.<br />
<br />
=== Improved OpenStack API Reference and Guide Documentation ===<br />
<br />
Description: Enhance API Complete Reference pages and create comprehensive API Guide. <br />
<br />
While I will focus on [[Blueprint-os-api-docs#Goal_1_-_New_API_Guide|goal #1]], <br />
the intern's focus will be on [[Blueprint-os-api-docs#https://wiki.openstack.org/wiki/Blueprint-os-api-docs#Goal_2_-_Improved_API_Reference_pages|goal #2]] and [[Blueprint-os-api-docs#Goal_3_-_Move_API_Specs_to_project_repositories_and_off_docs_landing_page|goal #3]] in the blueprint [https://wiki.openstack.org/w/index.php?title=Blueprint-os-api-docs#Goals goals.] list. Specifically, the intern will help move information from existing API specs into API reference page WADLs, and test revised WADLs to ensure they produce correct output. (2 months). After WADLs are updated, the intern will move existing source specs into appropriate project repositories and delete API specs from docs landing page (1 month).<br />
<br />
Blueprint: https://wiki.openstack.org/w/index.php?title=Blueprint-os-api-docs<br />
<br />
Expected results: Improved API Reference pages. Single, comprehensive API Guide on the api.openstack.org/ site that provides conceptual information and guidance for multiple OpenStack APIs. <br />
<br />
Knowledge Prerequisites: XML, HTML, build automation, APIs, javascript<br />
Nice-to-have knowledge: WADL, REST API, JSON, programming, Git<br />
<br />
Mentor: [[User:DianeFleming|Diane Fleming]]<br />
<br />
== Community ==<br />
* Build a supply-chain management system to distribute merchandising to OpenStack User Groups around the world [reed on IRC / stefano at openstack org] [[Community/CollateralMgmt|Details]]<br />
* Write a mobile app for tablets to create a paperless kiosk for marketing collateral at events [reed on IRC / stefano at openstack org] [[Community/PaperlessKiosk|Details]]<br />
* Add audio (video?) real time collaboration capabilities to OpenStack User Groups portal [reed on IRC / stefano at openstack org]<br />
<br />
== Coding ==<br />
<br />
=== Reporting Framework for Ceilometer based on Oslo Reporting ===<br />
<br />
Description: we need a way to store summary reports generated by Ceilometer. These would be stored as special Events in the CM database and accessable via the CM API. It would be nice to leverage the report work underway in Oslo, if possible. <br />
<br />
Existing Reporting BP: https://wiki.openstack.org/wiki/GuruMeditationReport<br />
<br />
New Reporting BP: https://blueprints.launchpad.net/ceilometer/+spec/add-ceilometer-reporter<br />
<br />
Discussion: http://lists.openstack.org/pipermail/openstack-dev/2013-October/016122.html<br />
<br />
Related work: https://github.com/openstack/oslo-incubator/tree/master/openstack/common/report<br />
<br />
Expected results: patches to Ceilometer to support the creation of Report Events. <br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:SandyWalsh|Sandy Walsh]], [[User:JulienDanjou|Julien Danjou]]<br />
<br />
=== Marconi WebSocket Transport ===<br />
<br />
Description: Marconi, a queuing service for OpenStack, is in its early ages and some of its areas are still being designed and developed from scratch. It is a great opportunity for interns to learn about queuing systems, OpenStack architecture and development methodologies. The proposed project is to help developing a WebSocket based transport for Marconi. <br />
<br />
Related blueprint: https://blueprints.launchpad.net/marconi/+spec/websocket-endpoint<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: RESTFul APIs, HTTP, MongoDB<br />
<br />
Mentor: [[User:flaper87|Flavio Percoco]]<br />
<br />
=== Marconi API Spec ===<br />
<br />
Description: Marconi is a queuing service for OpenStack. it's grown very fast, since it was kicked off in late Grizzly. This growth has allowed it to be incubated and to support multiple technologies under the same API and goal. However, there are still some areas that could be more generic and improved. One of those areas is the API specification. As for now, an API is specified within the transport itself. A transport is a frontend plugin that adds support for a specific protocol to Marconi - wsgi, zmq, tcp.<br />
<br />
This project is about creating a generic enough API spec that can be interpreted by every transport and that will also allow to have extensions and versioning without sacrificing Marconi's API stability.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/marconi/+spec/cross-transport-api-spec<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members. Blueprint draft completion and good development progress.<br />
Nice-to-have Knowledge: RESTFul APIs, HTTP.<br />
<br />
Mentor: [[User:flaper87|Flavio Percoco]]<br />
<br />
=== Sparklines in Horizon ===<br />
<br />
Description: A lot of work is currently being done to integrate metering (Ceilometer) better with the web dashboard (Horizon). One nice addition would be to add "sparklines" (for an example of what a sparkline is, [http://www.bissantz.de/site_images/tufte/sparklines.jpg see this]) to some of the tables in Horizon, so that they poll the data from Ceilometer. The Line Charts library should already provide asynchronous polling.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/horizon/+spec/sparklines<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Django<br />
<br />
Mentors: [[User:Jpichon|Julie Pichon]], [[User:Lsmola|Ladislav Smola]]<br />
<br />
=== Surface the "Instance Actions" Information ===<br />
<br />
''This project is taken.''<br />
<br />
Description: In the web dashboard (Horizon), it is possible to see information about the instances currently running. It would be nice to be able to see the instance history when clicking on the details, e.g. to figure out when an instance was shut down and by whom, etc. This information is already provided by an API in the compute service (Nova), and needs to be surfaced both for the user (who can see the history for their own instances) and the admin (who can see the history for everyone). This will probably require using Horizon Tabs and TabGroups, adding it to the instance details and finding a nice way to display the data. <br />
<br />
Related blueprint: https://blueprints.launchpad.net/horizon/+spec/instance-actions-dashboard<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Django, Selenium/UI Testing<br />
<br />
Mentors: [[User:Jpichon|Julie Pichon]]<br />
<br />
=== Glance - adding MongoDB support ===<br />
<br />
Description: Glance is used as metadata repository management tool within OpenStack for server Images. NoSQL can be really useful for DB backend for Glance.<br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/glance/+spec/enable-mongo-db<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, MongoDB<br />
<br />
Mentors: [[User:IcchaSethi|Iccha Sethi]], [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Glance - add memcache support for backend upload/download ===<br />
<br />
Description: <br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to reach out to the community to collect and discuss ideas. Glance folks are pretty active on #openstack-glance channel most of the time and would be willing to share their opinions on this or any other project.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/glance/+spec/glance-upload-memcache , https://blueprints.launchpad.net/glance/+spec/glance-download-memcache<br />
<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python<br />
<br />
Mentors: [[User:IcchaSethi|Iccha Sethi]], [[User:nikhil|Nikhil Komawar]]<br />
<br />
=== Neutron - add an extension for port statistics ===<br />
<br />
Description: <br />
<br />
Members of the community already have ideas on how one might want to implement this, therefore the first step will be to 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.<br />
<br />
You´ll create an extension for Neutron [https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions] to be able to expose monitoring data regarding ports (byte or packets transmitted or received). You´ll provide an implementation of the extension using the ML2 framework [https://wiki.openstack.org/wiki/Neutron/ML2] and openvswitch. This feature will be implemented end to end, from api design to unit testing.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/neutron/+spec/port-statistics<br />
Expected results: Patchsets submitted for review, reviewed by community members.<br />
<br />
Knowledge prerequisites: programming knowledge<br />
<br />
Nice-to-have knowledge: Python, Openvswitch<br />
<br />
Mentors: [User:Rossella]<br />
== Design ==<br />
<br />
=== Persona research and design for Horizon UI ===<br />
<br />
Description: <br />
There has been some initial work done in a few different areas around generating Personas for the Horizon UI. This task/project would allow someone to lead the effort to pull the research together, perhaps perform further end-user interviews or surveys, analyze data, form groups of personas, and put together an initial set of target Horizon personas that we can use during requirements gathering, design phases, and general discussion.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/horizon-personas<br />
<br />
Expected results: Initial set of Personas for people to use during requirements gathering, design phases, and general discussion of our target Horizon users.<br />
<br />
Knowledge prerequisites: basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:Liz_Blanchard|Liz Blanchard]], [[User:julim|Ju Lim]]<br />
<br />
=== Redesign for the Object Storage -> Containers section in Horizon ===<br />
<br />
Description: <br />
<br />
Currently, there is a section under the Object Storage panel that allows users (e.g. Consumers and/or Project Administrators) to Create, Delete, and Edit Containers. It would be great to do a little bit of research into identifying the use cases around these features and then proposing a redesign of these features based on the findings. This will include learning some basic Usability best practices and applying them to a design. The design would be done in wireframe format, so it could be done in any tool that allows for this. The design would be reviewed on the UX AskBot site, a new blueprint would need to be created as well. This would take a new designer through the process that currently exists for proposing an updated design to a current feature in Horizon.<br />
<br />
Related blueprint: N/A (To be created by intern as part of process)<br />
<br />
Expected results: Redesign of "Containers" section in Object Storage panel proposed and approved by Horizon community.<br />
<br />
Knowledge prerequisites: basic sketching or wireframing skills<br />
<br />
Nice-to-have knowledge: User Experience Design basics<br />
<br />
Mentors: [[User:Liz_Blanchard|Liz Blanchard]], [[User:julim|Ju Lim]]<br />
<br />
<br />
=== Horizon Concept Review and Usability Testing ===<br />
<br />
Description: There has been very little work done around Horizon UI concept reviews and usability testing. This task/project would allow someone to lead the effort to put together a test plan, identify customers as test participants, conduct (contextual) inquiry / interview, survey users, analyze data to share results / findings with the community findings regarding how current production OpenStack users are using the software, their use cases, and whether the Horizon UI meets their needs. Along the way, you may identify areas of improvement, concepts that need further refinement, and new use cases or opportunities that have not yet been addressed.<br />
<br />
Related blueprint: https://blueprints.launchpad.net/openstack-ux/+spec/ux-users-community-testing<br />
<br />
Expected results: (1) Identify a community of users willing to participate in Horizon UI usability testing and participate in various OpenStack concept reviews. (2) Share usability test findings with the community that will be used for design and general Horizon discussions.<br />
<br />
Knowledge prerequisites: usability testing skills, basic interviewing skills, willingness to talk with a lot of new people, readiness to listen and report back findings, ability to analyze data to find patterns.<br />
<br />
Nice-to-have knowledge: User Experience Design and/or User Research basics<br />
<br />
Mentors: [[User:julim|Ju Lim]], [[User:Liz_Blanchard|Liz Blanchard]]</div>Rossellahttps://wiki.openstack.org/w/index.php?title=User:Rossella&diff=43489User:Rossella2014-02-26T20:12:20Z<p>Rossella: </p>
<hr />
<div>I am a software engineer, mostly focused on Neutron. You can find me on irc, my nick is rossella-s .</div>Rossellahttps://wiki.openstack.org/w/index.php?title=User:Rossella&diff=43488User:Rossella2014-02-26T20:11:45Z<p>Rossella: Created page with "I am a software engineer, mostly focused on Neutron. You can find me in irc, my nick is rossella-s ."</p>
<hr />
<div>I am a software engineer, mostly focused on Neutron. You can find me in irc, my nick is rossella-s .</div>Rossellahttps://wiki.openstack.org/w/index.php?title=OpenStack_User_Groups&diff=31807OpenStack User Groups2013-10-08T08:42:34Z<p>Rossella: Added OpenStack Barcelona meetup</p>
<hr />
<div><!-- ## page was renamed from [[OpenStackUsersGroup]] --><br />
__NOTOC__<br />
<br />
Welcome to the list of the OpenStack User Groups!<br />
<br />
Can't find one nearby? Want to start one? The [[Teams#Community_team|OpenStack International Community team]] is your main contact point. Join [http://lists.openstack.org/cgi-bin/mailman/listinfo/community the mailing list] and read [[OpenStackUserGroups/HowTo|the HowTo page]] if you are hosting or want to start a user group with meetups, hackathons and other social events talking about OpenStack and free/libre open source software for the cloud. You can also edit this page to add your group, but remember - we're an [[Open]] community.<br />
<br />
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3"><br />
* '''[[#North America|North America]]'''<br />
** [[#Atlanta|Atlanta]]<br />
** [[#Austin|Austin]]<br />
** [[#Boston|Boston]]<br />
** [[#Canada|Canada]]<br />
** [[#Chicago|Chicago]]<br />
** [[#Colorado|Colorado]]<br />
** [[#District_of_Columbia_:_Washington.2C_DC_Metro_Area|District of Columbia : Washington, DC Metro]]<br />
** [[#Florida|Florida]]<br />
** [[#Indiana|Indiana]]<br />
** [[#Michigan|Michigan]]<br />
** [[#Minnesota|Minnesota]]<br />
** [[#Los Angeles|Los Angeles]]<br />
** [[#New York City|New York City]]<br />
** [[#North Carolina|North Carolina]]<br />
** [[#Philadelphia|Philadelphia]]<br />
** [[#San_Antonio.2C_Texas|San Antonio, Texas]]<br />
** [[#San Francisco Bay Area|San Francisco Bay Area]]<br />
** [[#Seattle|Seattle]]<br />
* '''[[#Africa|Africa]]'''<br />
** [[#Kenya|Kenya]]<br />
** [[#Nigeria|Nigeria]]<br />
* '''[[#Asia_.2F_Pacific|Asia / Pacific]]'''<br />
** [[#Australia|Australia]]<br />
*** [[#Canberra_.28ACT.29|Canberra]]<br />
** [[#China|China]]<br />
** [[#Hong Kong|Hong Kong]]<br />
** [[#India|India]]<br />
** [[#Indonesia|Indonesia]]<br />
** [[#Japan|Japan]]<br />
** [[#Malaysia|Malaysia]]<br />
** [[#New Zealand|New Zealand]]<br />
** [[#Singapore|Singapore]]<br />
** [[#South Korea|South Korea]]<br />
** [[#Taiwan|Taiwan]]<br />
** [[#Thailand|Thailand]]<br />
** [[#Vietnam|Vietnam]]<br />
* '''[[#Latin America|Latin America]]'''<br />
** [[#Argentina|Argentina]]<br />
** [[#Brazil|Brazil]]<br />
** [[#Ecuador|Ecuador]]<br />
** [[#Puerto Rico|Puerto Rico]]<br />
** [[#Venezuela|Venezuela]]<br />
* '''[[#Europe|Europe]]'''<br />
** [[#Austria|Austria]]<br />
** [[#Belgium|Belgium]]<br />
** [[#Czech Republic|Czech Republic]]<br />
** [[#Finland|Finland]]<br />
** [[#France|France]]<br />
** [[#Germany|Germany]]<br />
** [[#Greece|Greece]]<br />
** [[#Hungary|Hungary]]<br />
** [[#Netherlands|Netherlands]]<br />
** [[#Nordics_.28Scandinavia.29|Nordics (Scandinavia)]]<br />
** [[#Ireland|Ireland]]<br />
** [[#Italy|Italy]]<br />
** [[#Poland|Poland]]<br />
** [[#Russia|Russia]]<br />
** [[#Serbia|Serbia]]<br />
** [[#Slovenia|Slovenia]]<br />
** [[#South Eastern Europe|South Eastern Europe]]<br />
** [[#Spain|Spain]]<br />
** [[#Sweden|Sweden]]<br />
** [[#Switzerland|Switzerland]]<br />
** [[#UK|UK]]<br />
* '''[[#Middle East|Middle East]]'''<br />
** [[#Algeria|Algeria]]<br />
** [[#Cyprus|Cyprus]]<br />
** [[#Egypt|Egypt]]<br />
** [[#Israel|Israel]]<br />
** [[#Morocco|Morocco]]<br />
** [[#Turkey|Turkey]]<br />
** [[#UAE|UAE]]<br />
* '''[[#Language specific|Language specific]]'''<br />
</div><br />
<br />
== North America ==<br />
=== Atlanta ===<br />
* Meet-up details here: http://www.meetup.com/openstack-atlanta/<br />
* IRC Channel: [[irc://irc.freenode.net/openstack-atlanta|#openstack-atlanta]] on Freenode<br />
* Coordinators: Doug Hellmann, Mark McClain<br />
<br />
=== Austin ===<br />
* Meet-up details here: [http://www.meetup.com/openstack-austin/ http://www.meetup.com/openstack-austin/]<br />
<br />
=== Boston ===<br />
* Meet-up details here: http://www.meetup.com/Openstack-Boston/<br />
<br />
=== '''Canada''' ===<br />
* Meetup: http://www.meetup.com/Canadian-OpenStack-Users-Group/<br />
* Website: http://canstack.ca<br />
* Twitter: http://twitter.com/canstack<br />
* Blog: http://blog.canstack.ca<br />
* IRC: #canstack on freenode<br />
* Meetup: http://www.meetup.com/OpenStackTO/<br />
* Google Groups: http://groups.google.com/group/canada-openstack-user-group/<br />
* LinkedIn Group: http://www.linkedin.com/groups/OpenStack-Canada-4151460<br />
* Google Group: http://groups.google.com/group/openstack-canada<br />
<br />
=== Chicago ===<br />
* Meet-up details here: http://www.meetup.com/meetup-group-NjZdcegA/<br />
* Coordinator: Steven Loving<br />
<br />
=== Colorado ===<br />
(primarily Northern Colorado)<br />
<br />
* Meet-up details here: http://www.meetup.com/OpenStack-Colorado/<br />
<br />
(primarily Denver Metro/South Denver)<br />
<br />
* Meet-up details here: http://www.meetup.com/OpenStack-Denver/ <br />
* Twitter hashtag: #OSROCK<br />
* Coordinator: Shannon McFarland and Scott Lowe<br />
<br />
=== Connecticut ===<br />
*Home Page: http://www.meetup.com/Openstack-Connecticut/<br />
*Next Meetup: Monday, August 19th, 2013 (Inaugural OpenStack CT meetup) - http://www.meetup.com/Openstack-Connecticut/events/129855852/<br />
*Twitter Handle: @OpenStackCT<br />
*Twitter Hashtag: #OpenStackCT<br />
*Organizers: Fran Loehmann, James Ruddy, Kenneth Hui, Michael Brito, Michael Dugan<br />
<br />
=== District of Columbia : Washington, DC Metro Area ===<br />
* Meet-up details here: http://www.meetup.com/OpenStackDC/<br />
* Meet-up details here: http://www.linkedin.com/groups?gid=4207039<br />
<br />
=== Florida ===<br />
* LinkedIn: http://www.linkedin.com/groups?gid=4762393<br />
* FaceBook: http://www.facebook.com/FloridaOpenstack<br />
* Google Group: https://groups.google.com/d/forum/openstack-florida<br />
* Coordinator: [mailto:Trevor.Lowing@gmail.com Trevor Lowing]<br />
=== Indiana ===<br />
* Meet-up details: http://tinyurl.com/7k8b7mr<br />
* Forum: https://portal.futuregrid.org/forums/fg-user-services-forum/openstack<br />
* Contact: Gregor von Laszewski<br />
<br />
=== Michigan ===<br />
* Google Group: https://groups.google.com/d/forum/openstack-mi<br />
* Google Community: https://plus.google.com/communities/104709877702253658956<br />
* LinkedIn user group: http://www.linkedin.com/groups?home=&gid=4755132<br />
* Coordinator: Eric Detterman<br />
<br />
=== Minnesota ===<br />
* Meet-up details: http://www.meetup.com/Minnesota-OpenStack-Meetup//<br />
* Twitter hashtag: #MNOS<br />
* Contact/Coordinator: Kyle Mestery<br />
<br />
=== Los Angeles ===<br />
* Meetup details here: http://www.meetup.com/OpenStack-LA<br />
* LinkedIn user group: http://www.linkedin.com/groups?gid=4327316<br />
* Twitter hashtag: #OSLAX<br />
* Coordinator: Mike Perez, Matthew Wodrich<br />
<br />
=== New York City ===<br />
*Home Page: http://www.meetup.com/OpenStack-New-York-Meetup/<br />
*Next Meetup: Wednesday, July 17th, 2013 (OpenStack Global 3rd Birthday Celebration) - http://www.meetup.com/OpenStack-New-York-Meetup/events/125809072/<br />
*Twitter Handle: @OpenStackNYC<br />
*Twitter Hashtag: #OpenStackNYC<br />
*E-mail: openstacknyc@gmail.com<br />
*Organizers: AppFirst, Jason Edelman, Denis Guyadeen, Kenneth Hui, Judd Maltin<br />
<br />
=== North Carolina ===<br />
* Meetup March 7, 2013: http://www.meetup.com/Triangle-OpenStack-Meetup/events/100075312/<br />
* Coordinators: Mark Voelker, Arvind Somya, Amy Lewis<br />
<br />
=== Philadelphia ===<br />
*Home Page: http://www.meetup.com/Philly-OpenStack-Meetup-Group/<br />
*Next Meetup: Tuesday, August 20th, 2013 (How are you using OpenStack?) - http://www.meetup.com/Philly-OpenStack-Meetup-Group/events/128222352/<br />
*Twitter Handle: @OpenStackPhilly<br />
*Twitter Hashtag: #OpenStackPhilly<br />
*Organizers: Kenneth Hui, Paul Richards<br />
<br />
=== San Antonio, Texas ===<br />
* Next meeting: Tuesday 21 May, 2013 @ Rackspace (also a Hangout will be hosted on the G+ community page)<br />
* Meetup details here: http://www.meetup.com/SA-Open-Stackers/<br />
* Community Page at https://plus.google.com/communities/104303691151444174690<br />
* Coordinator(s): Wendel Hope<br />
<br />
=== San Francisco Bay Area ===<br />
* Meet-up details here: http://www.meetup.com/openstack/<br />
<br />
=== Seattle ===<br />
* Meet-up details here: http://www.meetup.com/OpenStack-Seattle/<br />
* Calendar: http://www.meetup.com/OpenStack-Seattle/events/calendar/<br />
* Coordinator: Mark Atwood of HP Cloud and Joseph Heck of Nebula<br />
<br />
== Africa ==<br />
* OpenStack Africa Google+ Community: https://plus.google.com/u/0/communities/106463180296945913906<br />
* Coordinator: Adam Nelson (adam@kili.io)<br />
<br />
=== Kenya ===<br />
* Meetup: http://www.meetup.com/OpenStack-Nairobi<br />
* Coordinator: Adam Nelson (adam@kili.io)<br />
<br />
=== Nigeria ===<br />
* Coordinator: Abayomi Ayoola (a 'dot' ayoola 'at' gmail 'dot' com)<br />
<br />
== Asia / Pacific ==<br />
<br />
=== Australia ===<br />
* Meet-up details here: http://aosug.openstack.org.au<br />
* Coordinator: Tristan Goode<br />
* Google Group: http://groups.google.com/group/openstack-au<br />
<br />
==== Canberra (ACT) ====<br />
* Meetup: http://www.meetup.com/Canberra-OpenStack-Users-Group/<br />
* LinkedIn Group: http://www.linkedin.com/groups?gid=4323576<br />
* Coordinator: Kristoffer Sheather<br />
<br />
=== China ===<br />
* [http://trystack.cn/ Trystack] Google Group: https://groups.google.com/d/forum/trystack-china<br />
* Twitter: [https://twitter.com/openstackchina @OpenStackChina] [http://www.slideshare.net/ben_duyujie/ Slideshare]<br />
* Weibo: [http://weibo.com/cosug @COSUG](China OpenStack User Group) or [http://weibo.com/trystack @trystack]<br />
* http://groups.google.com/group/china-openstack-user-group<br />
* LinkedIn Group: [http://www.linkedin.com/groups/openstackchina-4034145?home=&gid=4034145&trk=anet_ug_hm openstack-china]<br />
* Twitter: @OpenStackCN<br />
* Weibo: [http://weibo.com/openstack @OpenStack]<br />
* Coordinator: Hui Cheng< freedomhui@gmail.com >, ben( duyujie[dot]dyj[at]gmail[dot]com/[http://weibo.com/u/1716287123 Weibo:@ben_杜玉杰])<br />
<br />
=== Hong Kong ===<br />
* Website: http://osug.cyberport.hk<br />
* Facebook: https://www.facebook.com/groups/hkosug/<br />
* Forum: https://groups.google.com/d/forum/hong-kong-cloud-technology-sig<br />
* Google+: https://plus.google.com/u/0/communities/112611801924078008731<br />
* Coordinator: [mailto:brucelok@cyberport.hk Bruce Lok | HK Cyberport ]; [mailto:raymondchan@cyberport.hk Raymond Chan | HK Cyberport ]<br />
<br />
=== India ===<br />
* Meetup Page: http://www.meetup.com/Indian-OpenStack-User-Group<br />
* Subscribe to community mailing list sending an email to openstackindia@librelist.com<br />
* Facebook Page: http://www.facebook.com/groups/328814400511881/<br />
* LinkedIn: http://www.linkedin.com/groups/OpenStack-India-4005742<br />
* Twitter: https://twitter.com/openstackindia<br />
* Slideshare: http://www.slideshare.net/openstackindia<br />
* Coordinators: Deepak Garg ( Email: deepakgarg[dot]iitg[at]gmail[dot]com Launchpad Id: deepak.garg ] Kavit Munshi(@kavitaptira) Ritesh Nanda(@riteshnanda09) Syed Armani(@syedarmani) Sajid Akhtar(@mail2fashion ) Atul Jha(@koolhead17 , "Malyadri Beegala" <malyadri[dot]beegala[at]gmail.com> (Hyderabad events), "Srikanth Minnam" <srikanth[dot]minnam[at]gmail.com> (Hyderabad events)<br />
<br />
==== Pune, India ====<br />
* Meetup Page: http://www.meetup.com/OpenStack-Pune<br />
* Coordinators : Rajdeep Dua ( Email : dua_rajdeep[at]yahoo[dot]com )<br />
* Twitter Handle : #openstackpune<br />
<br />
=== Indonesia ===<br />
* Home page: http://www.openstack-id.org<br />
* Mailing list/forum: openstack-id@googlegroups.com<br />
* Coordinator: Frans Thamura ( frans@meruvian.org ) and (b-frans)<br />
<br />
=== Japan ===<br />
* Home Page: http://openstack.jp/<br />
* Mailing List : http://groups.google.com/group/openstack-ja<br />
* Coordinator: Masanori Itoh (thatsdone)<br />
<br />
=== Malaysia ===<br />
* Home page: http://www.openstack.my<br />
* Mailing list/forum: https://www.facebook.com/groups/openstackmy<br />
* Coordinator: Khairul Aizat ( fenris@ubuntu.com ) and Mohammad Hafiz ( mypapit@gmail.com )<br />
<br />
===Singapore===<br />
*Facebook: https://www.facebook.com/groups/sgopenstack<br />
*Homepage: http://openstack-sg.org<br />
*Google Groups: http://groups.google.com/group/openstack-singapore-users-group<br />
*IRC Channel: #openstack-sg on Freenode<br />
*Launchpad: https://launchpad.net/~openstack-sg<br />
*Coordinator: [https://launchpad.net/~wickedpuppy wickedpuppy]<br />
<br />
=== South Korea ===<br />
* Home Page: http://www.openstack.or.kr<br />
* Facebook Group: http://www.facebook.com/groups/openstack.kr/<br />
* Coordinator: [https://launchpad.net/~bluejay-ahn Jaesuk Ahn]<br />
<br />
=== Taiwan ===<br />
* Home page: http://groups.google.com/group/twosug2011?hl=zh-TW<br />
* Mailing list: twosug2011@googlegroups.com<br />
* Coordinator: Yoyo Chiang<br />
<br />
=== Thailand ===<br />
* Home page: http://blog.sushicloud.cs.tu.ac.th/?cat=14<br />
* Coordinator: Kasidit Chanchio ( kasiditchanchio@gmail.com , kasidit@cs.tu.ac.th )<br />
<br />
=== Vietnam ===<br />
* Facebook page: https://www.facebook.com/VietOpenStack<br />
* Official Mailing list: [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-vi Subscribe online], [http://lists.openstack.org/pipermail/openstack-vi/ Archives]<br />
* Coordinator: Giang Duong ( vietopenstack@dtt.vn )<br />
<br />
==Latin America==<br />
<br />
=== Argentina ===<br />
* Google Group: http://groups.google.com/group/openstack-argentina/<br />
* Contact: Leandro Reox of [[MercadoLibre]]<br />
* Official mailing list in Spanish: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-es [http://lists.openstack.org/pipermail/openstack-es/ Archives]<br />
<br />
=== Brazil ===<br />
* Google Groups: http://groups.google.com/group/openstack-br<br />
* Facebook Page: http://www.facebook.com/openstackbr<br />
* Twitter: @openstackbr<br />
* Coordinator: [http://wiki.openstack.org/Alexandre%20Haguiar Alexandre Aguiar]<br />
<br />
=== Ecuador ===<br />
* Google community: https://plus.google.com/communities/102070666375831873027?hl=es<br />
* Linkedin: http://www.linkedin.com/groups/OpenStack-Ecuador-5012947/about<br />
*Twitter: https://twitter.com/OpenStackEC<br />
* Coordinator: Daniel Núñez<br />
* Official mailing list in Spanish: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-es [http://lists.openstack.org/pipermail/openstack-es/ Archives]<br />
<br />
== Puerto Rico ==<br />
* Coordinator: Angel Berrios of http://www.dreyfous.com<br />
* Contact: aberrios@dreyfous.com<br />
* Google Group: https://groups.google.com/forum/?hl=en#!forum/openstack-puerto-rico<br />
* Official mailing list in Spanish: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-es [http://lists.openstack.org/pipermail/openstack-es/ Archives]<br />
<br />
=== Venezuela ===<br />
* Google+: https://plus.google.com/communities/118105990522935078913<br />
* Forum: https://groups.google.com/d/forum/openstack-ve<br />
* Twitter: @openstackve<br />
* Coordinator: Ender Mujica ( emujicad at gmail.com )<br />
* Official mailing list in Spanish: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-es [http://lists.openstack.org/pipermail/openstack-es/ Archives]<br />
<br />
==Europe==<br />
<br />
=== Austria ===<br />
* Meetup group: http://www.meetup.com/OpenStack-DACH/<br />
* Coordinator: Martin Loschwitz (madkiss)<br />
<br />
=== Belgium ===<br />
* LinkedIn Group: http://www.linkedin.com/groups?gid=4817141<br />
* Coordinators: Karel Striegel, Tom Degroote<br />
<br />
=== Czech Republic ===<br />
*LinkedIn Group: http://www.linkedin.com/groups/OpenStack-Czech-User-Group-Meetup-5118912?trk=myg_ugrp_ovr<br />
*Meetup group: http://www.meetup.com/OpenStack-Czech-User-Group-Meetup/<br />
*Coordinator: Stanislav Polášek<br />
*Mailing list: TBD<br />
<br />
=== Finland ===<br />
* LinkedIn Group - http://tinyurl.com/openstackfinland<br />
* Twitter - @OpenstackFIN<br />
* Coordinator: Ilkka Turunen - [firstname].[lastname]@jamk.fi<br />
* Mailing list: TBD<br />
<br />
=== France ===<br />
<br />
'''Paris area:'''<br />
* Meetup: http://www.meetup.com/OpenStack-France<br />
* French User Group : http://openstack.fr<br />
* http://cloud-oss-fr.blogspot.com/<br />
* Google Groups: http://groups.google.com/group/openstack-france?hl=fr<br />
* LinkedIn: [http://www.linkedin.com/groups/OpenStack-France-3993018?home=&gid=3993018&trk=anet_ug_hm&goback=.anp_3993018_1310075735312_1 http://www.linkedin.com/groups/OpenStack-France-3993018?home=&gid=3993018&trk=anet_ug_hm&goback=%2Eanp_3993018_1310075735312_1]<br />
<br />
'''Rhône-Alpes (Lyon/Grenoble/Geneva) region:'''<br />
* Meetup: http://www.meetup.com/OpenStack-Rhone-Alpes/<br />
<br />
=== Germany ===<br />
* OpenStack Germany<br />
:* Meet-up details here: https://www.xing.com/net/pri3642a8x/openstack-germany/<br />
:* Coordinator: Christian Berendt (berendt on launchpad, berendt 'at' b1-systems 'dot' de)<br />
* OpenStack DACH<br />
:* Meetup group: http://www.meetup.com/OpenStack-DACH/<br />
:* Coordinator: Martin Loschwitz (madkiss)<br />
<br />
=== Greece ===<br />
* Meetup: http://www.meetup.com/Athens-OpenStack-User-Group<br />
* Google community: https://plus.google.com/communities/113761625022392052075<br />
* Coordinator: Thanassis Parathyras<br />
<br />
=== Hungary ===<br />
* Meet-up details here: http://www.meetup.com/OpenStack-Hungary-Meetup-Group/<br />
* Coordinator: Marton Kiss (marton 'dot' kiss 'at' xemeti 'dot' com)<br />
<br />
=== Netherlands ===<br />
* Meet-up details here: http://www.meetup.com/Openstack-Amsterdam<br />
* Coordinator: Alessandro Vozza (alessandro <at> ams0.org , twitter: @bongo)<br />
* Google community: https://plus.google.com/u/1/communities/115207580745787867740<br />
<br />
=== Nordics (Scandinavia) ===<br />
* Twitter: http://twitter.com/OSNordics<br />
* Meet-up: http://www.meetup.com/OpenStack-User-Group-Nordics/<br />
* LinkedIn: http://www.linkedin.com/groups/OpenStack-Nordics-4764289<br />
* Coordinator - See each Country for it's coordinator.<br />
<br />
=== Ireland ===<br />
* Meetup details here: http://www.meetup.com/OpenStack-Ireland<br />
* Twitter - @OpenstackIRL<br />
* Coordinator: Tim Horgan - [firstname].[lastname]@cit.ie<br />
<br />
=== Italy ===<br />
* Meetup: http://www.meetup.com/OpenStack-User-Group-Italia/<br />
* Official mailing list: [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-it Subscribe online], [http://lists.openstack.org/pipermail/openstack-it/ Archives]<br />
* Coordinators: Davide Guerri ( davide.guerri@gmail.com ), Martina, Flavio Percoco Premoli, Mariano Cunietti, Mariano Iumiento<br />
<br />
=== Poland ===<br />
* Home page: [http://www.openstack.org.pl/ www.openstack.org.pl]<br />
* LinkedIn: [http://www.linkedin.com/groups?home=&gid=4950277&trk=anet_ug_hm OpenStack-Poland]<br />
* Meetup: [http://www.meetup.com/OpenStack-User-Group-Poland/ OpenStack-User-Group-Poland Meetup]<br />
*Google Hangout: [https://www.youtube.com/user/OpenStackPoland www.youtube.com/user/OpenStackPoland]<br />
*Coordinators: Marcin Wiciński (m.wicinski@openstack-poland.org), Rafael Knuth (rafael.knuth@openstack-poland.org)<br />
<br />
=== Russia ===<br />
* Home page: http://www.oscloud.ru/<br />
* Facebook: https://www.facebook.com/groups/openstack.russia/<br />
* LinkedIn: http://www.linkedin.com/groups?gid=4109150<br />
* Coordinator: [http://wiki.openstack.org/IlyaAlekseyev Ilya Alekseyev]<br />
<br />
=== Serbia ===<br />
* Home page: http://www.openstack.rs<br />
* Coordinator: [https://launchpad.net/~gerzic gerzic]<br />
<br />
=== Slovenia ===<br />
* Forum: https://groups.google.com/forum/?fromgroups#!forum/openstack-slovenija<br />
* LinkedIn: http://www.linkedin.com/groups/OpenStack-Slovenija-4793209?trk=myg_ugrp_ovr<br />
* Facebook: https://www.facebook.com/OpenstackSlovenija<br />
<br />
=== South Eastern Europe ===<br />
* Forum: https://groups.google.com/forum/#!forum/openstack-south-eastern-europe<br />
* LinkedIn: http://www.linkedin.com/groups/OpenStack-South-Eastern-Europe-4884630?trk=myg_ugrp_ovr<br />
<br />
=== Spain ===<br />
* https://plus.google.com/u/0/communities/102652393437279778000<br />
* http://groups.google.com/group/spain-openstack-user-group<br />
* Official mailing list in Spanish: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-es [http://lists.openstack.org/pipermail/openstack-es/ Archives]<br />
* http://twitter.com/openstackspain<br />
* Openstack Barcelona http://www.meetup.com/OpenStack-Barcelona<br />
<br />
=== Sweden ===<br />
* Meetup page: http://www.meetup.com/OpenStack-User-Group-Nordics/<br />
* Twitter: http://twitter.com/OpenStackSE<br />
* Coordinator: [https://launchpad.net/~n-paladi Nicolae Paladi]<br />
<br />
=== Switzerland ===<br />
* Home page: http://openstack.ch/<br />
* Coordinator: Thomas Michael Bohnert, [https://launchpad.net/~andy-edmonds Andy Edmonds], [https://launchpad.net/~al-maisan Muharem Hrnjadovic]<br />
<br />
=== UK ===<br />
* http://www.meetup.com/OpenStack-London<br />
<br />
==Middle East==<br />
<br />
=== Algeria ===<br />
* http://www.meetup.com/OpenStack-Algeria<br />
<br />
=== Cyprus ===<br />
* [http://www.meetup.com/OpenStack-Cyprus-Community/ Meetup Group]<br />
* http://www.meetup.com/OpenStack-Cyprus-Community/ <br />
* Coordinator: Sergios Charalambous<br />
<br />
=== Egypt ===<br />
* http://groups.google.com/group/egypt-openstack-user-group<br />
* Mailing list: egypt-openstack-user-group@googlegroups.com<br />
* Coordinator: Mohamed El-Refaey ( mohamed@egyptcloudforum.com )<br />
<br />
=== Israel ===<br />
* Home page: http://www.openstack-israel.org/<br />
* Meetup details here: http://www.meetup.com/igtcloud/<br />
* Twitter: https://twitter.com/OpenStackIL<br />
* Coordinator: Nati Shalom @natishalom<br />
<br />
=== Morocco ===<br />
* Meet-up details here: http://www.meetup.com/Morocco-OpenStack-Users-Group<br />
* Coordinators: Youssef LARGOU<br />
<br />
=== New Zealand ===<br />
* Meet-up page: http://www.meetup.com/New-Zealand-OpenStack-User-Group/<br />
<br />
=== Turkey ===<br />
* Coordinator: Ali Bugdayci ( Borsoftware )<br />
* Twitter: https://twitter.com/OpenStackTurkey<br />
<br />
=== UAE ===<br />
* Meetup Page: http://www.meetup.com/U-A-E-OpenStack-User-Group/<br />
* Facebook Page: https://www.facebook.com/groups/280298292070983/<br />
* LinkedIn: http://www.linkedin.com/groups/OpenStack-UAE-4653922?gid=4653922<br />
* Twitter: https://twitter.com/OpenStackUAE<br />
<br />
== Language specific ==<br />
* Official mailing list in Spanish: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-es [http://lists.openstack.org/pipermail/openstack-es/ Archives]</div>Rossella