https://wiki.openstack.org/w/api.php?action=feedcontributions&user=Arkady&feedformat=atomOpenStack - User contributions [en]2024-03-29T05:40:36ZUser contributionsMediaWiki 1.28.2https://wiki.openstack.org/w/index.php?title=Governance/InteropWG/Minutes2021&diff=180498Governance/InteropWG/Minutes20212022-01-28T21:14:55Z<p>Arkady: Converted from Etherpad to wiki for 2021 meeting notes</p>
<hr />
<div>These are minutes of Interop WG weekly meetings<br />
<br />
== Dec 23rd and 30th no meetings - holidays ==<br />
<br />
== Meeting Thursday Dec 16 (1600 UTC) ==<br />
Attendees: Martin will be few minutes late, Vida (meeting link doesn't work!) oh .. let's switch to Google meet for this time only? sure, https://meet.google.com/zgk-facv-hcq, <br />
Agenda:<br />
Our new taiga board: https://tree.taiga.io/project/openstack-interop-working-group ++<br />
reviews:<br />
https://review.opendev.org/c/openinfra/refstack-client/+/821325 -1<br />
https://review.opendev.org/c/openinfra/refstack-client/+/819918 -1<br />
https://review.opendev.org/c/openinfra/refstack-client/+/819919 -2<br />
https://review.opendev.org/c/openinfra/interop/+/817001 +2<br />
<br />
== Meeting Thursday Dec 9 (1600 UTC) ==<br />
Attendees: Martin, Vida, Arkady, Goutham<br />
Agenda:<br />
2021.11 guidelines https://review.opendev.org/c/openinfra/interop/+/819029/ ++<br />
(Martin) I think we can merge per Ghanshyam's comment and Jimmy's review - pushed the merged - done<br />
Once published we should let Jimmy to share with vendors: AI Arkady will handle it - done<br />
(Vida) Board meeting update - feedback to points noted in slides?<br />
slides: https://docs.google.com/presentation/d/1mn3eYjJ3YEyPWDdJXXtw8kwsMqY1vVW_I3EbKVi-jYQ/edit?usp=sharing<br />
AI Martin - email to Wes regarding the Copyright<br />
AI Martin - let's plan the work regarding the API microversions - we need to get the api microversion range used to run tempest (refstack-client) to the refstack server<br />
AI Martin: create a new presentation (expand 2 last slides from the previous one ^^) and explain in more details the current state of the programs, problems related and possible solution<br />
Where do we track AIs:<br />
https://taiga.io/ <br />
(Martin) +1<br />
AI: Move to taiga:<br />
set a new board - DONE<br />
put the current AIs there<br />
(Vida) Appears that refstack test list requires updating - Ref: question from kevko 12/8/21 on #refstack<br />
hi, anyone here ? I have question regarding test list - I think Cinder V2 is not supported anymore ..and because of this refstack certifications says i am missing tests ..<br />
how to deal with it ? <br />
example -> WARNING refstack_client.list_parser [-] Test tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_delete_volume_without_passing_volume_id not found in Tempest list.<br />
(Martin) thank you Vida for keeping an eye on the IRC channel .. I replied there<br />
https://meetings.opendev.org/irclogs/%23refstack/%23refstack.2021-12-09.log.html<br />
AI: supress the warning, refstack-client doesn't need to print warning that aliases are not present in tempest (that's expected) - we can print them with --verbose flag f.e.<br />
DONE by https://review.opendev.org/c/openinfra/refstack-client/+/821325<br />
(Vida) Question on guideline doc update patch - https://review.opendev.org/c/openinfra/interop/+/817001/5<br />
guidelines/2021.11.json L:315 "required_since": "",<br />
it's empty because that capability is under advisory (not required now) and it's unknown when it will be required (probably in the next guideline, depends on the results published on marketplace)<br />
<br />
== Meeting Thursday Dec 2 (1630 UTC) ==<br />
Attendees: Arkady, Martin, Goutham<br />
Agenda:<br />
python_requires >= 3.8 during Yoga<br />
f.e. refstack - https://opendev.org/openinfra/refstack/src/commit/8daea3e9086ecd4bbb394cb1878587b3760a5d0a/.zuul.yaml#L5<br />
https://docs.openstack.org/infra/openstack-zuul-jobs/project-templates.html<br />
refstack, refstack-client and python-tempestconf use openstack-python3-yoga-jobs zuul template which contains python3.8 job<br />
which means we are python3.8 ready<br />
the article is published \o/ https://superuser.openstack.org/articles/latest-marketplace-and-interop-working-group-update/ +++<br />
presentation for the board meeting:<br />
https://docs.google.com/presentation/d/1mn3eYjJ3YEyPWDdJXXtw8kwsMqY1vVW_I3EbKVi-jYQ/edit?usp=sharing<br />
https://review.opendev.org/c/openinfra/interop/+/819029++<br />
guideline doc update - https://review.opendev.org/c/openinfra/interop/+/817001/5<br />
<br />
== Meeting Thursday Nov 18 (1630 UTC) ==<br />
Attendees: Arkady, Martin, Vida<br />
Agenda:<br />
latest guidelines got merged - https://review.opendev.org/c/openinfra/interop/+/815995<br />
symlinks and doc updates (rst files out of the new guideline json ones) - AI: Arkady Update symlink file to new draft guidleines - https://review.opendev.org/c/openinfra/interop/+/819029<br />
update exclude file - AI Martin<br />
AI: Arkady submit PR to move guidelines to approved. Then send email and add TC, Foundation to review. - https://review.opendev.org/c/openinfra/interop/+/819029<br />
we have received some feedback on the test analysis<br />
https://etherpad.opendev.org/p/refstack-test-analysis<br />
AI Martin to go over it (and emails)<br />
https://review.opendev.org/q/topic:%2522update-interop-doc%2522+(status:open+OR+status:merged)<br />
in progress, AI Martin to update the openstack manuals<br />
https://review.opendev.org/c/openstack/nova/+/816980 - AI: Vida to review<br />
wiki notifications and openstack profile updates<br />
AI: Arkady update pointer to the draft of latest guidelines<br />
the article, we have gathered feedback, we may publish it - https://etherpad.opendev.org/p/refstack-highlights-wallaby<br />
here? - https://superuser.openstack.org/contribute/ - AI: Arkady to fill the form - submitted<br />
touching base with octavia folks<br />
good feedback at the PTG - project folks want to be involved in the add-on guideline creation<br />
need to follow up during a weekly meeting: https://wiki.openstack.org/wiki/Octavia#Meetings<br />
identify vendor agnostic API resources/actions and corresponding tests<br />
Feature matrix is here: https://docs.openstack.org/octavia/latest/user/feature-classification/index.html<br />
The next step is to find the tests we wanna include in an octavia guideline<br />
Write a draft of presentation for a board meeting in Dec - AI Martin - DONE<br />
IWG leader change<br />
report on new process that we folowed for new gudielines<br />
Get Marketplace entries for Add-on<br />
microservices handling - no simple way to handle it. We can not agree on one flow of testing<br />
Copyright notice: OPenstack -> OpenInfra one?<br />
SHoudl cinder be in Compute Logo requirement?<br />
Octavia as the next Add-on project<br />
<br />
== Meeting Thursday Nov 11 (1600 UTC) ==<br />
Attendees: Martin (only for first 30 minutes), Vida, Arkady<br />
Agenda:<br />
Meeting info update: https://review.opendev.org/c/opendev/irc-meetings/+/817225 - got 2 +2s, Leave to Martin to handle Workflow<br />
AI: Martin diff between all next files and corresponding 2021.11 ones - DONE<br />
Documentation<br />
https://review.opendev.org/q/topic:%2522update-interop-doc%2522+(status:open+OR+status:merged) - Arkady reveiwed<br />
the article: https://etherpad.opendev.org/p/refstack-highlights-wallaby - Arkady had reviewed and updated it 11/12/2022.<br />
Latest guidelines - https://review.opendev.org/c/openinfra/interop/+/815995<br />
Updated https://wiki.openstack.org/wiki/Governance/InteropWG - with new leadership team<br />
<br />
== Meeting Thursday Oct 28 and Nov 4 (1600 UTC) ==<br />
Attendees: Arkady, Vida, Martin<br />
Can't attend: Martin (public holiday Oct 28)<br />
Arkady dropped after 10 min. Will use this agenda for next week<br />
Agenda:<br />
https://review.opendev.org/c/openinfra/interop/+/815995 - latest guideline draft<br />
Martin commented<br />
AI: Martin will verify the test coverage for new compute-servers-tags-* capabilities - DONE<br />
AI: Martin email to Thierry on how vendors can express that their offering supports advisory APIs?<br />
AI: Arkady update path combing TAG ops into CRUD and removing dated for required for advisory capabilities - DONE<br />
PTG summary, the main goals we should focus on this cycle<br />
the way how we get feedback from teams regarding the new tests to track in interop guidelines<br />
the theory should be like - we are in touch with the projects and we are thinking about tests (which aren't written yet) to test upcomming features<br />
although right now (as the interop guidelines were neglected for some time) we can start with the feedback from the projects regarding already existing tests - the analysis etherpad we have<br />
do we have any vendors running refstack on clouds without cinder?<br />
cinder doesn't have to be present in a working openstack deployment - therefore there's the question whether cinder should be a part of core program<br />
currently there are no vendors who don't have cinder active in their clouds which they test with refstack<br />
Microversion testing - I personally still can't imagine how we will address this <br />
the article - finish and publish it so that we would raise an awerness about IWG<br />
https://etherpad.opendev.org/p/refstack-highlights-wallaby<br />
AI: ALL review by Nov 17 so we can publish<br />
<br />
Documentation check, please go through the documentation and:<br />
Is the Copyright at the bottom ok? What year should be there? Do we want Copyrigt be mentioned there at all? - That is the question to Thierry<br />
Feel free to add your comments here or propose changes yourself. - I think we are astill relying on sending email to Jimmy and Wes to make changes to these pages.<br />
the links for the docs:<br />
https://docs.opendev.org/openinfra/interop/latest/<br />
source: https://opendev.org/openinfra/interop/src/branch/master/doc/source<br />
Our mission is to define “OpenStack Core” that is supported by all implementations as chartered by the by-laws. - need to update it to match new terminology and process<br />
whole section on core defintion must be fully rewritten similarly what we had done for updated process for 2021.<br />
It does not look like these pages come from the documents that we had updated in the repo. They should come from it.<br />
https://docs.opendev.org/openinfra/refstack/latest/<br />
source: https://opendev.org/openinfra/refstack/src/branch/master/doc/source<br />
https://docs.opendev.org/openinfra/refstack-client/latest/<br />
source: https://opendev.org/openinfra/refstack-client/src/branch/master/doc/source<br />
Based on what i've noticed, we need to do at least the following:<br />
put link to the docs to the README of every project - the documentation has to be easy to find<br />
put the links to the wiki pages (after/when we move the content out of the wiki) AI: Arkady update Interop WIki to piint to docs and udpoate to current info<br />
mention the bug tracker links somewhere in the doc - we should have a Contributing page within the doc, which would explain how to start contributing to our projects<br />
search for "DefCore", other old names of IWG and our wiki links and update the occurrences (mention also the doc links)<br />
tool for searching in all openstack projects - https://codesearch.opendev.org/<br />
Arkady informed Allison Randall (chair of OFI) that Martin is new chair of Inetrop WG. Arkady and Martin are invited to the next board meeting for introduction and passing the chairmanship baton.++<br />
<br />
<br />
== Meeting Thursday Oct 14 (1630 UTC) ==<br />
- moved 30 minutes later only this time<br />
Attendees: Martin, Vida, Goutham, Arkady<br />
Agenda:<br />
patches:<br />
https://review.opendev.org/c/openinfra/refstack/+/813065 + - Martin will post a new patchset<br />
https://github.com/r1chardj0n3s/pip-check-reqs/issues/66 and https://github.com/r1chardj0n3s/pip-check-reqs/issues/70 seem to be the same issue<br />
https://opendev.org/openstack/octavia/src/branch/master/tox.ini#L235-L239 <br />
#AGREED: we don't need this job, drop it - DONE<br />
https://review.opendev.org/c/openinfra/refstack/+/813607 +<br />
https://review.opendev.org/c/openinfra/interop/+/813178 +<br />
https://review.opendev.org/c/openinfra/interop/+/809450 +<br />
https://review.opendev.org/c/openinfra/interop/+/808943 + <br />
https://review.opendev.org/c/openinfra/interop/+/809271<br />
draft of 2021.11 guidelines<br />
https://review.opendev.org/c/openinfra/interop/+/811049 <br />
it needs to be rebased on top of https://review.opendev.org/c/openinfra/interop/+/813178<br />
(Martin) I made a few comments, a few details need to be improved<br />
$ git review -d 813178<br />
$ git review -x 811049 <br />
<deal with potential conflict and implement changes pointed out in the comments><br />
FIPS support - Tempest is not fully ready for FIPS environments atm<br />
however there is a company trying to pass refstack tests while they env is running on FIPS cluster which leads to several failures<br />
who is empowered to grant an exception for trademark usage in this case?<br />
open infrastructure personnel <br />
FIPS testing across OpenStack projects: https://review.opendev.org/q/topic:%22add_fips_job%22+(status:open%20OR%20status:merged) <br />
Yoga generic presentation for PTG - https://docs.google.com/presentation/d/18fJP7wB-8fe1XdLgx1tlS028rVG5Sx556TGrHlH_W08/edit#slide=id.gf2d2574db4_0_16<br />
PTG plan - https://etherpad.opendev.org/p/yoga-ptg-interop<br />
update with project meeting times and dates for projects you are covering<br />
<br />
== Meeting Thursday Oct 7 (1600 UTC) ==<br />
Attendees: Martin, Vida, Arkady<br />
Agenda:<br />
Microversion testing - gouthamr is out this week, but some notes added to https://docs.google.com/presentation/d/18fJP7wB-8fe1XdLgx1tlS028rVG5Sx556TGrHlH_W08/edit#slide=id.gf2d2574db4_0_16<br />
an example of microversioned tests - https://pasteboard.co/KCVQ25q8m3PE.png<br />
how exactly are we gonna handle that in refstack-client?<br />
https://docs.google.com/presentation/d/18fJP7wB-8fe1XdLgx1tlS028rVG5Sx556TGrHlH_W08/edit#slide=id.gf53ddfa1fb_0_0 - Vida review comments<br />
https://www.openstack.org/marketplace/drivers/#project=manila%20(shared%20file%20storage)&vendor=ibm&release=all - Vida driver support versions<br />
^^ suggest adding some verbage to explain on the page <br />
https://opendev.org/osf/interop/src/branch/master/doc/source/guidelines/next.rst Vida - noticed broken links here<br />
(Martin) oh, yeah, I'll fix them<br />
PTG<br />
Swift PTG meeting schedueled at Monday, 16:00 UTC <br />
https://docs.google.com/presentation/d/18fJP7wB-8fe1XdLgx1tlS028rVG5Sx556TGrHlH_W08/edit#slide=id.p1<br />
2021.11 guidelines draft - https://review.opendev.org/c/osf/interop/+/811049<br />
Patches<br />
<br />
== Meeting Thursday Sept 30 (4pm UTC) ==<br />
Attendees: Arkady, Martin, Vida, Goutham, Thierry<br />
Agenda:<br />
2021.11 guidelines draft - https://review.opendev.org/c/osf/interop/+/811049<br />
Ongoing reviews<br />
still being worked on - great job so far by Martin's intern! Lukas and Roman ++<br />
Yoga generic presentation fpr PTG - https://docs.google.com/presentation/d/18fJP7wB-8fe1XdLgx1tlS028rVG5Sx556TGrHlH_W08/edit#slide=id.gf2d2574db4_0_16<br />
Gaouthma to add a sldie with the proposal on handling microservice APis<br />
Follow with Wes and Thierry on microservice proposal<br />
https://storyboard.openstack.org/#!/story/1638112 - Vida emailed Nova and cinder teams - review response<br />
http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025132.html<br />
<br />
== Meeting Thursday Sept 23 (4pm UTC) ==<br />
Attendees: Arkady, Martin, Goutham, Vida<br />
Agenda: <br />
Shared File System and Orchestration Add-on is now in Marketplace with Red Hat entry showing it - https://www.openstack.org/marketplace/distros/<br />
Catching up on PTG ToDos<br />
The draft guideline is in next.json, several new tests have been added<br />
Call attention to this at the interop interlock with the service projects<br />
Ask for +/-1s on the draft guidelines from the next.json files<br />
Action Item: Arkady will clone the next.json files into 2021.11 guidelines - https://review.opendev.org/c/osf/interop/+/811049<br />
Reviewers: TC, Marketplace folks, Project contributors, Interop/Refstack WG<br />
Goutham catching up on todos<br />
Keystone's session overlaps with manila: https://ethercalc.openstack.org/8tum5yl1bx43 <br />
Heat doesn't have a PTG session- we can follow with heat PTL thur emails<br />
https://storyboard.openstack.org/#!/story/1638112 - Vida reviewed need to revisit<br />
the capability - https://opendev.org/osf/interop/src/commit/dd7ae2660de5daa82ab4fe080e875d6326f88185/guidelines/2017.01.json#L1324-L1348<br />
it was removed in 2017.01<br />
contains 2 tempest tests which are still part of tempest<br />
https://opendev.org/openstack/tempest/src/commit/ae41052a51f5dbb748eb6bf4f23e9145853f4639/tempest/api/compute/volumes/test_volumes_list.py#L60<br />
https://opendev.org/openstack/tempest/src/commit/ae41052a51f5dbb748eb6bf4f23e9145853f4639/tempest/api/compute/volumes/test_volumes_list.py#L75<br />
VIda to send email to openstack and for Nova and Cinder and ask for these API usage, if they are still needed.<br />
PTG planning preparation - https://etherpad.opendev.org/p/yoga-ptg-interop or https://etherpad.opendev.org/p/yoga-ptg-interop) ?<br />
staging meeting <br />
roles and responsibilites<br />
reference old sessions?<br />
Arkady to create a generic presentation that people can use for each project meeting - done - https://docs.google.com/presentation/d/18fJP7wB-8fe1XdLgx1tlS028rVG5Sx556TGrHlH_W08/edit#slide=id.gf2d2574db4_0_16<br />
refstack has 2 bug trackers, we need to close what we can and the rest merge together, we should probably stick with the storyboard as that's what we have for refstack-client and interop:<br />
https://bugs.launchpad.net/refstack<br />
https://storyboard.openstack.org/#!/project/osf/refstack<br />
<br />
== Meeting Friday Sept 17 (2pm UTC) ==<br />
Attendees: Martin, Vida, Arkady<br />
Agenda: <br />
meeting time change<br />
http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024820.html<br />
https://doodle.com/poll/2477h9mm9er4ecnn<br />
the most voted time slot is Thursdays at 4pm UTC<br />
Arkady AI: update invite, and submit patches for updating wiki - done<br />
Will start new time slot next week<br />
https://wiki.openstack.org/wiki/Governance/InteropWG#Meetings - done<br />
https://review.opendev.org/c/opendev/irc-meetings/+/809903 - done<br />
Interop docs:<br />
https://review.opendev.org/c/osf/interop/+/808943 - Prettify rendering<br />
https://review.opendev.org/c/osf/interop/+/809271 - WIP atm - publish docs to docs.opendev.org - we shouldn't point to gitea<br />
Do we want to move the content from the wiki to the docs.opendev.org server?<br />
https://wiki.openstack.org/wiki/Governance/InteropWG<br />
let's put this on the TC agenda<br />
let's discuss on PTG and decide after<br />
https://review.opendev.org/c/osf/interop/+/809017 - Fix a few discrepancies<br />
rename from osf/, x/ to openinfra/ updates:<br />
https://review.opendev.org/c/openstack/project-config/+/765787<br />
https://review.opendev.org/c/openstack/project-config/+/808479<br />
https://storyboard.openstack.org/#!/story/1579132 - Martin will close it per the comments there<br />
<br />
<br />
== Meeting Friday Sept 10 (2pm UTC) ==<br />
Attendees: Arkady, Martin<br />
Agenda:<br />
review status of patches<br />
all approved except this one - https://review.opendev.org/c/osf/interop/+/800899<br />
all the patches are chainged, after ^^ gets merged the others will too<br />
https://review.opendev.org/c/osf/interop/+/804498<br />
ddt issue - test names are dynamically created based on intput data<br />
https://review.opendev.org/c/osf/interop/+/808047<br />
https://review.opendev.org/c/osf/interop/+/806598<br />
This approach to testing with single test anme and passing different parameters need to be discussed with Designated, Manila and TC<br />
how to handle unique naming comvention UUID?<br />
dependency between multuple tests with the same name?<br />
https://opendev.org/openstack/designate-tempest-plugin/src/commit/da27a70ae2b39695ef6f03bbefb55afeacf1cdf3/designate_tempest_plugin/tests/api/v2/test_recordset.py#L87<br />
https://opendev.org/openstack/designate-tempest-plugin/src/commit/da27a70ae2b39695ef6f03bbefb55afeacf1cdf3/designate_tempest_plugin/tests/api/v2/recordset_data.json<br />
review status of storyboard items https://storyboard.openstack.org/#!/project/osf/interop<br />
https://review.opendev.org/c/openstack/project-config/+/765787 - Martin can you update the patch?<br />
PTG preparation<br />
Marketplace update<br />
Red Hat submitted add-on results for Orchestration and Shared File System for 2020-11 guidelines. Results are not published yet on Marketplace.<br />
article - https://etherpad.opendev.org/p/refstack-highlights-wallaby<br />
(kopecmartin) I wrote a few additions<br />
Proposed new day and time for the meetings - Monday 10:00am CT - email sent<br />
<br />
== Meeting Friday Sept 3 (2pm UTC) ==<br />
Attendees: Arkady, Martin, Vida<br />
The same Agenda as for August 27<br />
AI: Arkady to write down what are Chair's responsibilities.<br />
Martin is a candidate for Chairmanship for Yaga, and Vida as co-chair likely in future cycles.<br />
Expect that we will skipp guidelines fro Wallaby addition and will proceed to guideliens for Xena. Target draft for September.<br />
https://etherpad.opendev.org/p/interop-new-guideline-release<br />
Discussion about tracking inteop issues between vendors who have been certified (Thiery)<br />
<br />
== Meeting Friday August 27- (2pm UTC) ==<br />
Attendees: Arkady, Vida, Martin (we are on jitsi bridge https://meetpad.opendev.org/interop )<br />
Nobody showed up. WIll try next week<br />
Vida unable to attend, conflicts with Manila event for August 20<br />
Martin declined for August 20<br />
Topics:<br />
Yoga PTG sync with TC - https://etherpad.opendev.org/p/tc-yoga-ptg<br />
include hacking in test-requirements to improve quality of the code - https://review.opendev.org/c/osf/interop/+/804836<br />
jsonToRst.py update in progress - https://review.opendev.org/c/osf/interop/+/804498<br />
please try it out and throw any suggestions mainly in regards of the generated .rst content<br />
very nice. comments added<br />
Agreed to have single sceript to handle both single guideline as well as all guidelines (core and add-ons) for specific release<br />
Looks like verification failing for all approved patches. What can/should we do?<br />
script for cross checking tests in tempest (and plugins) and in interop:<br />
https://review.opendev.org/c/osf/interop/+/799201<br />
(Martin) I'm trying to form a policy/set of steps needed in order to create a new guideline<br />
https://etherpad.opendev.org/p/interop-new-guideline-release - looks good , one comment (Arkady)<br />
Please, add your progress on PTG scheduling of projects are covering<br />
cinder scheduled<br />
https://etherpad.opendev.org/p/nova-yoga-ptg - Nova scheduled Wed Oct 20 15:00 UTC - 15:30<br />
https://etherpad.opendev.org/p/yoga-ptg-glance-planning - data and time TBD<br />
superuser article progress<br />
<br />
== Meeting Friday August 6 - (2pm UTC) ==<br />
Attendees: Arkady, Vida<br />
Topics:<br />
PTG planning - revisit<br />
Time slots changed from planned date/times L:66 - correct. That is to avoid overlap with QA<br />
Confirmed no overlap with Manila timeslot<br />
Tu Oct 19 14-16 UTC & Fr Oct 22 13-14 UTC<br />
PTG planning below<br />
Tentative PTG planning - https://etherpad.opendev.org/p/yoga-ptg-interop<br />
<br />
== Meeting Friday July 23 - (2pm UTC) ==<br />
Attendees: Arkady, Vida, Martin, Thierry<br />
Topics:<br />
Yoga PTG planning<br />
Project sync coverage proposal<br />
Check the time for a project you are covering<br />
schedule a time for that project PRG <br />
Share draft of guidelines and ask for feedback so we can finalize next guidelines<br />
nova - Arkady<br />
neutron - Martin - http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024827.html<br />
keystone - Goutham<br />
glance - Arkady<br />
cinder - Arkady<br />
https://etherpad.opendev.org/p/yoga-ptg-cinder-planning Requested for Tu 16:30-16:45 UTC <br />
swift - Arkady<br />
manila - Vida/Goutham<br />
heat - Goutham<br />
designate - Martin - http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024828.html<br />
barbican - Prakash (key-management mainkly pkcs11# - last changes to Barbican was in Stein https://releases.openstack.org/stein/highlights.html#barbican ) <br />
quotas for secrets, containers, orders, consumers, and CAs. secrets metadat (eg. consumer is octavia for load balacing TLS traffic with keys)<br />
https://docs.openstack.org/api-guide/key-manager/<br />
octavia - Goutham<br />
TC - Martin<br />
https://etherpad.opendev.org/p/tc-yoga-ptg<br />
the exact date will be added once the agenda is finilized<br />
Agenda - https://etherpad.opendev.org/p/yoga-ptg-interop)<br />
Tu 14-16 UTC & Friday 13-14 UTC <br />
superuser article - Prakash - Not clear if this is to be based on 2020.11 or 2021.07 which is still not ready<br />
Open patches<br />
https://review.opendev.org/c/osf/interop/+/799163 - need one more +2 - done Prakash<br />
https://review.opendev.org/c/osf/interop/+/799201 - cleared code review +2 from my side<br />
https://review.opendev.org/c/osf/interop/+/800795 - Abandoned<br />
https://review.opendev.org/c/osf/interop/+/801054 - Failed state - Advisory issue ( https://meetings.opendev.org/meetings/cinder/2021/cinder.2021-05-12-14.00.log.html#l-56) + zuul gating error <br />
https://review.opendev.org/c/osf/interop/+/801039 - zuul gating error - added commnets on https://zuul.opendev.org/t/openstack/job/neutron-functional<br />
https://review.opendev.org/c/osf/interop/+/800946 - same as cindeer v3 vs v2 issue - cinderclient.exceptions.UnsupportedVersion: Invalid client version '2.0'. Major part should be '3'<br />
https://review.opendev.org/c/osf/interop/+/800935 - cinderclient.exceptions.UnsupportedVersion: Invalid client version '2.0'. Major part should be '3' plus<br />
https://review.opendev.org/c/osf/interop/+/800899 - Similar cinderclient plus, heat_tempest_plugin/tests/scenario/test_octavia_lbaas.py <br />
https://review.opendev.org/c/osf/interop/+/800891- 404 not found<br />
https://review.opendev.org/c/osf/interop/+/800774 - similar dependencies as in 800899<br />
storyboard for Interop to review and cleanup - https://storyboard.openstack.org/#!/project/877<br />
https://storyboard.openstack.org/#!/story/1579162 - assign to Lucas<br />
https://storyboard.openstack.org/#!/story/1638112 - assign to Vida<br />
i think this can be closed - the capability (compute-volume-list) mentioned in the story is removed and is not mentioned in the current next.json file<br />
https://opendev.org/osf/interop/src/branch/master/guidelines/next.json<br />
https://storyboard.openstack.org/#!/story/1579136 - assign to Lucas to see if the problem is still there as part of Neutron L3 tests coverage<br />
https://storyboard.openstack.org/#!/story/1579132 - Martin to take a look if Glance test cover it already<br />
do not see GET coverage for glance. <br />
Do we have a test for getting the version of API supported?<br />
If not bring to attention of Glance at PTG<br />
Refstack test analysis - https://etherpad.opendev.org/p/refstack-test-analysis L:321-348<br />
<br />
== Meeting Friday July 16 - new time (2pm UTC) ==<br />
Attendees: Arkady, Martin, Vida, prakash<br />
Apologies: gouthamr won't be in this meeting, will follow the progress via the meeting minutes, thanks!<br />
Topics:<br />
Yoga PTG planning<br />
divide coverage for all projects under guidelines & add inetrop/refstack topic on their agenda<br />
AI: Arkady to create a list of projects (including 2 new propsoed add-ons)- done<br />
Interop/Refstack PTG time<br />
2 hours on Monday, 1 hour on Friday<br />
Make sure it does nto overlap with QA & Manila & TC<br />
Need to fill the form for PTG times<br />
AI: Arkady - Launchpad for Agenda<br />
team signup info: http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023540.html - deadline June 21<br />
form submitted<br />
Signed up for Tu 14-16 UTC & Friday 13-14 UTC (avoid Manila overlap) - Austin room (the same as Manila)<br />
article about refstack highlights - https://etherpad.opendev.org/p/refstack-highlights-wallaby<br />
please review the content as well as the grammar please :) +:)<br />
let's publish that so that we gain more visibility of RefStack work ...<br />
any ideas where? superuser? - https://superuser.openstack.org/contribute/<br />
AI: Prakash - draft of the article<br />
https://docs.google.com/presentation/d/1-9H1cTXZxW0vCSTzfBe0aMKbd7nggd8SOHQOT987nFs/edit?ts=60bfe90d#slide=id.g898dc4e183_2_0<br />
(gmann) Currently, I am not having much bandwidth for the interop, much busy in TC, Nova, QA and other things,<br />
I would like to step down from the co-chair. Though I will be available for any query related to interop/Api/testing part.<br />
(Arkady) Jenkins issue - cannot do any reviews till next week<br />
Arkady plans to resign as co-chair by PTG<br />
We will need to have 2 co-chair decided by PTG<br />
<br />
<br />
<br />
== Meeting Friday July 9 - new time (2pm UTC) ==<br />
Attendees: Arkady, Martin, Vida, <br />
Topics:<br />
Storyboard backlog - https://storyboard.openstack.org/#!/project/877<br />
Wes update - https://github.com/OpenStackweb/openstack-org/commit/d091a3cecfddf68f88e20af2ae96b082d83628ac#diff-d3cb49b40514438d69b7a641bb32c7e71e775ac15301f6ed394b2ff91b5c8b51<br />
https://opendev.org/osf/interop/src/branch/master/doc/source/process/procedure.rst<br />
Need help with adding new tests - it's quite time consuming - creating new capabilities and editing next files<br />
new identity tests - https://review.opendev.org/c/osf/interop/+/799163<br />
https://etherpad.opendev.org/p/refstack-test-analysis<br />
https://review.opendev.org/c/osf/interop/+/799333 - merged<br />
Once we create draft of 2011.7 guidelines - let share them with vendors for feedback<br />
<br />
<br />
== Meeting Friday July 2 ==<br />
Attendees: Arkady, Thierry, Prakash, Vida, Goutham<br />
Topics:<br />
Move meeting 2 hours early - agreed to move it by 2 hours during the summer, till USA Labor day.<br />
Report from Board approval of new Interop process<br />
https://review.opendev.org/c/osf/interop/+/799213<br />
Process approved<br />
No requirement for chair to be nominate by the board<br />
Left to us on how to handle human-readable guidelines - suggest we make it nice to have in process : AI Arkady create a patch for it<br />
Discussion on Kupenstack - The Cloud native openstack from last week - https://arxiv.org/pdf/2106.02956.pdf<br />
Jimmy report on new vendor submissions and Add-on results<br />
Shared File System - Exposure on the Web site<br />
Swift ? Should it not be replaced as Integrated Opestack Core and allow multiple backends with external Storage systems with Swift API alone<br />
follow with vendors and customers on flexibility of using Swift API with non-swift implementation of object storage<br />
Arkady pinged Wes on update to https://www.openstack.org/brand/interop/ <br />
https://www.openstack.org/brand/logo-request/ <-- needs an update as well<br />
Next guidelines status<br />
revuew of current Interop Wiki - https://wiki.openstack.org/wiki/Governance/InteropWG<br />
Wiki is not able to follow softlink - how do we handle it? - did not found wiki handling of symbolic links - https://en.wikipedia.org/wiki/Help:Cheatsheet<br />
Vida - see working links below , will update wiki with Arkady/Goutham +1+1 - Arkady fixed the wiki<br />
Current OpenStack Powered guideline -> https://opendev.org/osf/interop/src/branch/master/guidelines/2020.11.json<br />
Current Orchestration add-on program guideline (Heat) -> https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json<br />
Current DNS add-on program guideline (Designate) -> https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json<br />
Current Shared File System add-on program guideline (Manila) -> https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json<br />
Directory structure: no softlinks for json.next in add_on directory<br />
Vida - see ^^ links - Arkady will file a patch creating these<br />
Move Capability Levels: Component and Platform (board approved October 2014) - into archives<br />
Inputs from OpenInfra to OpenStack Interop - Refer to Ghanshyam (QA/Tempest/API team?MicroVersion addition?)<br />
What microversions are:<br />
https://docs.openstack.org/nova/latest/contributor/microversions.html <br />
https://docs.openstack.org/manila/latest/contributor/api_microversion_dev.html<br />
https://docs.openstack.org/cinder/latest/contributor/api_microversion_dev.html<br />
<br />
== Meeting Friday June 25 2021 ==<br />
Attendees: Arkady, prakash,Vida, Goutham, Martin<br />
Topics:<br />
Martin is not sure he'll be able to attend, might be late<br />
It's 6pm in my time and during the summer I'm usually travelling somewhere on Fridays afternoons - alternate mtg time/date? <br />
not sure about the alternate mtg time as it would be at least 2 hours earlier in order to make a difference .. it's ok , i download an app to my phone, so I'll try to attend just from my phone in the worst case scenario<br />
Reviews:<br />
refstack:<br />
https://review.opendev.org/c/osf/refstack/+/790941/ - important for the guideline move +1<br />
https://review.opendev.org/c/osf/refstack/+/797636/ in progress<br />
https://review.opendev.org/c/osf/refstack/+/797637/ +1<br />
https://review.opendev.org/c/osf/refstack/+/798056/ reviewed<br />
interop:<br />
https://review.opendev.org/c/osf/interop/+/791736 +1<br />
https://review.opendev.org/c/osf/interop/+/796413 - please review if it's ok like that - I'll merge that at the same time we update the production server +1<br />
Which order they should be merged?<br />
they are already chained (within project) and 796413 needs to be merged last .. at the same moment production server is updated (manual process) - OK<br />
Leave to Martin to control workflow labels for patches so order is controlled<br />
microversions - what is interop's concern here?<br />
https://www.openstack.org/brand/interop/ update - email sent and Foundation acknowledged the work to be done<br />
Next guidelines<br />
when do we wanna create new guidelines? Month? - July<br />
Martin will propose new tests soon (on top of 796413 patch) based on the analysis: https://etherpad.opendev.org/p/refstack-test-analysis +1+1+1<br />
A filesystem test was flagged in 2020.11, it should remain flagged in the next guideline (https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system.2020.11.json#L262-L270) <br />
Board presentation on June 29 9:00pm PT <br />
https://zoom.us/j/96201224963?pwd=VkliQndaVU5xZzBmdzVwaWI2UjE1UT09 <br />
Completed the updates discussed in meeting<br />
AI: Arkady to review current Interop WIKI to see what should be changes<br />
AI: document what we need to do for https://opendev.org/osf/interop/src/branch/master/tools/jsonToRst.py update.<br />
<br />
<br />
== Meeting Friday June 18 2021 ==<br />
Attendees: Arkady, Vida,<br />
Topics:<br />
Martin is not available today, below is my update:<br />
update refstack-client's README (adds mention of ansible-role-refstack-client + a few other improvements)<br />
https://review.opendev.org/c/osf/refstack-client/+/797053<br />
move procedure.txt out of 2016.08 dir as discussed in the last meeting:<br />
https://review.opendev.org/c/osf/interop/+/797086 <br />
Suggest adding a procedure.rst banner in 2016.8 dir pointing to the new file location<br />
please review first patch of the series fixing consistency:<br />
https://review.opendev.org/c/osf/interop/+/791524<br />
Martin is working on moving the guidelines to a new location (https://review.opendev.org/c/osf/interop/+/796413) https://review.opendev.org/c/osf/interop/+/796413<br />
it's harder than it looked , it's more complicated and it requires further changes on refstack's side<br />
I have an environment active where I was able to simulate the move - it will help me to find the changes we need to make in refstack - very nice<br />
Removed requirement for Co-chair from the board based on discussin with a few board folks<br />
https://review.opendev.org/c/osf/interop/+/796312<br />
https://review.opendev.org/c/osf/interop/+/784622 - need one more +2 review<br />
Need to complete review of https://docs.google.com/presentation/d/1-9H1cTXZxW0vCSTzfBe0aMKbd7nggd8SOHQOT987nFs/edit?ts=60bfe90d#slide=id.p1<br />
kupenstack white paper - https://arxiv.org/pdf/2106.02956.pdf<br />
Must send to the board by this weekend<br />
Arkady to provide Jimmy on the changes needed for https://www.openstack.org/brand/interop/ - email sent with all people cc-ed<br />
include Add-on programs and remove core projects mentioning<br />
<br />
<br />
== Meeting Friday June 11 2021 ==<br />
Attendees: Vida, Martin, Arkady, Goutham, Prakash<br />
Topics:<br />
we need to update procedure.rst file<br />
https://opendev.org/osf/interop/src/branch/master/2016.08/procedure.rst - interop/2016.08/procedure.rst<br />
https://review.opendev.org/c/osf/interop/+/795903<br />
http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022673.html<br />
AI (kopecmartin): let's make the procedure.rst from 2016.08 more generic and move it to the top level of the interop dir<br />
let's mention x/ansible-role-refstack-client in the new generic procedure file (as another way how to run tests against a guideline)<br />
let's also mention x/ansible-role-refstack-client in the refstack-client repo to be transparent<br />
Update <br />
AI: Arkady to follow with Jimmy to update to include Add-on and point to latest guidelines<br />
Review presentation to the board with updated process<br />
https://docs.google.com/presentation/d/1-9H1cTXZxW0vCSTzfBe0aMKbd7nggd8SOHQOT987nFs/edit#slide=id.p1<br />
refstack tests analysis: https://etherpad.opendev.org/p/refstack-test-analysis<br />
it shows what api non admin tests are available in tempest however are not in any interop guideline<br />
Adress the question posted on the old meetpad -> https://meetpad.opendev.org/Interop-WG-weekly-meeting<br />
<br />
== Meeting Friday May 21 2021 ==<br />
Attendees: Arkady, Vida, Goutham, Martin<br />
Topics:<br />
Request Board to allow WG not to have co-chair who is on the board. Prefer to have a board member as co-chair.<br />
keep that portion as the current process<br />
Do we know the place where that process is written about one of the co-chair has to be Board ?<br />
Reviews:<br />
https://review.opendev.org/c/osf/interop/+/791736 - fixing consistency issues:<br />
heat's api tests are defined in a different way, their ids are not defined by decorator.idempotent_id<br />
https://opendev.org/openstack/heat-tempest-plugin/src/branch/master/heat_tempest_plugin/tests/api/gabbits/stacks.yaml<br />
consistency.sh script is failing due to that - it can't identify the ids<br />
let's omit orchestration consistency check so that we can merge - https://review.opendev.org/c/osf/interop/+/786116<br />
https://review.opendev.org/c/osf/interop/+/787646<br />
https://review.opendev.org/c/osf/interop/+/784622<br />
https://review.opendev.org/c/osf/interop/+/789399<br />
Cancel June 4 meeting.<br />
Cancel May 28 meeting.<br />
Added Thierry, Martin and Vida as core members of Interop<br />
Arkady to check with Jimmy on prototype of reporting add-on results<br />
Propose that we do not need to create human readable format of guidelines. Json format is good enough. <br />
we can always do it later for any members who wants it.<br />
Not the process requirement - good intern task<br />
https://opendev.org/osf/interop/src/branch/master/tools/jsonToRst.py - convert to Schema2 and add support for add-on guidelines<br />
<br />
== Meeting Friday May 14 2021 ==<br />
Attendees: Arkady, Martin, Goutham, Jimmy<br />
Topics:<br />
Arkady will be leaving Dell. And will be replaced on the Board.<br />
Can somebody run the meeting for June ?<br />
Arkady plan is to stay on till we approve everthing for this cycle and approve new process with the board Will step down as a chair after it.<br />
Can stay as core after it. Can ask Dell marketplace owner to participate.<br />
Mark wants to step down as core contributor. - removed as core contributor.<br />
Reviews:<br />
https://review.opendev.org/c/opendev/irc-meetings/+/790923 - mreged<br />
https://review.opendev.org/c/osf/refstack/+/790925<br />
the readme pointed to this wiki:<br />
https://wiki.openstack.org/wiki/RefStack - gouthamr will update this wiki page and add redirects/notes to the interop WG wiki<br />
however we use this one:<br />
https://wiki.openstack.org/wiki/Governance/InteropWG<br />
should we remove the old wiki?<br />
https://review.opendev.org/c/osf/refstack/+/790940 - merged<br />
refstack server updated in the production by: https://review.opendev.org/c/opendev/system-config/+/791043<br />
https://review.opendev.org/c/osf/interop/+/787646<br />
ove milestone column from the process doc<br />
https://review.opendev.org/c/osf/interop/+/784622<br />
https://review.opendev.org/c/osf/interop/+/789399<br />
https://review.opendev.org/c/osf/interop/+/786116<br />
(Martin) I'm still reviewing, there are issues with tools/consistency.sh<br />
Switch meetpad: https://meetpad.opendev.org/Interop-WG-weekly-meeting to https://meetpad.opendev.org/interop (gouthamr) - good idea (need to update wiki) - Arkady to do 5/21/2021<br />
Add-on program <br />
marketpalce is capable of displaying it<br />
Orchestration & DNS is ready to be displayed<br />
Refstack can ahndle submissions now<br />
Jimmy sent email to to all marketplace entry owners to subvmit add-on results for inclusion and udpate pwoered on results also<br />
How to submit results for all add-ons and Pwoered on Logo?<br />
These are submitted to us through interop@openstack.org<br />
https://meetpad.opendev.org/Interop-WG-weekly-meeting<br />
Comment from Greg Waines <greg.waines@windriver.com> re: asking to move Swift to an add-on i/o being part of core Powered Platform<br />
<br />
== Meeting Friday May 7 2021 ==<br />
Attendees: Arkady, Vida, Martin, Goutham<br />
Topics:<br />
* https://review.opendev.org/c/osf/interop/+/787646<br />
- https://review.opendev.org/c/osf/interop/+/789940 <br />
* https://review.opendev.org/c/osf/interop/+/784622<br />
- https://governance.openstack.org/tc/reference/tags/starter-kit_compute.html <br />
- https://governance.openstack.org/tc/reference/tags/starter-kit_kubernetes-in-virt.html <br />
* https://review.opendev.org/c/osf/interop/+/789399<br />
* https://review.opendev.org/c/osf/interop/+/786116<br />
* (Martin) I have a patch locally for refstack, need to test a little, will push for a review soon<br />
* Cinder response - http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022308.html<br />
Have a chat with Brian on RBAC and any user test changes for it.<br />
Maybe consider tenant admin user for the future<br />
Multi usre interop testing? Current testing is single user API only<br />
We've flagged a test case (details below) for using multiple users<br />
Test case: id-86128d46-e170-4644-866a-cc487f699e1d - "tempest.api.identity.v3.test_projects.IdentityV3ProjectsTest.test_list_projects_returns_only_authorized_projects"<br />
* Microservices API<br />
AI: Arkady check with Mark V if he still wants to be stay as core<br />
* Creating 2021.x guideline<br />
* Should be aling LOGO granting to Starter-kit model<br />
* Should we have the discussion with Board on this alignment<br />
* AI Arkady to check where we use old definition of Core projects and replace it with OpenStack Powered Logo covered projects. - done<br />
* AI: Also see if we can replace project core APIs with "required" funcitionality<br />
<br />
== Meeting Friday April 30 2021 ==<br />
Attendees: Prakash,Arkady, Vida, Martin<br />
Topics:<br />
* Arkady update invite time and WIki to 4:00 on=m UTC - done<br />
* also here: http://eavesdrop.openstack.org/#Interop_Working_Group_Meeting<br />
* https://review.opendev.org/c/opendev/irc-meetings/+/790923<br />
New meeting time and https://wiki.openstack.org/wiki/Governance/InteropWG updated<br />
* Review of feedback from project interlocks<br />
* Review of process change:<br />
https://review.opendev.org/c/osf/interop/+/787646 - Prakash Reviwe completed<br />
add a link to previous process in commit message<br />
https://review.opendev.org/c/osf/interop/+/784622 - If this is previous process I am not sure if I need to comment<br />
Feedback from projects from PTG:<br />
designate - no changes<br />
neutron - summarized in the mail thread - http://lists.openstack.org/pipermail/openstack-discuss/2021-April/022052.html<br />
need to propose new tests to interop (under adivosory for now)<br />
we will need to slightly modify refstack-client (to install neutron-tempest-plugin) and run the nest tests in zuul CI (using x/ansible-role-refstack-client)<br />
Cinder - Brian will get back to us in 2 weeks with any changes for Cinder Interop coverage. - done<br />
Glance. Major changes over last 2 cycle. No microservices.<br />
AI: Martin - check tempest if there are any new tests which are not tracked in interop<br />
Heat - no changes. But Ric Lin will notify Martin of any tempest changes going forward.<br />
Nova - V2.1 API are still supported and no plan to deprecate them.<br />
https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-ussuri-and-victoria<br />
Proposal: To report tange of microservice API range for projects that support it<br />
Refstack reporting of it<br />
vendor submission include it<br />
Vendor Markeplace detailed per project API version support for microservice range<br />
Customer can run a specific microservice version and submit results thru refstack<br />
AI: Martin, try to test new tests in the Zuul using x/ansible-role-refstack-client<br />
if it works, we can include the tests as advisory in the next guideline - 2021.5/6/7?<br />
Octavia is the top candidate for new add-on interop project - AI: Arkady to schedulle interlock with us<br />
AI check Barbicuan can help in security aspect for Interior - Prakash<br />
<br />
PTG April 18-23 - https://etherpad.opendev.org/p/april2021-ptg-interop-refstack<br />
<br />
<br />
== Meeting Friday April 16 2021 ==<br />
Attendees: Arkady, Martin, Ghanshyam, Goutham<br />
Topics:<br />
superuser article status - draft at https://etherpad.opendev.org/p/refstack-highlights-wallaby <br />
PTG schedule:<br />
http://ptg.openstack.org/ptg.html<br />
Cross team PTG meetings:<br />
cinder - Tuesday 14:30 UTC: interoperability working group - Arkady https://etherpad.opendev.org/p/apr2021-ptg-cinder<br />
neutron - Friday 13:30 - 14:00 Cross project session with Interop Group (to confirm with Arkady Kanevsky) - Martin https://etherpad.opendev.org/p/neutron-xena-ptg<br />
glance - Tuesday, April 20th 16:00-16:20 UTC - Arkady, Martin https://etherpad.opendev.org/p/xena-glance-ptg<br />
designate - Thursday April 22nd, 1 UTC (14:30) - Martin https://etherpad.opendev.org/p/xena-ptg-designate<br />
Nova - Wed 14:00 - 15:00 UTC (do not need to take full 1 hour) - Arkady, Martin, gmann (https://etherpad.opendev.org/p/nova-xena-ptg) (add microservices discussion & discovery of microservices)<br />
Manila - Goutham - Apr 21st - Wednesday - 1535 UTC-1555 UTC - Arkady (https://etherpad.opendev.org/p/xena-ptg-manila)<br />
Heat - April 21st - Wednesday - 14:45-15:00 UTC - Arkady (https://etherpad.opendev.org/p/xena-ptg-heat)<br />
https://review.opendev.org/c/osf/interop/+/783976<br />
https://review.opendev.org/c/osf/interop/+/786116<br />
https://review.opendev.org/c/osf/interop/+/784622<br />
https://review.opendev.org/c/osf/interop/+/766840<br />
Interop handling of Microversions of API<br />
<br />
== Meeting Friday April 9 2021 ==<br />
Attendees: Arkady, Vida, Martin, Goutham<br />
Topics:<br />
https://wiki.openstack.org/wiki/Governance/InteropWG - discuss updates<br />
https://review.opendev.org/c/osf/interop/+/783976<br />
https://review.opendev.org/c/osf/interop/+/784622 - major process update<br />
https://github.com/openstack/interop/blob/master/doc/source/process/ProcessCycles.rst - outdated link<br />
https://opendev.org/osf/interop/src/branch/master/doc/source/process/ProcessCycles.rst - the new one / the new location of interop repo<br />
Spider process materials - everybody to review process page and see if we still need it<br />
old process no longer in use<br />
delete Process Cycles section<br />
"Alternative Implementations"<br />
see CoreDefinition.rst doc<br />
Update to make clear that it is dirver choices not project alternative defintion<br />
We are aware of two cases where alternative implementations are being done (beyond vendor driver)<br />
object store alternative that supports Swicth API and properly integrate with openstack control plane<br />
Alternative Manila implementations<br />
Both use cases are in productions on several customer sites<br />
For new board approval propose relaxing upstream code requirement<br />
How do we enforce compatiblity of API<br />
Ensuring interop testing for each release for alternative implementations to avoid bit-rot<br />
Shall we demand that this alternaive code base implementation meet 4 Os?<br />
https://github.com/openstack-archive/interop/blob/master/doc/source/process/Lexicon.rst<br />
Lack of Add-on info<br />
Add-on defintion to add<br />
Fix wo links on the github page above fail<br />
Capabilites and guidleines<br />
rid of list all guidelines.<br />
Only list current one<br />
Pointer to all previous guideliens and what releases they apply to ( table to link from Wiki)<br />
How do we create new guidelines?<br />
Old process, with per project review then create new guudelines<br />
Or directly create new guideline proposal (next.json + add-ons patch) then discuss +1<br />
Coverage for all Projects under Interop<br />
List of PTLs: https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml (Similar list: https://governance.openstack.org/election/results/wallaby/ptl.html) <br />
Cinder - Arkady Kanevsky (PTL Brian Rosmaita rosmaita.fossdev@gmail.com) - done<br />
Nova - Ghanshyam Mann<br />
Glance - ??? (PTL Abhishek Kekane akekane@redhat.com)<br />
Keystone - ???<br />
Neutron - ???<br />
Swift - Arkady (John Dickinson me@not.mn, or Christian Schwede cschwede@redhat.com) <br />
Heat - ??? (Rico Lin ricolin@ricolky.com)<br />
Manila - Goutham Pacha Ravi gouthampravi@gmail.com<br />
Designate - ???<br />
AI: Arkady send email to each PTL and ask to add on PTG agenda 15-30 min to discuss test coverage chanegs and potential Interop requirements changes - done<br />
https://review.opendev.org/c/osf/interop/+/766840 - updated .next files so they match current reality. Not chnaging the process on how we choose testes for each project.<br />
restructure code - next meeting<br />
move old/all gudelines into previous section<br />
keep .next & current on top level (or soft link to old guidelines directory)<br />
Maybe create file current_guideline with the soft link to directory where we keep all guidleines.<br />
Tools directory - what are we using it for?<br />
How do we generate matching .RST file for a guideline<br />
test_shrink_share should be optional<br />
https://review.opendev.org/c/osf/interop/+/783955 - lets merge it ASAP - done<br />
https://docs.openstack.org/manila/latest/admin/share_back_ends_feature_support_mapping.html (What backend drivers support this feature)<br />
are we gonna remove the test in the next guideline?<br />
Let's review how other driver support it.<br />
How do we specify optional functionality in test coverage? still use Flag designated?<br />
<br />
== Meeting Friday April 2 2021 - Good Friday - NO MEETING ==<br />
<br />
== Meeting Friday March 26 2021 ==<br />
Attendees: Arkady, Vida, Martin, Prakash<br />
Topics:<br />
Register for PTG https://april2021-ptg.eventbrite.com<br />
there's an effort to run all target programs' tests in the zuul using ansible-role-refstack-client<br />
https://review.opendev.org/c/x/ansible-role-refstack-client/+/776202 still WORK IN PROGRESS<br />
superuser article (draft): https://etherpad.opendev.org/p/refstack-highlights-wallaby <br />
Let's update refstack's documentation:<br />
refstack doc on how to run it locally:<br />
how to run it with docker: https://opendev.org/osf/refstack/src/branch/master/doc/source/run_in_docker.rst +<br />
that's most likely outdated +<br />
how to run it directly: https://opendev.org/osf/refstack/src/branch/master/doc/source/refstack.rst -<br />
this is outdated and the steps don't work anymore<br />
I'd say let's drop this and let's document docker usage (containerized way) - which is also how it's used in the production<br />
here is a dockerfile which we use in production:<br />
https://opendev.org/opendev/system-config/src/branch/master/docker/refstack +<br />
the rest of the automation used in production:<br />
https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/refstack +<br />
not all of it will be required to run things locally<br />
this prepares the host (the server the container is running on)<br />
https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/refstack/tasks/main.yaml +<br />
we also could publish the documentation so that we (users) don't have to browse it in the repo:<br />
https://opendev.org/osf/refstack/src/branch/master/doc/source<br />
if we add a zuul doc job, the doc should be published automatically (?)<br />
python-tempestconf example: https://opendev.org/osf/python-tempestconf/src/branch/master/.zuul.yaml#L6 +<br />
and it's published here: https://docs.openstack.org/python-tempestconf/latest/ +<br />
The goal is basically - document (potentially provide a script(s)/ansible playbook):<br />
how to create a docker image - that will contain the latest (or any wanted version) of refstack code<br />
how to configure apache conf, link refstack configs, run container<br />
it's all here https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/refstack/tasks/main.yaml<br />
in theory if we run ^^ on localhost, it should set everything - but may break something (I didn't tested it) - in production it's executed on a fresh server<br />
<br />
== Meeting Friday March 19 2021 ==<br />
Attendees: Arkady, Prakash, Vida, Martin<br />
Topics:<br />
* Wallaby Cycle Highlights<br />
Interop and Refstack are not published in release highlights<br />
Kendall suggested that we can write superuser post on it.<br />
Ai: pounter to latest superuser magazine - https://superuser.openstack.org/<br />
Get user perspective on Interop. Cloud provider, hosting provider, Telco service provider<br />
https://etherpad.opendev.org/p/april2021-ptg-interop-refstack - PTG etherpad<br />
Current process - https://review.opendev.org/plugins/gitiles/osf/interop/+/refs/heads/master/doc/source/process/2017A.rst<br />
Patch for proposed guidelines for PTL to review<br />
We attend each of project meeting under guidelines and ask for review of the tests coverage (slack or IRC)<br />
List of PTLs for each project (AI: for Arkady)<br />
PTG to PTG roadmap<br />
there's an effort to run all target programs' tests in the zuul using ansible-role-refstack-client<br />
https://review.opendev.org/c/x/ansible-role-refstack-client/+/776202 still WORK IN PROGRESS<br />
<br />
== Meeting Friday March 12 2021 == <br />
Attendees: Arkady, Martin, Prakash, Vida, Goutham<br />
Topics:<br />
PTG April 19 - 23 - When should Refstack and Interop should meet? dates, time, how many meetings?<br />
PTG Registration: https://april2021-ptg.eventbrite.com <https://april2021-ptg.eventbrite.com/> <br />
refstack future, interop next<br />
Prakash reserved 2 slots: Monday (2 hours) 13-15 UTC first time slot in Austin room; and Friday (13-14) and Wednesday (13-14 UTC). <br />
Reserved time slots for VPTG here: https://ethercalc.net/oz7q0gds9zfi<br />
AI: Arkady to create new etherpad for PTG agenda (update this etherap with the pointer to it)<br />
Guidelines approval new process:<br />
new guidelines to be approved by WG and Foundation employees who are handling marketplace<br />
People to make sure they vote<br />
Let board know of new guidelines. Does not require board approval<br />
Bring to board only new project for guidelines and any major process changes<br />
the server got updated \o/ https://refstack.openstack.org/#/++<br />
Great job Martin!!<br />
AI: Arkady will ping Dell guide to submit community results to test new version of refstack<br />
My Catalog at refstack.openstack.org<br />
what is the precise use case? (just to make it clear)<br />
AI: Arkady (check with Tierry) do we expect that people should add something in "my catalog"<br />
do we expect users adding their vendors and products there?<br />
if so is then the maketplace page for the specific vendor updated automatically (f.e. granting powered logo) based<br />
on the results uploaded and linked to the vendor (and the product)?<br />
in other words:<br />
are users expected to register their company and the products (f.e. a product from openstack train, another product openstack ussuri) they will be submitting results for?<br />
will be the marketplace of the registerd company (vendor) and the related product updated automatically?<br />
or is the My Catalog page just for better organizing results of the specific user (in case the user uploads many results for various products) without any connections to the marketplace?<br />
<br />
<br />
<br />
== Meeting Friday March 5 2021 == <br />
Attendees: Arkady, Martin, Prakash<br />
Topics:<br />
* Test instance - 104.239.166.15 use the ip instead<br />
* final patch: https://review.opendev.org/c/opendev/system-config/+/776292<br />
* Branding, Logo, Trademark innagural meeting feedback<br />
https://etherpad.opendev.org/p/branding<br />
Goutham's not able to attend due to Feature Freeze this week! Sorry :(<br />
Vida regretfully missing meeting due to conflict <br />
* Trademark - keep away as for as possibe<br />
* Branding -OpenStack Offering - Logo Program (Community) for OpenStack - Incremental <br />
* Branding - OpenStack Offering - Logo Program (Commercial) for OpenStack - Legal contract needed<br />
Interop guidelines current 2020.11 are covering T,U,V,W - Refstack is a submission vehicle - Tempest results <br />
No need for approval for Community Logo Program any more - Only if change of process guidelines creation we go to board approval<br />
Core (compute, Object Storage, compute + Object-strorage) + Add-ons (3 - Orchestartion, DNS, Shared File System)<br />
<br />
Openinfra - TBD (Awaits Machine and program definition with goals)<br />
<br />
== Meeting Friday Feb 26 2021 - skipping today ==<br />
Attendees:<br />
Topics:<br />
Martin - I can't attend today, sorry, the server is still work in progress<br />
<br />
== meeting Friday Feb 19 2021 ==<br />
Attendees: Arkady, Martin,Prakash, Vida, gmann<br />
Topics:<br />
http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020294.html<br />
Jimmy accepted and will do it. Delayed due to weather in Texas<br />
Started branding dicussion<br />
https://etherpad.opendev.org/p/branding<br />
http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020542.html<br />
testing instance is up and used for testing env.<br />
https://refstack01.openstack.org/#/<br />
https://etherpad.opendev.org/p/refstack-docker<br />
run tempest plugins' tests by refstack-client:<br />
https://review.opendev.org/c/x/ansible-role-refstack-client/+/775699<br />
https://review.opendev.org/c/x/ansible-role-refstack-client/+/776202<br />
<br />
== Meeting Friday Feb 12 2021 ==<br />
Attendees: Arkady, Vida, Martin, Goutham<br />
Topics:<br />
http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020294.html<br />
proposal acquested. Need to follow with Jimmy on updating web site (done)<br />
AI: Arkady to remind Jimmy about our weekly meetings so he can attend, as Chris Hoge was before (done)<br />
tempest test credentials for running tests (gouthamr)<br />
Options:<br />
1) document that you need admin creds for manila-tempest-plugin in your test accounts file, or have dynamic creds turned on<br />
2) refstack/tempest.conf does the bootstrapping? creation of share types<br />
Need to document manila tempest.conf for refstack<br />
we will document this behavior <br />
Tempest will skip the admin tests if no admin creds available. <br />
https://github.com/openstack/tempest/blob/34743b278c9ba9e1a11447f715cfe719adee7be7/tempest/test.py#L302 <br />
Agreed: <br />
We'll document the instructions to setup manila tests and execute them for refstack - <br />
no changes are expected to the published guideline. We'll attempt to remove the "admin" requirement from the manila tests in the next guideline<br />
(gmann) why we need admin creds. is all tests hard coded to have admin creds or some common stuff need admin?<br />
We'll figure out improving refstack to handle bootstrapping automatically<br />
Deploy new refstack.openstack.org<br />
ianw is actively working it<br />
UI is up: https://refstack01.openstack.org/#/<br />
However, there are troubles with connecting the database<br />
Great job, Martin!+++1<br />
the great work behind deploying the new instance is all ianw's<br />
Will need to add drop down menu entry for Manila<br />
seems like that's done, at least I can see it in the dropdown menu https://refstack01.openstack.org/#/<br />
probably automatically pulled from interop git repo, which is great<br />
nope, it's not automatically pulled, the support for these options has been added years ago<br />
https://review.opendev.org/c/osf/refstack/+/547246<br />
<br />
== Meeting Friday Feb 5 2021 ==<br />
Attendees: Arkady, Vida, Martin, Goutham, Prakash<br />
Topics:<br />
deploying a new refstack.openstack.org instance<br />
Ian Wienand will create the instance, a discussion about tech parameters of the instance:<br />
https://etherpad.opendev.org/p/refstack-docker <br />
https://review.opendev.org/c/opendev/system-config/+/705258<br />
When instance is up Arkady will ask Dell folks ot try it to submit results, not for interop cert.<br />
Documentation on how to deploy a refstack server<br />
https://opendev.org/osf/refstack/src/branch/master/doc/source/refstack.rst <br />
^^ link to 'one-click setup' page is missing <br />
https://review.opendev.org/c/osf/refstack/+/773626 - just WIP atm<br />
Goutham will follow on refstack documentation update once the refstack is running and UI pages functional<br />
Arkady will look at interop pages updates <br />
https://review.opendev.org/admin/repos/osf/interop<br />
https://review.opendev.org/admin/groups/ad95fb605fa544dab35712194df7faaa10ec7a22<br />
https://review.opendev.org/admin/repos/q/filter:refstack<br />
Is Refstack runs under root? Is this really needed?<br />
Patchset referencing root priv requirement: https://review.opendev.org/c/opendev/system-config/+/705258 <br />
see playbooks/roles/refstack/tasks/main.yaml<br />
It's a standard in other upstream web server projects such as codesearch, etherpad or gerrit, see:<br />
https://opendev.org/opendev/system-config/src/commit/56277bf70a3e9c66e274e4b2558dfd0b70d8e944/playbooks/roles/codesearch/tasks/main.yaml#L30-L53<br />
https://opendev.org/opendev/system-config/src/commit/56277bf70a3e9c66e274e4b2558dfd0b70d8e944/playbooks/roles/etherpad/tasks/main.yaml#L60-L86<br />
https://opendev.org/opendev/system-config/src/commit/56277bf70a3e9c66e274e4b2558dfd0b70d8e944/playbooks/roles/gerrit/tasks/main.yaml#L65-L88<br />
<br />
== Meeting Friday Jan 29nd 2021 ==<br />
Attendees: Arkady, Vida, Martin, Prakash<br />
Topics:<br />
deploying a new refstack.openstack.org instance<br />
https://review.opendev.org/c/opendev/system-config/+/705258 <br />
this is finally ready, the next step is deploying it, then testing and if it's ok, then replacing the old instance by the new one<br />
http://lists.opendev.org/pipermail/service-discuss/2021-January/000176.html<br />
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Weekly_Project_Infrastructure_team_meeting<br />
https://opendev.org/osf/refstack/src/branch/master/doc/source/refstack.rst<br />
https://review.opendev.org/c/osf/refstack/+/772934<br />
how to display multiple powered programs on ( how to handle add-ons)<br />
the marketplace page<br />
in the refstack , f,e, https://refstack.openstack.org/#/results/5cce986e-7ab3-4dd2-aa3b-f3135f1b1de8<br />
Can we support single vendor submission for compute, storage and add-ons? How does vendors specify which programs are covered?<br />
<br />
== Meeting Friday Jan 22nd 2021 ==<br />
Attendees:<br />
Prakash Ramchandran, Vida, Martin, Goutham, Arkady <br />
- https://review.opendev.org/c/opendev/system-config/+/705258 - to continue<br />
- https://review.opendev.org/c/osf/refstack/+/705097 - can drop this<br />
- https://review.opendev.org/c/osf/refstack/+/734535<br />
- https://review.opendev.org/c/osf/refstack/+/732943<br />
- Victoria guidelines marketing (Claire email) - done - https://docs.google.com/presentation/d/1QXncLzF1-AKs9P7P9TOI3qFHg5zC0dNbUcmTNex0AWY<br />
<br />
AI: Arkady to update interop documentation and follow with Jimmy on the doc changes.<br />
AI: How to display multiple powered programs passed? Verify that submission is in place.<br />
<br />
Below is a redhat page where only train release is listed<br />
https://www.openstack.org/marketplace/distros/distribution/red-hat/red-hat-openstack-platform<br />
Is the point to show only one release here? Wouldn't be better to give companies a possiblity to list there multiple releases?<br />
Currently we only list the latest version of certified product. What if user wants to know of interoperaibility of previous versions. Do we show history? How far back?<br />
Do we want to list multiple version? Maybe we can list latest on the top level but provide way to go back. AI: Arkady to bring to the board for teh guidelines<br />
<br />
== meeting Friday Jan 15th == <br />
Attendees:<br />
Prakash, Arkady, Martin, Goutham, Vida<br />
- Marketplace discussions - https://www.openstack.org/marketplace/<br />
- What will be difference between Integrated OpneStack and Open Infrastructure -Products?<br />
- What are the roles of <br />
Board<br />
Projects in OpenInfra<br />
Vendors<br />
Tech team for enabling conformance & compliance<br />
Any other thougts or ideas<br />
<br />
- Post electioin scenario and InterOp for OIF - <br />
Based on results Prakash indicates he wants to handover to Arkady effective Feb 1 with clourse on Victoria TOI<br />
<br />
https://review.opendev.org/c/opendev/system-config/+/705258<br />
- How is this patch related to https://review.opendev.org/c/osf/refstack/+/705097 (noob question?) - I suppose it's for local/dev/test of refstack with containers? <br />
- 705258 was cherry-picked from 705097, see line 28 https://review.opendev.org/c/opendev/system-config/+/705258/20/docker/refstack/Dockerfile#28<br />
- however, based on the comment on lines 25-26 it was originally there to gain py3 support (both reviews are a year old) - i removed the cherry-pick in patchset 21 and it doesn't make any difference<br />
- so probably 705097 is not needed anymore<br />
- Lets chat about this, Martin - i popped off refstack meetings between us, my bad - i'll revive those<br />
<br />
Website Updates: <br />
We need to update this for 3 add-ons DNS, Orchestraion, Shared File System<br />
https://www.openstack.org/brand/interop/ - Who owns this and gets updated? Thiery? - You can submit a PR, and ping Jimmy McArthur (https://github.com/jimmytipit)<br />
The content is here: https://github.com/OpenStackweb/openstack-org/<br />
Interop page is here: https://github.com/OpenStackweb/openstack-org/blob/master/themes/openstack/templates/Layout/InteropPage.ss <br />
<br />
What is the ask to OSF webteam<br />
Under unified "OpenStack Powered" logo we need add three add-ons: <br />
DNS, Orchestraion, Shared File System<br />
Refer: https://review.opendev.org/c/osf/interop/+/762719<br />
The Boord had approved the guidelines on December 8, 2020 as proposed : https://wiki.openstack.org/wiki/Governance/Foundation/8Dec2020BoardMeeting<br />
Need following updates to link<br />
https://www.openstack.org/brand/interop/ (referred under https://www.openstack.org/brand/openstack-powered/)<br />
<br />
The row with 4 columns showing following content <br />
=======================================================================================================================<br />
OpenStack Powered DNS<br />
Must include all DNS-specific code and pass all DNS -specific capabilities tests <br />
Qualifying products may use the OpenStack Powered logo and use the phrase "OpenStack Powered DNS" in their product name<br />
DNS add-on for OpenStack Powered cloud or distribution (Deignate)<br />
<br />
OpenStack Powered Orchestrator<br />
Must include all Orchestrator-specific code and pass all DNS -specific capabilities tests <br />
Qualifying products may use the OpenStack Powered logo and use the phrase "OpenStack Powered Orchestrator" in their product name<br />
Orchestrator add-on for OpenStack Powered cloud or distribution (Heat)<br />
<br />
OpenStack Powered Shared File System<br />
Must include all DNS-specific code and pass all Shared File System -specific capabilities tests <br />
Qualifying products may use the OpenStack Powered logo and use the phrase "OpenStack Powered Shared File System" in their product name<br />
Shared Filr System add-on for OpenStack Powered cloud or distribution (Manila)<br />
=========================================================================================================================<br />
<br />
Next meeting Friday Jan 8th / return from happy holidyas<br />
Attendees: Prakash , Martin, Vida, Arkady<br />
Topics- Diversity aspects - updates -Martin<br />
stestr (a test runner of tempest) started this effort by deprecating the non-inclusive arguments and replacing them by new ones<br />
since stestr 3.1.0 both arguments are accepted to make the transition period smoother<br />
http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019639.html<br />
--black-regex is replaced by --exclude-regex<br />
--whitelist-file is replaced by --include-list<br />
--blacklist-file is replaced by --exclude-list<br />
see related changes:<br />
https://review.opendev.org/q/topic:inclusive_jargon+(status:open+OR+status:merged)<br />
https://review.opendev.org/c/osf/refstack/+/767667 - need to review to update documentation +add prakash as reviewer before merge - reveiwed -1 for whitelist pending / Martin to take care<br />
it's ready to be merged, however the gates are broken atm<br />
https://review.opendev.org/c/openstack/project-config/+/765787 - will be merged when stite will be taken down for update (X to OSF move).</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=180497Governance/InteropWG2022-01-28T21:07:07Z<p>Arkady: </p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" that is supported by all implementations as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/Lexicon.html Terms Definition]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/CoreDefinition.html 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://opendev.org/openinfra/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/DesignatedSections.html10 Designed Sections Principles] (board approved December 2014)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/GovernanceProcess.html Interop Working Group Governance:]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/2021A.html Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/next.json draft of the next OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://docs.opendev.org/openinfra/interop/latest/guidelines/index.html OpenStack Powered and Add-on Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines Source Directory of all previous OpenStack Powered Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/ Source Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since September 23 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Thursday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Thursday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
[https://wiki.openstack.org/wiki/Governance/InteropWG/Minutes2020 Minutes of Interop WG 2020 meetings] <br />
<br />
[https://wiki.openstack.org/wiki/Governance/InteropWG/Minutes2021 Minutes of Interop WG 2021 meetings] <br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/102303/martin-kopec Martin Kopec] (chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=180496Governance/InteropWG2022-01-28T21:06:41Z<p>Arkady: added 2021 notes wiki</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" that is supported by all implementations as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/Lexicon.html Terms Definition]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/CoreDefinition.html 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://opendev.org/openinfra/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/DesignatedSections.html10 Designed Sections Principles] (board approved December 2014)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/GovernanceProcess.html Interop Working Group Governance:]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/2021A.html Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/next.json draft of the next OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://docs.opendev.org/openinfra/interop/latest/guidelines/index.html OpenStack Powered and Add-on Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines Source Directory of all previous OpenStack Powered Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/ Source Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since September 23 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Thursday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Thursday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
[https://wiki.openstack.org/wiki/Governance/InteropWG/Minutes2020 Minutes of Interop WG 2020 meetings] <br />
[https://wiki.openstack.org/wiki/Governance/InteropWG/Minutes2021 Minutes of Interop WG 2021 meetings] <br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/102303/martin-kopec Martin Kopec] (chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG/Minutes2020&diff=180495Governance/InteropWG/Minutes20202022-01-28T21:03:41Z<p>Arkady: created heading per meeting</p>
<hr />
<div>This page contains Logs of 2020 Interop WG meetings.<br />
<br />
== Last 2020 meeting ==<br />
OIF - Interop, Branding to be taken after new commitee is formed<br />
Manila - As on Dec 18 meeting no change<br />
Ironic - On Hold till Julia PTL is ready, after the OIF decision<br />
Next week call -Prakash to send email<br />
<br />
== Friday Dec 18th == <br />
Attendees: Prakash, Arkady, Vida, Martin, Goutham<br />
Topics:<br />
- last meeting AIs, updates<br />
- refstack website needs maintenance<br />
- Look at Interop web pages to fix them (Notes to be added)<br />
- http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019185.html<br />
- .next files need to be updated - gmann will do this after the draft guidelines are approved by the OSF Board<br />
- Updating the guidelines as per Dec 8th Board meeting - https://review.opendev.org/c/osf/interop/+/766778<br />
- Website needs updates, to expose add-ons<br />
- the new guideline is not updated on refstack (server) side<br />
- https://refstack.openstack.org/api/v1/guidelines/<br />
- https://refstack.openstack.org/#/results/f75c4c91-8bdd-471f-823e-41fa7c7538eb <br />
- (when you open a result page you cannot see the new guideline in the Guideline Versions drop-down menu)<br />
- wrong issues links in opendev.org - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019416.html<br />
- https://opendev.org/osf/refstack-client - Issues link redirects to https://storyboard.openstack.org/#!/project/openstack/refstack-client<br />
- notice the namespace , it's 'openstack' and it should be 'osf'<br />
We also should review and update https://www.openstack.org/brand/interop/ documentation<br />
also https://refstack.openstack.org/#/about#about<br />
alsohttps://refstack.openstack.org/#/guidelines still does not show 2020.11 guidelines<br />
- bug tracking revival/options:<br />
- https://launchpad.net/refstack<br />
- https://launchpad.net/~refstack-bugs/+members#active <br />
- Chris Hoge can still be contacted - Danny Carreno <danny@openstack.org><br />
- AI: Goutham contact the admin (Catherine Diep) of this group (and related groups)<br />
- https://storyboard.openstack.org/#!/project/700 <br />
- Should Heat engine can sub Kubernetes as revamping of OpenStack as a whole to be based on KCP? - bring it board for discussion but Technical committee should take a dig at this<br />
- Should tempest add go libs (ginkos & go*)<br />
- Marketing message on Interop contribution to compile the 2020 Open Infrastructure Foundation annual report. (Deadline Jan 13,2021)<br />
https://etherpad.opendev.org/p/2020-Wallaby-interop-brainstorming (Lin 23 onwards to end)<br />
<br />
== Friday Dec 11th == <br />
Attendees: Prakash Ramchandran, Martin Kopec, Vida Haririan, Ghanshyam Mann, Goutham Pacha Ravi<br />
- Review Board meeting inputs<br />
- Discussion to extend the interop program across all OIF projects<br />
- TBI (Trademark and Branding Initiative) proposed/to-be-formed within the foundation board<br />
- TBI will be functional only after the new board is formed - elections will begin in 2021<br />
- 2021 Election Info: <br />
https://www.openstack.org/election/2021-individual-director-election/<br />
https://www.openstack.org/election/2021-individual-director-election/CandidateList<br />
- Action Items from the last meeting<br />
- Refstack Maintenance<br />
- Current Refstack Maintainers: https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members<br />
- Need to get Martin Kopec added there: <br />
- http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019263.html<br />
- Reform the core team for:<br />
- openstack/python-tempestconf<br />
- openstack/refstack<br />
- openstack/refstack-client<br />
- x/ansible-role-refstack-client (moving to osf/ via https://review.opendev.org/765787) - needs your +1s, please<br />
- Proposal:<br />
- "refstack-core" group <br />
- Update the groups with new members and erplace any other refstack corewith this new group.<br />
- include "interop-core" group in the refstack-core group so we can manage both of these individually <br />
https://review.opendev.org/admin/groups/ad95fb605fa544dab35712194df7faaa10ec7a22,members<br />
- includes chair/co-chair no change. in existing one.<br />
- Action Items for this week:<br />
- gmann will send email to revive the "refstack-core" group, gain control and seed it with interested members (the email will call for any interested contributors to reach out) <br />
- gmann<br />
- martin (mkopec@redhat.com)<br />
- Goutham<br />
- vhari (vhariria@redhat.com)<br />
- interop-core<br />
<br />
- How do we cater to OIF & or OSF Kubernetes Distros for comformance testing or leave that to upstream kubernetes & arrange discussions with CNCF? -next call<br />
- Prow -Build and test k8s projects - Sonobouy<br />
- KoO using for Cloud Provider OpenStack with Prow -<br />
- KoO using for Cloud Provider Openstack + Manila using Zuul -<br />
- https://github.com/kubernetes/cloud-provider-openstack <-- this is where OpenStack integrations live, and are being tested<br />
- Kubernetes "starter-kit" for OpenStack: https://governance.openstack.org/tc/reference/tags/starter-kit_kubernetes-in-virt.html <br />
<br />
== Dec 4th ==<br />
Attendees:<br />
Prakash Ramachandran<br />
Arkady Kanevsky<br />
Goutham Pacha Ravi<br />
Vida Haririan<br />
Martin Kopec<br />
Agenda:<br />
- Refstack Maintenance - AI -1 (Investigating Refstack and providing input to Interop team) -Martin (Redhat) can help<br />
- Repositories:<br />
- https://opendev.org/osf/refstack (server project) - AI Prakash to lookinto and get back on who mainatins it & how add-on programs gets added/advisory files like dns not getting added - need codes to fix the add-ons integration with marketplace stats<br />
- Patch to add add-ons: https://opendev.org/osf/refstack/commit/0f55b39a6bd013cd808c74b56ff4d1d838f3cd2e <br />
etc/refstack.conf.sample<br />
Like #154 #additional_capability_urls = https://api.github.com/repos/openstack/interop/contents/add-ons - Need code review (GMaan)<br />
- https://opendev.org/osf/refstack-client<br />
- runs tempest tests and generates subunit file<br />
- cannot upload results to the refstack server - (martin) it can, however only manually using refstack-client's API, the ansible-role-refstack-client is a wrapper around refstack-client to allow running tests in an automation (CI, Jenkins jobs ..), see below<br />
- https://opendev.org/x/ansible-role-refstack-client - Need to move to osf repo (add to Board presentation, we can schedule it for next Geriit reboot) -> https://review.opendev.org/c/openstack/project-config/+/765787<br />
osf mirroring responsibility is osf's - it appears so Infra team needs to follow gudielines ? - https://docs.opendev.org/opendev/infra-manual/latest/creators.html#mirroring-projects-to-git-mirrors<br />
Propose Martin as commiter for Refstack -Gautham can handle this<br />
- Martin created this ansible role to automate installation of the refstack client, collating results and uploading them to the refstack server<br />
- it automates everyting needed for running refstack tests - preparation (installing refstack-client, generating tempest.conf), running tests and uploading results to Refstack after the tests are finished <br />
(the result uploading is allowed only with a key identifying refstack account the results will be stored under - so the role will copy the user's key to either local ~/.ssh or even a remote one on a target machine if needed)<br />
- all this can be done by a single playbook run<br />
- the role provides several vars to contol the behavior of the testing - e.g. var for specifying a guideline, a tempest version to use, refstack-client version to use, a var for specifying custom tempest.conf or accounts.yaml (the role will generate them by default)<br />
<br />
- Shared File Systems Add-On advisory follow up<br />
- https://review.opendev.org/c/osf/interop/+/762193 (AI - Gautham to update advisory & Prakash to revise Board presentation to include this + other items above)<br />
What next:<br />
- Needs code reviews, needs to be merged - done<br />
- Goutham will add the 2020.11 advisory "Shared File System" today - done: name in Project File - https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml<br />
<br />
== Friday Nov 27th ==<br />
Attendees:<br />
Prakash<br />
Agenda:<br />
Getting Interop Draft ready for Board approval by email & later at Board meeting Dec.<br />
Cancelling the meeting , but verify code review by Ravi & updated by Ghanshyam<br />
Sent email to Mark to rveiew the workflow.<br />
From my side I will give a +2 for either Mark or Arkady to close and release.<br />
<br />
<br />
== Friday Nov 20 == <br />
Iterop Meeting cancelled - Gerrit maintaenance<br />
http://lists.opendev.org/pipermail/service-announce/2020-October/000012.html<br />
<br />
<br />
== Friday Nov 13th == <br />
Attendeees:<br />
Prakash <br />
Goutham Ravi (gouthamr)<br />
Vida <br />
Arkady<br />
Julia <br />
David Paterson (dpaterson)<br />
<br />
Agenda: <br />
1. Interop Guidelines for 2020.10.json - 2020.10.json (https://opendev.org/osf/interop) - Arkady to try submit to osf/interop - escale to osf staff if needed - Need pointers to results in Markets<br />
2. Interop add-on Guidelines for existing - https://opendev.org/osf/interop/src/branch/master/add-ons<br />
2.a DNS (Designate) - dns.2020.10.json - Need pointers to results <br />
2.b Orchestration(Heat) -orchestration.2020.10.json - Need pointers results<br />
3. Interop add-on guidelines for new proposals - https://www.openstack.org/marketplace/<br />
3.a FileSystem (Manila) - No plans for Victoria<br />
3.b Metal as a Service (Ironic) - No plans for Victoria<br />
4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals - Need Board level guideleines from Foundation<br />
<br />
Q: How do we tie vendor certification to the interop tests? refstack.openstack.org has anonymized results, and nothing about add-on programs<br />
A: These are linked via the Marketplace website<br />
Example marketplace link: https://www.openstack.org/marketplace/public-clouds/ovh-group/ovh-public-cloud (expand test results)<br />
<br />
<br />
== Friday Nov 6th (Decision for Victoria release from core and add-on modules) ==<br />
Attendees:<br />
Prakash Ramchandran<br />
Vida Haririan (vhari)<br />
<br />
Notes: (vhari)<br />
Please confirm if this is the new path to master branch? https://opendev.org/osf/interop/src/branch/master/add-ons - This is the right palce to submit add-on patch for Manila & ironic -Prakash<br />
Commit changes to : https://opendev.org/osf/interop/src/branch/master/add-ons/2020.10.json<br />
Make proposed changes to dns.2020.06.dns and submit<br />
Need document field defenitions used in json file -> Prakash provided 11/6/20++<br />
<br />
https://storyboard.openstack.org/#!/story/2008328 <br />
I have a working draft with cosmetic changes for review<br />
pramchan@ubuntu132:~/interop$ git log --oneline<br />
3a42a6d (HEAD -> master) created Draft for 2020.10<br />
but looks unable to submit it to interop stable? https://opendev.org/osf/interop<br />
pramchan@ubuntu132:~/interop$ diff 2020.10.json 2020.06.json<br />
https://opendev.org/osf/interop/master/<br />
3c3<br />
< "id": "2020.10",<br />
---<br />
> "id": "2020.06",<br />
5,6c5,6<br />
< "reference": "https://opendev.org/osf/interop/master/doc/source/schema/2.0.json",<br />
< "source": "https://opendev.org/osf/interop/master/2020.10.json",<br />
---<br />
> "reference": "https://opendev.org/openstack/interop/raw/branch/master/doc/source/schema/2.0.json",<br />
> "source": "https://opendev.org/openstack/interop/raw/branch/master/2020.06.json",<br />
73,76c73,76<br />
< "target_approval": "2020.10",<br />
< "replaces": "2020.06",<br />
< "releases": ["train", "ussuri", "victoria","wallaby"],<br />
< "status": "draft"<br />
---<br />
> "target_approval": "2020.06",<br />
> "replaces": "2019.11",<br />
> "releases": ["stein", "train", "ussuri", "victoria"],<br />
> "status": "approved"<br />
3209,3226d3208<br />
< "sections": {}<br />
< }<br />
< },<br />
< "designate": {<br />
< "informational": {<br />
< "guidance": "Not a core capability, add-on program is available.",<br />
< "sections": {}<br />
< }<br />
< },<br />
< "manila": {<br />
< "informational": {<br />
< "guidance": "Not a core capability, add-on program is being added.",<br />
< "sections": {}<br />
< }<br />
< },<br />
< "ironic": {<br />
< "informational": {<br />
< "guidance": "Not a core capability, add-on program is being added.",<br />
<br />
Verify above is correct<br />
Please note - https://opendev.org/osf/interop/src/branch/master/add-ons/dns.2020.06.json<br />
<br />
<br />
<br />
Checklist for PTLs (core - keystone, glance, nova, neutron, cinder & swift) and add-ons (heat & designate)<br />
<br />
1. Did the Victoria switch for Jenkins to Zuul V3 and move to new Ubuntu Focal impact your DevStack and Tempesting module feature testing in any way for Interop?<br />
<br />
2. Pease check https://opendev.org/osf/interop/src/branch/master/2020.06.json#L72<br />
We will drop stein and add wallaby, hence train release notes will be the base line for feature retention and compliance baseline testing<br />
<br />
Please verify what are the changes you may need for Victoria cycle for Logo program for your modules list all<br />
core - keystone, glance, nova, neutron, cinder & swift and add-ons (heat & designate)<br />
"required": []<br />
"advisory": []<br />
"deprecated": [] <br />
"removed": []<br />
<br />
3. Reply by email the changes expected for us the review based on your Victoria release notes or add notes to <br />
https://releases.openstack.org/victoria/?_ga=2.174650977.277942436.1604012691-802386709.1603466376<br />
<br />
4. Discussions on Manila - Need Volunteer<br />
5. Disucssions on Ironic - Need Voluteers<br />
6. Discussion on future Kata GoLang - Kata (with tempest vs k8s test tools or https://onsi.github.io/ginkgo/ + Airship, Starlingx, Zuul on infralab ?) - Need volunteers<br />
<br />
<br />
<br />
== Friday October 23rd & 30th ==<br />
Attendees ( Refere PTG Session 1 & 2)<br />
https://etherpad.opendev.org/p/interop-wallaby-ptg<br />
<br />
<br />
Attendees<br />
Prakash Ramchandran<br />
Arkady Kanevsky<br />
Deferred except for announcing PTG items<br />
<br />
Agenda<br />
https://etherpad.opendev.org/p/interop-wallaby-ptg<br />
Where are we at Interop Quaestionnair with Allison -Action Item (Prakash)<br />
Reviewed all above.<br />
<br />
== Friday October 9th ==<br />
Attendees<br />
Prakash Ramchandran<br />
Arkady Kanevsky<br />
David Paterson<br />
Goutham Pacha Ravi (gouthamr)<br />
<br />
Topic:<br />
Review Last calls summary<br />
PTG slots: http://ptg.openstack.org/ptg.html<br />
- 2 hours on Monday: 1300-1500 UTC (Room: Austin)<br />
- 4 hours on Friday: 1300-1700 UTC (Room: Austin)<br />
<br />
<br />
What Capabilities need addressing for Account, Container, Object (https://docs.openstack.org/swift/latest/)<br />
1. Swift - https://github.com/openstack-archive/interop/blob/master/doc/source/process/PlatformCap.rst<br />
Swift API supports three objects - <br />
2. OpenStack Manila inclusion (Goutham Pacha Ravi (gouthamr) - PTL, Manila - Project : manila (Filesystem))<br />
- project has full blown testing<br />
- Protocol support no different from the Cinder storage protocols, in one sense<br />
- How many third party vendors provide tempest results <br />
- What's the common set of capabilities<br />
- Add On Module<br />
- like Heat, Designate<br />
- have an add on module called "File System Storage"<br />
- No admin API is ever tested in interop <br />
- Interop is run for Ussuri right now, will be run for Victoria when it is released<br />
- Testing a release means you're testing three releases prior<br />
- Interop is run after a release, and when a new release is adopted, the oldest one is dropped from the list supported<br />
- Weightage assigned to individual tests<br />
- Vendors commercially supporting submit test results to marketplace<br />
<br />
- Todo:<br />
Identify the capabilities in terms of API/resources<br />
CRUD tests on these resources - identify these tests - drop any that relate to admin<br />
Pre-provisioned accounts are used in tests (manila-tempest-plugin has supported this for a while)<br />
Microversion testing:<br />
- Adopt a baseline that is common for the last three releases<br />
- Baseline moves as we drop support to older releases<br />
- Baseline currently (Oct 2020): https://docs.openstack.org/manila/latest/contributor/api_microversion_history.html#maximum-in-stein<br />
https://etherpad.opendev.org/p/interop2020<br />
https://www.openstack.org/software/project-navigator/openstack-components#openstack-services<br />
<br />
Notes to be circulated for these two to get feedback from community on OpenSTack-Discussions email - AI Prakash<br />
We need Swift PTL to be informed that Interop would like to have a Swift driver for helping commercial Back ends to be tested for comaptaibility like Ceph RGW (PowerFlex)<br />
We need Manila PTL to define the Interop for File System.<br />
<br />
<br />
<br />
<br />
2. K8s conformance APIs (core k8s APIs?)<br />
3 BMaaS conformance APIs (? Ironic, MaaS, Tinker Bell?)<br />
<br />
<br />
== Sept 25 ==<br />
Attendees:<br />
Prakash Ramchandran <br />
Mark Voelker<br />
David Paterson <br />
<br />
Topic: <br />
Interop Certification test results submission? Shambu for Dell seeking clarification <br />
When yo test Run test locally it gets posted to Refstack portal (if you do: "./refstack-client upload -v -k .tempest/.testrepository/0.json"). All one needs isto send that link of test results to interop@openstack.org<br />
https://refstack.openstack.org/#/<br />
You will get message like following<br />
Hello and thanks so much for your interest in the OpenStack Foundation and our supported projects! Someone from our staff will get back to you ASAP.<br />
To add additional comments, reply to this email or click the link below:<br />
https://support.openstack.org/hc/requests/38315<br />
The ticket number issued will be followed up by OpenStack Staff (like Jimmi Mecarthur or some one in his team)<br />
<br />
Interop - Planning for discussions on topic<br />
Proposed Discussion Title - https://ethercalc.openstack.org/7xp2pcbh1ncb (Two slots on Friday 30th Oct -reserved for any additional discussions with conatiner & ironoc teams, Option is see if we can get udates om NFV4 standards for container managament)<br />
InteropWG Looking to new Branding Opportunities<br />
Abstract (1000 chars)<br />
Interop WG has been reviewing opportunities to maintain and build on defcore, refStack & Steller contributors in past. The current team would like to debate, to see what the new opportunities emerge from market disruption due to Hybrid Cloud, Edge, Container footprint over Bare-Metal & with Kubernetes clusters orchestration as the baseline for Infrastructure. Current challenges include Tempest test spread plus updates to refStack . Board is willing address all aspects from license, legal, object storage, bring in Policies for Open-Infra branding opportunities. We like to hear through Q&A session more ideas like kubernetes-ready-Stack, BMaaS add-ons etc <br />
https://etherpad.opendev.org/p/2020-Wallaby-interop-brainstorming<br />
Add-ons - Ironic, k8s conformnace for Open Infra/OpenStack modules, ceph<br />
k8s ready openstack (k8s over OpenStack)- crate volume (offer cinder or Manila for PVs) - Run Sunobuy tests for eg. over this like VIO using Swift, RHOSP with Cinder, Any OpenStack Distro or hoster OpenStack Service needing k8s conformance<br />
Cloud Provider for OpenStack: https://github.com/kubernetes/cloud-provider-openstack<br />
Octavia Load Balacer for Ingress Controller funtion <br />
<br />
<br />
<br />
== Sept 11 == <br />
Attendees:<br />
Prakash Ramchandran<br />
Arkady Kanevsky<br />
The old Interop presentation panel not selected for Summit to be moved to forum with minor changes<br />
https://cfp.openstack.org/app/presentations/24735/preview<br />
https://ethercalc.openstack.org/7xp2pcbh1ncb<br />
FYI only <br />
[1] https://wiki.openstack.org/wiki/Forum<br />
[2] https://www.openstack.org/summit/2020/<br />
[3] https://cfp.openstack.org<br />
[4]https://wiki.openstack.org/wiki/Forum/Virtual2020<br />
<br />
Added two slots for InteropWG Oct 30 - Friday 13-14UTC & 16-17 UTC incase we need other presentaions for containers (NFV4 Standards) , BMaaS / Ironic (APIs and consumption by Airship), Container Interop by OpenSatck (Magnum, Zun, Kuryr & Kolla teams)<br />
<br />
OCT 26 Forum plans- https://ethercalc.openstack.org/7xp2pcbh1ncb<br />
- Any inputs to/from Board for new Logo Programs<br />
-Discussions on CNTT/OPNFV Merger and Proposed RA2 using KubeVirt (https://kubevirt.io/) for VMs along with K8s for Containers? <br />
Impact on Interop for VM + COntainer workloads<br />
<br />
== August 28th ==<br />
Prakash<br />
Cancelling No Quoram<br />
<br />
<br />
== Aug 14 ==<br />
Attendees: <br />
Prakash Ramchandran<br />
Ghanshyam Mann<br />
Arkady Kanevsky<br />
<br />
<br />
Review Forum submission for Project Updates -Prakash + Mark - not clear what is Project Update to Forum, as we don't have any Project for Interop to report? <br />
Forum Submissiom request completed for Interop WG - Prakash - https://openstackfoundation.formstack.com/forms/oct2020_vptg_survey - Filled in with cross project meetings with Intergated projects , Ironic, Container related projected(Mgnum, Kuryr, Kola, Zun), Tempest<br />
- Process - Horizontal - AT start of PTG can be brought asking PTL to acknowledge schedule..and particpate - https://ethercalc.openstack.org/7xp2pcbh1ncb<br />
- Process - Project Specific - (RefStack , Tempest)<br />
Swift - will depend on polling (working with Allison- Follow up) results and any changes to current Tempest coverage<br />
Intergated projects + add-ons (as is exisiting Logo Programs) - Need Deltas<br />
Ironic - add-ons (BM Logo) - Admin API ? should be kept aways? User needs to inherit Admin permission for Ironic APIs to make it interoperable<br />
Container - Refer Friday Juy 17th meeting notes<br />
Foundation Discussions for Open Infrastructure Logo Programs (Market Place feedback or End users need to bring to table , 4Os plus can add to Interop) - Bring to Panel Discussions<br />
OPNFV-CNTT is merging in LFN as OPNFV LLC (without chnage of name) driven by GSMAA + LFN likely Jon 2021.<br />
CNCF driver Cluster API based testing for Containerized Plane...need watching<br />
Tempest - Test Capabilities limited to Integrated Projects, add-ons like Heat & Designate is within - Its limited to QA with Integrated stack<br />
Open Infra projects have their own CI/CD & Testing<br />
RefStack is broken for Ussuri ? Need to generate a report...or file a bug for Ussuri - Check with Mark?<br />
<br />
Seperate from Proposed Panel Submit under - Open Development https://www.openstack.org/summit/2020/vote-for-presentations#/24735<br />
Follow up on Action Intems from last call - <br />
Operator Survey - Follow up with Allison -Prakash -sent email -<br />
New Guidleines for Victoria - Mark? Await an initial patch or we can take up later Victoria Time frame -TBD<br />
Any feedback on Tags for Interop - Ghanshyam from TC (How to enable tag assert:supports-api-interoperability) - Gmann working with Manila -TBD<br />
- assert:supports-api-interoperability -refer - https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml<br />
<br />
== Friday July 31 ==<br />
Prakash Ramchandran<br />
Mark Voelker<br />
Arkady Kanevsky<br />
<br />
Arkady - Everyone can update their user profile for Individual projects<br />
Q? about Interop<br />
About each about projects<br />
Do they use this for <br />
<br />
https://www.openstack.org/user-survey/faq (2014)<br />
interop@openstack.org <br />
<br />
Marketplace needs decouple from Branding? seperate <br />
Decion : All questions should go to Operator and hence Decision makers - Echosystem Operator Survey - Follow up with Allison (Action Intem - Line170-176)<br />
What is there now and response + cc Mark+Ghashyam ...<br />
<br />
Review projects for k8s conformance/Openstack provider APIs<br />
Kourier - https://developers.redhat.com/blog/2020/06/30/kourier-a-lightweight-knative-serving-ingress/<br />
Navisite Cloud Director (NCD) - https://navisite.uservoice.com/knowledgebase/articles/1902673-vcloud-director-api<br />
https://docs.vmware.com/en/VMware-Cloud-Director/index.html<br />
k8s conformance - https://github.com/cncf/k8s-conformance<br />
OpenStack confrmance - https://opendev.org/osf/refstack<br />
OpenStack Integrations testing - https://github.com/openstack/tempest<br />
CI Jobs k8s -https://github.com/kubernetes/test-infra<br />
k8s Openstack Provider - https://github.com/kubernetes/cloud-provider-openstack<br />
<br />
Swift is independent - Do you care about what back end is used with Swift API?<br />
Swift, Swiftstack, Ceph, ECS, ...<br />
<br />
Add-ons<br />
kubernetes - line 103-116(Tempest should have coverage for openstck API which the provider calling)<br />
Community has intrest ? lets wait on this?<br />
Identify requrients ? <br />
kubernets<br />
Ironic - one cycle<br />
<br />
New guidelines for Victoria- Ask PTL/Project Teams if they have anything for 2020.12(?) Guideline:<br />
* Any capabilities in the guidelines that have been depricated inTrain, Ussuri, Victoria<br />
* Any new capabilities that should be added? Must be supported in Train, Ussuri, and Victoria<br />
https://cfp.openstack.org - Project updates for Interop delata... (Add the csfp on Forum and we can knock out 10 slides later - add all 3 names Prakash, Mark & Arkady - Since Ghanshyam is leading Forum sessions<br />
)<br />
Since topics are limited we move the meeting once in two weeks - Next meeting will be on August 14th, 28th...<br />
<br />
== Friday July 24th == <br />
Open Agenda<br />
Sent email and followed up with <br />
Follow ups<br />
Replied email to Allison/Danny/Interop team.<br />
https://Dell.zoom.us/j/92074400967<br />
<br />
<br />
On Jul 17, 2020, at 6:30 PM, Ghanshyam Mann <gmann@ghanshyammann.com> wrote:<br />
I agree with adding question 5th to user survey (along with existing 2 questions) and adding all 5 to marketplace survey to get their feedback.<br />
<br />
-gmann<br />
<br />
<br />
---- On Fri, 17 Jul 2020 16:30:52 -0500 prakash RAMCHANDRAN <pramchan@yahoo.com> wrote ----<br />
Allison,<br />
In short yes both user-survey & marketplace survey.<br />
1. Based on review of user-survey pointed below, if I understand correctly the questions in them relate to existing deployments , its scale and use cases for OSF decision making.<br />
2. The other question you have posted below is questions related to, if the decision makers used the Logo program guidance formulated by InteropWG and challenges they faced in evaluating offers from commercial providers supporting OpenStack.<br />
We like to add the question 5 from InteropWG to be added to user-survey in case they like to deploy Bare metal & "Kubernetes-ready OpenStack" in their deployments as below or some edited form to bring in as decision makers focus on using facts presented in marketplace by participants in logo program.{5.What would you like to see improve in current Marketplace Logo Program?[a] Do you want to add Interop for bare metal service?[b] Do you want to see a new Logo progam called "Kubernetes-Ready OpenStack"? This designation would basically say "any Kubernetes distribution that supports the OpenStack cloud provider should run on this vendor's OpenStack product"}<br />
<br />
3. Sure you can add question to users-survey regarding Object Storage Swift and the back end drivers they use for maintaining them in-tree. Plus any additional guidelines or logo programs we may need to enhance its usability.<br />
4. Finally, we do want to hear from marketplace participants polling as all questions 1-5 (https://etherpad.opendev.org/p/interop-polling-2020) we have framed for reviving their interests in leveraging and enhancing InteropWG future branding opportunities for OSF.<br />
<br />
Hope this clears the questions you have posed and lets know what we can do to sustain and enhance InteropWG efforts.Like other InteropWG members to pitch-in or a simple +1 reply to let Alison handle the rest.<br />
ThanksPrakash<br />
For InteropWG On Friday, July 17, 2020, 12:23:27 PM PDT, Allison Price <allison@openstack.org> wrote: <br />
<br />
Hi Prakash,<br />
I can help. Going to move some folks to bcc because I have a few questions that I want to clarify with you as I review these additions.<br />
Are you wanting these added to the OpenStack User Survey (openstack.org/user-survey) that we share results on annually? Or are you referring to a different survey? Some of these questions seem more directed towards Marketplace vendors, so I wasn’t sure if there was another survey you were referencing. There are already two Interop questions added in the survey that I have included a screenshot of below.<br />
Some of these questions, we can get the information from other responses in the User Survey, like around Object Storage<br />
<br />
Any additional context will be helpful, including what you’re hoping to understand from the results. Happy to help in any way I can.<br />
Thanks,Allison<br />
<br />
On Jul 17, 2020, at 2:11 PM, Mark Collier <mark@openstack.org> wrote:<br />
adding Allison price, who works on a lot of our survey designs.<br />
Allison, can you take a look?<br />
On Jul 17, 2020, at 1:57 PM, prakash RAMCHANDRAN <pramchan@yahoo.com> wrote:<br />
<br />
Ashlee,<br />
Here is InteropWG suggested questions to OSF Exec team to edit as necessary and provide us feedback from marketplace participants as well include as part of Open Infrastructure Summit 2020 for annual OpenStack 2020 survey.<br />
OpenDev Etherpad<br />
OpenDev Etherpad<br />
<br />
<br />
Since you have been facilitating other Projects to add their questions for poll, here is our efforts to help arrive at what's the direction interopWG need to take based on feedback.<br />
If you have any questions to clarify please reply all as we have been formulating this questions over several meetings and deliberations and have documented the logic etc. in our regular community meetings in https://etherpad.opendev.org/p/interop<br />
<br />
ThanksFor InteropWG Prakash<br />
<br />
<br />
== Friday Juy 17th ==<br />
<br />
Refer to remianing one from last week - went through last weeks AIs.<br />
<br />
Some discussions on Licensing Open Stack Open License (OS OL) for Open Infra projects exception processing<br />
This is part of discussions to be taken to board based on new https://openinfralabs.org/ inclusiaon as new project or seperate org<br />
Described university network use case for Manageability but turns out Interop can not touch admin APIs.<br />
Hence we look at some of the followings<br />
Some discussion of possible interop programs:<br />
<br />
Kuberentes<br />
-----------------<br />
* If I as a vendor want to offer Kuberentes and OpenStack to end users...<br />
* I'll probably provide Kubernetes conformance test suite results (to show I have an interoperable K8s) and RefStack results (to show I have an interoperably OpenStack).<br />
* There's not really anything we (InteropWG) need to do for this use case...it's covered by the existing tools/programs.<br />
* If I as a vendor want to offer a product that runs OpenStack in Kubernetes...<br />
* Again, there's not a lot for us to do here: if OpenStack is what is exposed to the end user, then I simply need to run RefStack against that OpenStack to show compliance with Powered guidelines<br />
* If I as a vendor want to provide an OpenStack offering that provides all the necessary API's and capabilities needed by the OpenStack cloud provider for K8s (K8s on top of OpenStack):<br />
* https://github.com/kubernetes/cloud-provider-openstack<br />
* Are all these API's coverged in the OpenStack Powered program today? ¯\_(ツ)_/¯<br />
* Should we have a new logo program (let's call it "Kubernetes-Ready OpenStack" for the moment) that lets vendors certify that their product is interoperable with the OpenStack cloud provider?<br />
* This could be done with a new guideline document that includes tests & designated sections of code specifically for the API's that the OpenStack cloud provider calls.<br />
* This designation would basically say "any Kubernetes distribution that supports the OpenStack cloud provider should run on this vendor's OpenStack product"<br />
* How many vendors would be interested in this? - Can we add his to poll question? +1+1+1<br />
<br />
== July 10th ==<br />
<br />
AI-03 - (for Core + Add-ons for OpenStack Integrated Projects) - Can you volunteer to add tag assert:supports-api-interoperability to your projects?<br />
Any comments on what Projects need to do to claim this based on 2020.06 - interop - https://opendev.org/osf/interop/src/branch/master/2020.06.json <br />
<br />
- We should send email notcies to marketplace participants to update their distros/hsoted solutions/public cloud etc. - OSF foundation should havd the list to send.<br />
- We should send the Quationnair as poll to marketplace and other reevant partciapnts (openirrastructure.labs/ OPen Infrastucuture)<br />
<br />
Can someone take a crack at documenting how to for one project like nova compute api does now?<br />
- assert:supports-api-interoperability<br />
Need guidelines standardization for interoperability<br />
- Version & Discovery should be consistant despite variations in flow <br />
AI-04 - Seeking volunteers to maintain - Refstack - https://opendev.org/osf/refstack<br />
- Maintenance of refstack - Ganesh Hiregaudar (VMWare) + Pavan Dikonkar (team) and/or University/Student support.<br />
<br />
<br />
AI-05 - Can someone volunteer to present at next Interop meeting Friday 3rd at 17 UTC (10 AM PDT) - https://github.com/cncf/k8s-conformance<br />
Presenter to be identified.<br />
??*<br />
*. Ideas for new logo programs to propose to Board working with TC<br />
- Any legal disclaimers or change required - Conformance or validation vs. compliance?<br />
- Revising Object Storage Logo for Swift Compliance (For Platinum/Gold partners)<br />
- Bare Metal Ironic - Independent then how will it release and maintain Interop in Victoria? - https://releases.openstack.org/victoria/index.html - cycle-with-intermediary? likely 3 releases / when will we introduce interop (assert interop)<br />
https://releases.openstack.org/reference/process.html <br />
- Container Projects (Zun, Magnum, Kola, Kuryr) - Container projects - How do they follow release goverance https://governance.openstack.org/tc/reference/projects/release-management.html / how will we introduce k8s conforamce? how with or without tempest?<br />
- Airship Cloud to StarlingX Edge Interop, Can we introduce k8s conformance - what is anyway, any tests - <br />
- kubernetes Conformance for OpenStack & Open Infra Projects. - Where is CI/CD in CNCF for k8s conformance- Can we borrow or we already have in Tempest for Zun?<br />
- Can Serchlight - Resource Type {OS::<br />
<br />
== Next Friday - July 3rd - Meeting Canceled due to July 4 long week end in USA ==<br />
<br />
<br />
== Friday June 26th ==<br />
<br />
1.Interop Ussuri Guidelines established - documented the details in here and merged.<br />
https://storyboard.openstack.org/#!/story/2007510<br />
<br />
https://storyboard.openstack.org/#!/story/2007509<br />
<br />
<br />
(Add above your suggestions)<br />
level 2 Q&A<br />
1. Do you use data on add-on programs in the OpenStack Marketplace?<br />
1.1 If yes which ones?<br />
<br />
<br />
<br />
2. To supersede or abandon this.https://blueprints.launchpad.net/refstack/+spec/interop-2020.06 - Ghanshyam or Mark - please confirm<br />
AI-01 - GM to update/close? launchpad item - https://blueprints.launchpad.net/refstack/+spec/interop-2020.06<br />
With following two references to storyboard for all API guidelines for 2020.06.json.<br />
https://storyboard.openstack.org/#!/story/2007509<br />
https://storyboard.openstack.org/#!/story/2007510<br />
<br />
3. Marketplace participants <br />
AI-02 Regards to Survey questions - https://storyboard.openstack.org/#!/story/2007511<br />
<br />
6/26/2020 - AT todays Interop call it was decided to add following questions and is being circulated for updates via openstack-discuss list.<br />
<br />
1. Do you use OpenStack Marketplace data for your decision on use of OpenStack Cloud? - User Survey/Operator Survey<br />
2. Do you look for at Interoperability OpenStack Powered Logo when selecting an OpenStack product reports available to you on different offerings in Marketplace portal? -User Survey/OperatorSurvey<br />
3. If you offer OpenStack Cloud do you use the OpenStack logo programs.? -Ecosystem Survey/Opertor Survey<br />
4. If you are using Object Storage for your cloud do you use Swift? - User Survey/Operator Survey<br />
5.What would you like to see improve in current Marketplace Logo Program? -Ecosystem Survey/Operator Survey<br />
[a] Do you want to add Interop for bare metal service?<br />
[b] Do you want to see a new Logo progam called "Kubernetes-Ready OpenStack"? This designation would basically say "any Kubernetes distribution that supports the OpenStack cloud provider should run on this vendor's OpenStack product"<br />
<br />
4. The Content & Procedure of Survey to be identified and agreed<br />
- How to send message to Vendors , Distro's, Hosting Partners and other Marketplace participants to test for Logo updates for 2020.06 Ussuri cycle - Consistency in meeting times on irc and websites <br />
- Update site for logo - https://www.openstack.org/brand/interop/<br />
- update site for irc meeting time - https://refstack.openstack.org/#/about#about <br />
<br />
5. Implementing updates to project governance - https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml<br />
How to enable tag assert:supports-api-interoperability (for Core + Add-ons for Integrated Projects)<br />
tags:<br />
- tc:approved-release<br />
- starter-kit:compute<br />
- vulnerability:managed<br />
- assert:follows-standard-deprecation<br />
- assert:supports-upgrade<br />
- assert:supports-rolling-upgrade<br />
- assert:supports-accessible-upgrade<br />
- stable:follows-policy<br />
- assert:supports-api-interoperability<br />
<br />
Chair / Interop WG (Prakash Ramchandran)<br />
Co-Chairs (Mark V.Voelker & Ghanshyam Maan)<br />
Rep. from Board (Arkady Kanevsky)<br />
<br />
<br />
== Friday 19th ==<br />
<br />
Meeting cancelled<br />
<br />
===================================<br />
Please use thi bride for PTG June 1 : monday 6/1/2020 **************************************************************************<br />
Please join Interop WG meeting Jun1 UTC 13-15 (2 hrs) <br />
Austin room zoom link - https://www.openstack.org/ptg/rooms/austin <br />
**********************************************************************************************<br />
=======================================<br />
<br />
Management Meetings (Master for all refrences)<br />
Refere to link for technical details for 2020.06 guideliens - https://etherpad.opendev.org/p/interop2020 / <br />
Meeting Bridge : https://zoom.us/j/914761969 (NA/EU -PDT Fridays 10 AM) 10-10.45 Please use?<br />
Meeting Bridge: : (APJ -BJT Fridays 9 AM ) - APJ Bridge<br />
<br />
== May 29th - PDT 10.00 AM == <br />
Bridge will try both<br />
https://meetpad.opendev.org/Interop-WG-weekly-meeting (Sorry this did not work) <br />
https://Dell.zoom.com/wc/join/99829924353 <br />
< password: 101045 **********************************************************************************************<br />
<br />
Attendees<br />
Prakash<br />
Ghanshyam<br />
Mark (late)<br />
Topics<br />
1. Meetpad does not work as expected /Decided that we will use Zoom instead <br />
<br />
2. Nova - compute api testing<br />
https://refstack.openstack.org/#/results/d950f90f-fcc9-4216-962e-2bd0ce4b6fea<br />
We just pickedup NOT PASSED in "next " to see why compute list failure show up in Refstack when the regular nova is passing it?<br />
stack@ubuntu-os-host:~/tempest$ tempest run --regex tempest.api.compute.servers.test_list_server_filters.ListServerFiltersTestJSON.test_list_servers_filtered_by_ip<br />
Make sure the Usuri has cirros image to test<br />
<br />
3. Tasks to complete for approving guidelines for 2020.06 by June 10th<br />
a. Verify all changes<br />
Reviewed relevant APIs<br />
Identity (Keystone)<br />
https://docs.openstack.org/api-ref/identity/v3/index.html#<br />
Comute + Image (Nova, Glance)<br />
https://docs.openstack.org/api-ref/compute/<br />
https://docs.openstack.org/api-ref/image/v2/index.html<br />
Networking (Neutron)<br />
https://docs.openstack.org/api-ref/network/v2/index.html<br />
Block Storage - Cinder<br />
https://docs.openstack.org/api-ref/block-storage/v3/index.html<br />
Object Store (Swift)<br />
https://docs.openstack.org/api-ref/object-store/<br />
<br />
add-ons<br />
Orchestartion<br />
https://docs.openstack.org/api-ref/orchestration/v1/index.html<br />
DNS<br />
https://docs.openstack.org/api-ref/dns/<br />
<br />
b. Clean up the flagged tests<br />
<br />
Myay 29th - AsiaPacifc meeting 9 AM BJT<br />
Dr Li Kiai<br />
Prakash Ramchandran<br />
Tried - https://meetpad.opendev.org/Interop-WG-weekly-meeting (Failed)<br />
Tried - , https://Dell.zoom.com.cn/j/94921799892?pwd=R3RESHVQWWl6WC8vTUcvUEROTW9sUT09 - Failed<br />
<br />
The Audio did not work and decides to abnndon but send info to marketing@99cloud.net for follow up for adding topics to<br />
https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020<br />
<br />
<br />
== Friday May 22 ==<br />
Prakash Ramchandran<br />
Mark Voelker<br />
<br />
Request email to community for guidelines review<br />
<br />
Interop WG approvel sceduled for June 11 - https://wiki.openstack.org/wiki/Governance/Foundation#OpenStack_Board_of_Director_Meetings<br />
<br />
<br />
== Friaday May 15th ==<br />
Prakash Ramchandran<br />
Kanevsky Arkady<br />
Ghanshyam Mann<br />
<br />
<br />
Ussuri Release announcement<br />
http://lists.openstack.org/pipermail/openstack-announce/2020-May/002035.html<br />
<br />
Reviewing Release Notes for API changes<br />
https://review.opendev.org/#/c/722137/<br />
<br />
TODO:<br />
Ghanshyam to remove the deprecated tests from new guidlines and add a patch<br />
https://review.opendev.org/#/c/728564/<br />
Review 'Advisory' with Mark and apply new patch<br />
Prakash to check for new 'Required' capabilities from Ussuri release.<br />
Send mail to PTL on openstack-discuss about new core capabilities: Core + adds-on<br />
Review microversion(or any API versioning mechanism) is deffered to post release.<br />
<br />
<br />
Review Next in Refstck for test passings<br />
https://refstack.openstack.org/#/results/d950f90f-fcc9-4216-962e-2bd0ce4b6fea<br />
<br />
<br />
<br />
<br />
== Friday May 8 ==<br />
Prakash Ramchandran<br />
Mark Voelker<br />
<br />
Worked through core and add-ons reviiewing scores and API and finally decided to commit Patch 4.<br />
Mark Added Prakash for +2 Interop WG Reop<br />
Prakash Added for Arkady +2 InteropWG Repo<br />
We still will retaning Egle Sigler for the work she has done and hope she may return infuture.<br />
For now Draft is mearged for testing.<br />
Once we have few tests run by current or any new Marketplace Distro or Vendor offerings <br />
Plest test for 2020.06 draft and provide feedback...over next few weeks<br />
x<br />
<br />
Board Approval request? - Got email from Alan scheduling it for June<br />
planning for PTG<br />
https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020<br />
<br />
Core Scoring - Cutoff - 74 of 102<br />
A - Atomic - 6<br />
U - Used by Clients (Nova, Neutron etc.) - 10<br />
C - Complete - 10<br />
W - Widely Deployed - (muliple Proviers) - 8<br />
D - Discoverable (Service through keystone and introspection) - 8<br />
D - Documented - 8<br />
F - Foundation - Tests for uinversl Dependencies - 9<br />
F - Future Direction (TC recommended for verions & compatible) - 11<br />
P - Proximity reletaed to Coe - 8<br />
S - Stable - 9<br />
S - Sticky -Must pass per release - 9<br />
U - Used by Tools of External Providers like Rackspace, RightScale, JCloud - 6<br />
<br />
<br />
Add-ons scorinng<br />
Cutoff 60<br />
AUCDDF<br />
A - Atmoic - 6<br />
U - Used by Clients - 10<br />
C - Complete -10<br />
D -Discoverable -8<br />
D - Documented - 8<br />
F- Future -11<br />
<br />
Reviewed relevant APIs<br />
Identity (Keystone)<br />
https://docs.openstack.org/api-ref/identity/v3/index.html#<br />
Comute + Image (Nova, Glance)<br />
https://docs.openstack.org/api-ref/compute/<br />
https://docs.openstack.org/api-ref/image/v2/index.html<br />
Networking (Neutron)<br />
https://docs.openstack.org/api-ref/network/v2/index.html<br />
Block Storage - Cinder<br />
https://docs.openstack.org/api-ref/block-storage/v3/index.html<br />
Object Store (Swift)<br />
https://docs.openstack.org/api-ref/object-store/<br />
<br />
add-ons<br />
Orchestartion<br />
https://docs.openstack.org/api-ref/orchestration/v1/index.html<br />
DNS<br />
https://docs.openstack.org/api-ref/dns/<br />
<br />
<br />
Tempest for Testing APIs with idempotetnt_id for tests with 1-to-may releations / API testing may use multiple ids in guidelines file<br />
https://opendev.org/openstack/tempest/src/branch/master/tempest/api/compute/test_versions.py<br />
<br />
<br />
== Friday May 1 ==<br />
<br />
eed few decisions <br />
1. Should-add ons for Heat and Designate be in separate file like 2020.06.json or 2020.06.nn.json - keep it seperate but can submit as sinle patch<br />
Past guidelines: https://opendev.org/openstack/interop/src/branch/master/add-ons/<br />
Chat notes for Mark for creating add-ons for 2020 for orchestartion & dns<br />
wget https://github.com/openstack/interop/blob/master/add-ons/orchestration.2019.11.json<br />
Or rather: wget https://github.com/openstack/interop/blob/master/add-ons/orchestration.2019.11.json<br />
<br />
Complete 3rd Patch<br />
Done - https://review.opendev.org/722137 [Call for content review]<br />
<br />
Please add your name for review if you have time, we need few +1s and two +2's<br />
Mark & Egle can review and give +2<br />
All others including Arkady, Ghansyam, Dr Likai & Mohammad can provide a +1 after reviewing for us to close with zero or more patches as needed based on review.<br />
<br />
<br />
2. If separate can some one volunteer or should I add to single file and we filter out test<br />
results for logo mark as part of validations.<br />
The Process used to be Next in Refstack Window lie<br />
https://refstack.openstack.org/#/results/d950f90f-fcc9-4216-962e-2bd0ce4b6fea<br />
So pre-approval testing was done through next json file.<br />
Since we are short on time have decided to lump in basic plus add-ons as one patch and after code review we will merge and let tests be done with pending board approval.<br />
But will ask for approval at next Baord meeting<br />
<br />
3. Do we review in meeting and make a call and then send to opestack-discuss mail for confirming release changes for needed 80 + 18 current api scenario's (Compute + Storage) or other way round?<br />
This is answered in 2 above as we are short circuting the process, as all we cars is user level APIs for respective modules and scores included from 2019.11.json gudieleines<br />
<br />
4. Plans for beyond June In Victoria for interop.<br />
There are two ways to support Edge Cloud logos in OpenStack<br />
1.Use hierarchial Openstack with Central and Distributed nodes with different stack components (specifically Glance matser and Glance with replication for local availability of images to boot for Edge Applications per tenant)<br />
2. Federated Edges with Stacks as they need to run OpenStack at scale individual locations need<br />
<br />
How to do this and what APIs additions this brings in, we willreview next week.<br />
1. <br />
<br />
<br />
<br />
<br />
5. Other suggestions from Asia Pacific team.<br />
<br />
Check this out for Compute<br />
https://etherpad.opendev.org/p/interop2019<br />
or<br />
https://refstack.openstack.org/#/results/d950f90f-fcc9-4216-962e-2bd0ce4b6fea<br />
See if can get something for 2020.06 without approval?<br />
<br />
<br />
<br />
<br />
API-Docs - https://docs.openstack.org/api-ref/<br />
US/EU<br />
APJ <br />
<br />
== Friday 24, April 2020 / 10 AM PDT ==<br />
Present<br />
Prakash Ramchandran<br />
Arkady Kanevsky<br />
Ghanshyam Mann<br />
<br />
Topic:<br />
To Review : https://blueprints.launchpad.net/refstack/+spec/interop-2020.06 (new bp reday for review -refer tech work link at the top)<br />
Fix metadat -> 2020..06 to 2020.06 -Arkady (Done)<br />
Mark's reviews & questions - discuss and fix online<br />
Add DNS? combine or seperate?<br />
<br />
Add Orchestration? combine or seperate?<br />
Drop Ceilometer? ( No replacers with Aodh or any telemetry modules?) - For now dropping out, will check with Mark/Mohammad for add-on for telemetry<br />
<br />
Sure this is draft not approved, we can correct. - fixed removed approved to draft<br />
<br />
Also any other thoughts on alternate orchestration based on kubernetes api as sub for heat orchestration?<br />
TBD - for now assiging heat orchestartion work to Mark if he can volunteer<br />
<br />
Heat creates VM stacks and k8s for crio based for containers or pods (? stacks not sure, may be clusters+pods/+servcies).<br />
<br />
Also openstack control plane using containers as CAPO provider.<br />
<br />
Let's do review these crazy possibilities too.<br />
What was the logic earlier in 2019.11 to keep DNS and Orchestration out of core?<br />
Comparing the flexibility offered by k8s to use cluster DNS as a "Service" over coreDNS as internal name registry for PODs.<br />
In OpenStack case we have mixup between Glance rgeistry versus designate versus Heat and may need relook as how to simplify, if we really want to make it flexible.<br />
<br />
Revise the story2000-7507,-7509,-7510<br />
Review OpenStack Controle Plane in CAPI - <br />
Review Image needed for container based Openstack Controller in SCI Image builder - https://image-builder.sigs.k8s.io/capi/providers/openstack.html<br />
<br />
== Friday 24, April 2020 / 9 AM BJT ==<br />
Present<br />
Prakash Ramchandran<br />
Dr Li Kai<br />
<br />
How do we handle new Profiles for NFV, Edge, Hybrid Cloud, HPC<br />
We shoul look at Contianer based OpenStack Control plane as a target.<br />
This will also mean we need an image that we can use for different mdules or service_types as in microservcies<br />
We can review Adjecensies as how Airship uses OpenStack Control plane and workloads - Refer <br />
https://etherpad.opendev.org/p/interop2020<br />
Zun APIs for Capsules/PoDs may be an answer along with Magnum or kuryr<br />
https://wiki.openstack.org/wiki/Kuryr<br />
We will see if add-ons like orchestartion & desgnate , we can add for Zun...<br />
<br />
<br />
== Friday 17, April 2020 /10 AM PDT ==<br />
Prakash Ramchandran<br />
Mark T. Voelker<br />
Arkady Kanevsky<br />
Topic:<br />
Discovering what to do now and beyond in 2020<br />
<br />
Minutes:<br />
Discussed on CAPI over OpenStack API for K8s based cluster<br />
Whay not do Direct in OpenStack through Zun or OoK like Airshi? <br />
<br />
== Friday 10 , April 2020 /10 AM PDT ==<br />
Attendees: Prakash Ramchandran<br />
Mark T. Voelker<br />
Mohammad Naser<br />
Topic: <br />
Prakash started working on Train Refstack and created a BP for Train<br />
https://blueprints.launchpad.net/refstack/+spec/refstack-train-api - Superseded as suggeted by Mark.<br />
story2007510 -on hold<br />
story2007507 -on hold<br />
story2007509 -on hold<br />
Define the Specs: INPROGRESS (will be revised based on new bp/2020.06 refer next week entry)<br />
Approve the Specs: TODO<br />
Implement the Specs for One Vendor: TODO<br />
Minutes: <br />
2019.06 does cover Train but not Usuri [1], 2019.11 covers both [2] <br />
[1] https://opendev.org/openstack/interop/src/branch/master/2019.06.json#L75<br />
[2] https://opendev.org/openstack/interop/src/branch/master/2019.11.json#L75<br />
More discussions on covering Hybrid and Multi-cloud<br />
<br />
== Friday 10. April 20 / 9 AM BJT (6.30 PDT Thu) -APJ bridge ==<br />
Attendees: Prakash Ramchandran<br />
Dr Li Kai <br />
https://Dell.zoom.com/wc/join/94921799892 (APJ -BJT Fridays 9 AM ) - APJ Bridge Password 200011<br />
Topic: Briefing APJ partcpants what was presented to Board 0n April 4 - https://wiki.openstack.org/wiki/Governance/Foundation/14April2020BoardMeeting<br />
Feedback needs to adddress new areas<br />
Minutes: <br />
Sugessions from Dr Li Kai for looking at Edge & Hybrid CLoud Interoperability<br />
<br />
== Friday 3, April 2020 ==<br />
Attendees: Prakash Ramchandran<br />
Mark T. Voelker<br />
Ghanshyam Maan<br />
Topic:<br />
Where to Start and What to do?<br />
Reviwe RefStack, Tempest and Interop<br />
Minutes: <br />
Show we expand the Program to cover NFV, Containers etc. - First get to do minimum for next release<br />
Can we look at K8s compliance for OpenStack Projects. - May be not since Source codes may not be owned by or Licenses my differ<br />
Think out-of box for other compliance + Compatibility logo marks like Oen Infra Logog Mark etc.<br />
Prakash to review Refstack & Tempest<br />
Prakash Preparing slides for Board for rebooting InteropWG -Shared tentative Slides</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=180366Governance/InteropWG2022-01-13T16:09:57Z<p>Arkady: added 2020 minutes link</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" that is supported by all implementations as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/Lexicon.html Terms Definition]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/CoreDefinition.html 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://opendev.org/openinfra/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/DesignatedSections.html10 Designed Sections Principles] (board approved December 2014)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/GovernanceProcess.html Interop Working Group Governance:]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/2021A.html Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/next.json draft of the next OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://docs.opendev.org/openinfra/interop/latest/guidelines/index.html OpenStack Powered and Add-on Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines Source Directory of all previous OpenStack Powered Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/ Source Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since September 23 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Thursday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Thursday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
[https://wiki.openstack.org/wiki/Governance/InteropWG/Minutes2020 Minutes of Interop WG 2020 meetings] <br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/102303/martin-kopec Martin Kopec] (chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG/Minutes2020&diff=180365Governance/InteropWG/Minutes20202022-01-13T16:06:33Z<p>Arkady: Create minutes for Interop WG 2020 meetings</p>
<hr />
<div>This page contains Logs of 2020 Interop WG meetings.<br />
<br />
OIF - Interop, Branding to be taken after new commitee is formed<br />
Manila - As on Dec 18 meeting no change<br />
Ironic - On Hold till Julia PTL is ready, after the OIF decision<br />
Next week call -Prakash to send email<br />
<br />
Next meeting Friday Dec 18th <br />
Attendees: Prakash, Arkady, Vida, Martin, Goutham<br />
Topics:<br />
- last meeting AIs, updates<br />
- refstack website needs maintenance<br />
- Look at Interop web pages to fix them (Notes to be added)<br />
- http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019185.html<br />
- .next files need to be updated - gmann will do this after the draft guidelines are approved by the OSF Board<br />
- Updating the guidelines as per Dec 8th Board meeting - https://review.opendev.org/c/osf/interop/+/766778<br />
- Website needs updates, to expose add-ons<br />
- the new guideline is not updated on refstack (server) side<br />
- https://refstack.openstack.org/api/v1/guidelines/<br />
- https://refstack.openstack.org/#/results/f75c4c91-8bdd-471f-823e-41fa7c7538eb <br />
- (when you open a result page you cannot see the new guideline in the Guideline Versions drop-down menu)<br />
- wrong issues links in opendev.org - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019416.html<br />
- https://opendev.org/osf/refstack-client - Issues link redirects to https://storyboard.openstack.org/#!/project/openstack/refstack-client<br />
- notice the namespace , it's 'openstack' and it should be 'osf'<br />
We also should review and update https://www.openstack.org/brand/interop/ documentation<br />
also https://refstack.openstack.org/#/about#about<br />
alsohttps://refstack.openstack.org/#/guidelines still does not show 2020.11 guidelines<br />
- bug tracking revival/options:<br />
- https://launchpad.net/refstack<br />
- https://launchpad.net/~refstack-bugs/+members#active <br />
- Chris Hoge can still be contacted - Danny Carreno <danny@openstack.org><br />
- AI: Goutham contact the admin (Catherine Diep) of this group (and related groups)<br />
- https://storyboard.openstack.org/#!/project/700 <br />
- Should Heat engine can sub Kubernetes as revamping of OpenStack as a whole to be based on KCP? - bring it board for discussion but Technical committee should take a dig at this<br />
- Should tempest add go libs (ginkos & go*)<br />
- Marketing message on Interop contribution to compile the 2020 Open Infrastructure Foundation annual report. (Deadline Jan 13,2021)<br />
https://etherpad.opendev.org/p/2020-Wallaby-interop-brainstorming (Lin 23 onwards to end)<br />
<br />
<br />
<br />
Next meeting Friday Dec 11th <br />
Attendees: Prakash Ramchandran, Martin Kopec, Vida Haririan, Ghanshyam Mann, Goutham Pacha Ravi<br />
- Review Board meeting inputs<br />
- Discussion to extend the interop program across all OIF projects<br />
- TBI (Trademark and Branding Initiative) proposed/to-be-formed within the foundation board<br />
- TBI will be functional only after the new board is formed - elections will begin in 2021<br />
- 2021 Election Info: <br />
https://www.openstack.org/election/2021-individual-director-election/<br />
https://www.openstack.org/election/2021-individual-director-election/CandidateList<br />
- Action Items from the last meeting<br />
- Refstack Maintenance<br />
- Current Refstack Maintainers: https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members<br />
- Need to get Martin Kopec added there: <br />
- http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019263.html<br />
- Reform the core team for:<br />
- openstack/python-tempestconf<br />
- openstack/refstack<br />
- openstack/refstack-client<br />
- x/ansible-role-refstack-client (moving to osf/ via https://review.opendev.org/765787) - needs your +1s, please<br />
- Proposal:<br />
- "refstack-core" group <br />
- Update the groups with new members and erplace any other refstack corewith this new group.<br />
- include "interop-core" group in the refstack-core group so we can manage both of these individually <br />
https://review.opendev.org/admin/groups/ad95fb605fa544dab35712194df7faaa10ec7a22,members<br />
- includes chair/co-chair no change. in existing one.<br />
- Action Items for this week:<br />
- gmann will send email to revive the "refstack-core" group, gain control and seed it with interested members (the email will call for any interested contributors to reach out) <br />
- gmann<br />
- martin (mkopec@redhat.com)<br />
- Goutham<br />
- vhari (vhariria@redhat.com)<br />
- interop-core<br />
<br />
- How do we cater to OIF & or OSF Kubernetes Distros for comformance testing or leave that to upstream kubernetes & arrange discussions with CNCF? -next call<br />
- Prow -Build and test k8s projects - Sonobouy<br />
- KoO using for Cloud Provider OpenStack with Prow -<br />
- KoO using for Cloud Provider Openstack + Manila using Zuul -<br />
- https://github.com/kubernetes/cloud-provider-openstack <-- this is where OpenStack integrations live, and are being tested<br />
- Kubernetes "starter-kit" for OpenStack: https://governance.openstack.org/tc/reference/tags/starter-kit_kubernetes-in-virt.html <br />
<br />
Friday Dec 4th<br />
Attendees:<br />
Prakash Ramachandran<br />
Arkady Kanevsky<br />
Goutham Pacha Ravi<br />
Vida Haririan<br />
Martin Kopec<br />
Agenda:<br />
- Refstack Maintenance - AI -1 (Investigating Refstack and providing input to Interop team) -Martin (Redhat) can help<br />
- Repositories:<br />
- https://opendev.org/osf/refstack (server project) - AI Prakash to lookinto and get back on who mainatins it & how add-on programs gets added/advisory files like dns not getting added - need codes to fix the add-ons integration with marketplace stats<br />
- Patch to add add-ons: https://opendev.org/osf/refstack/commit/0f55b39a6bd013cd808c74b56ff4d1d838f3cd2e <br />
etc/refstack.conf.sample<br />
Like #154 #additional_capability_urls = https://api.github.com/repos/openstack/interop/contents/add-ons - Need code review (GMaan)<br />
- https://opendev.org/osf/refstack-client<br />
- runs tempest tests and generates subunit file<br />
- cannot upload results to the refstack server - (martin) it can, however only manually using refstack-client's API, the ansible-role-refstack-client is a wrapper around refstack-client to allow running tests in an automation (CI, Jenkins jobs ..), see below<br />
- https://opendev.org/x/ansible-role-refstack-client - Need to move to osf repo (add to Board presentation, we can schedule it for next Geriit reboot) -> https://review.opendev.org/c/openstack/project-config/+/765787<br />
osf mirroring responsibility is osf's - it appears so Infra team needs to follow gudielines ? - https://docs.opendev.org/opendev/infra-manual/latest/creators.html#mirroring-projects-to-git-mirrors<br />
Propose Martin as commiter for Refstack -Gautham can handle this<br />
- Martin created this ansible role to automate installation of the refstack client, collating results and uploading them to the refstack server<br />
- it automates everyting needed for running refstack tests - preparation (installing refstack-client, generating tempest.conf), running tests and uploading results to Refstack after the tests are finished <br />
(the result uploading is allowed only with a key identifying refstack account the results will be stored under - so the role will copy the user's key to either local ~/.ssh or even a remote one on a target machine if needed)<br />
- all this can be done by a single playbook run<br />
- the role provides several vars to contol the behavior of the testing - e.g. var for specifying a guideline, a tempest version to use, refstack-client version to use, a var for specifying custom tempest.conf or accounts.yaml (the role will generate them by default)<br />
<br />
- Shared File Systems Add-On advisory follow up<br />
- https://review.opendev.org/c/osf/interop/+/762193 (AI - Gautham to update advisory & Prakash to revise Board presentation to include this + other items above)<br />
What next:<br />
- Needs code reviews, needs to be merged - done<br />
- Goutham will add the 2020.11 advisory "Shared File System" today - done: name in Project File - https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml<br />
<br />
<br />
<br />
<br />
Friday Nov 27th<br />
Attendees:<br />
Prakash<br />
Agenda:<br />
Getting Interop Draft ready for Board approval by email & later at Board meeting Dec.<br />
Cancelling the meeting , but verify code review by Ravi & updated by Ghanshyam<br />
Sent email to Mark to rveiew the workflow.<br />
From my side I will give a +2 for either Mark or Arkady to close and release.<br />
<br />
<br />
Friday Nov 20 th<br />
Iterop Meeting cancelled - Gerrit maintaenance<br />
http://lists.opendev.org/pipermail/service-announce/2020-October/000012.html<br />
<br />
<br />
Friday Nov 13th <br />
Attendeees:<br />
Prakash <br />
Goutham Ravi (gouthamr)<br />
Vida <br />
Arkady<br />
Julia <br />
David Paterson (dpaterson)<br />
<br />
Agenda: <br />
1. Interop Guidelines for 2020.10.json - 2020.10.json (https://opendev.org/osf/interop) - Arkady to try submit to osf/interop - escale to osf staff if needed - Need pointers to results in Markets<br />
2. Interop add-on Guidelines for existing - https://opendev.org/osf/interop/src/branch/master/add-ons<br />
2.a DNS (Designate) - dns.2020.10.json - Need pointers to results <br />
2.b Orchestration(Heat) -orchestration.2020.10.json - Need pointers results<br />
3. Interop add-on guidelines for new proposals - https://www.openstack.org/marketplace/<br />
3.a FileSystem (Manila) - No plans for Victoria<br />
3.b Metal as a Service (Ironic) - No plans for Victoria<br />
4. What's next for Interop 2021 with containers & Kubernetes/magnum ? - Need Volunteers with go skills for new conformance test proposals - Need Board level guideleines from Foundation<br />
<br />
Q: How do we tie vendor certification to the interop tests? refstack.openstack.org has anonymized results, and nothing about add-on programs<br />
A: These are linked via the Marketplace website<br />
Example marketplace link: https://www.openstack.org/marketplace/public-clouds/ovh-group/ovh-public-cloud (expand test results)<br />
<br />
<br />
Friday Nov 6th (Decision for Victoria release from core and add-on modules)<br />
Attendees:<br />
Prakash Ramchandran<br />
Vida Haririan (vhari)<br />
<br />
Notes: (vhari)<br />
Please confirm if this is the new path to master branch? https://opendev.org/osf/interop/src/branch/master/add-ons - This is the right palce to submit add-on patch for Manila & ironic -Prakash<br />
Commit changes to : https://opendev.org/osf/interop/src/branch/master/add-ons/2020.10.json<br />
Make proposed changes to dns.2020.06.dns and submit<br />
Need document field defenitions used in json file -> Prakash provided 11/6/20++<br />
<br />
https://storyboard.openstack.org/#!/story/2008328 <br />
I have a working draft with cosmetic changes for review<br />
pramchan@ubuntu132:~/interop$ git log --oneline<br />
3a42a6d (HEAD -> master) created Draft for 2020.10<br />
but looks unable to submit it to interop stable? https://opendev.org/osf/interop<br />
pramchan@ubuntu132:~/interop$ diff 2020.10.json 2020.06.json<br />
https://opendev.org/osf/interop/master/<br />
3c3<br />
< "id": "2020.10",<br />
---<br />
> "id": "2020.06",<br />
5,6c5,6<br />
< "reference": "https://opendev.org/osf/interop/master/doc/source/schema/2.0.json",<br />
< "source": "https://opendev.org/osf/interop/master/2020.10.json",<br />
---<br />
> "reference": "https://opendev.org/openstack/interop/raw/branch/master/doc/source/schema/2.0.json",<br />
> "source": "https://opendev.org/openstack/interop/raw/branch/master/2020.06.json",<br />
73,76c73,76<br />
< "target_approval": "2020.10",<br />
< "replaces": "2020.06",<br />
< "releases": ["train", "ussuri", "victoria","wallaby"],<br />
< "status": "draft"<br />
---<br />
> "target_approval": "2020.06",<br />
> "replaces": "2019.11",<br />
> "releases": ["stein", "train", "ussuri", "victoria"],<br />
> "status": "approved"<br />
3209,3226d3208<br />
< "sections": {}<br />
< }<br />
< },<br />
< "designate": {<br />
< "informational": {<br />
< "guidance": "Not a core capability, add-on program is available.",<br />
< "sections": {}<br />
< }<br />
< },<br />
< "manila": {<br />
< "informational": {<br />
< "guidance": "Not a core capability, add-on program is being added.",<br />
< "sections": {}<br />
< }<br />
< },<br />
< "ironic": {<br />
< "informational": {<br />
< "guidance": "Not a core capability, add-on program is being added.",<br />
<br />
Verify above is correct<br />
Please note - https://opendev.org/osf/interop/src/branch/master/add-ons/dns.2020.06.json<br />
<br />
<br />
<br />
Checklist for PTLs (core - keystone, glance, nova, neutron, cinder & swift) and add-ons (heat & designate)<br />
<br />
1. Did the Victoria switch for Jenkins to Zuul V3 and move to new Ubuntu Focal impact your DevStack and Tempesting module feature testing in any way for Interop?<br />
<br />
2. Pease check https://opendev.org/osf/interop/src/branch/master/2020.06.json#L72<br />
We will drop stein and add wallaby, hence train release notes will be the base line for feature retention and compliance baseline testing<br />
<br />
Please verify what are the changes you may need for Victoria cycle for Logo program for your modules list all<br />
core - keystone, glance, nova, neutron, cinder & swift and add-ons (heat & designate)<br />
"required": []<br />
"advisory": []<br />
"deprecated": [] <br />
"removed": []<br />
<br />
3. Reply by email the changes expected for us the review based on your Victoria release notes or add notes to <br />
https://releases.openstack.org/victoria/?_ga=2.174650977.277942436.1604012691-802386709.1603466376<br />
<br />
4. Discussions on Manila - Need Volunteer<br />
5. Disucssions on Ironic - Need Voluteers<br />
6. Discussion on future Kata GoLang - Kata (with tempest vs k8s test tools or https://onsi.github.io/ginkgo/ + Airship, Starlingx, Zuul on infralab ?) - Need volunteers<br />
<br />
<br />
<br />
Next alternate week meetings Friday October 23rd & 30th<br />
Attendees ( Refere PTG Session 1 & 2)<br />
https://etherpad.opendev.org/p/interop-wallaby-ptg<br />
<br />
<br />
Attendees<br />
Prakash Ramchandran<br />
Arkady Kanevsky<br />
Deferred except for announcing PTG items<br />
<br />
Agenda<br />
https://etherpad.opendev.org/p/interop-wallaby-ptg<br />
Where are we at Interop Quaestionnair with Allison -Action Item (Prakash)<br />
Reviewed all above.<br />
<br />
Next alternate week meetings Friday October 9th<br />
Attendees<br />
Prakash Ramchandran<br />
Arkady Kanevsky<br />
David Paterson<br />
Goutham Pacha Ravi (gouthamr)<br />
<br />
Topic:<br />
Review Last calls summary<br />
PTG slots: http://ptg.openstack.org/ptg.html<br />
- 2 hours on Monday: 1300-1500 UTC (Room: Austin)<br />
- 4 hours on Friday: 1300-1700 UTC (Room: Austin)<br />
<br />
<br />
What Capabilities need addressing for Account, Container, Object (https://docs.openstack.org/swift/latest/)<br />
1. Swift - https://github.com/openstack-archive/interop/blob/master/doc/source/process/PlatformCap.rst<br />
Swift API supports three objects - <br />
2. OpenStack Manila inclusion (Goutham Pacha Ravi (gouthamr) - PTL, Manila - Project : manila (Filesystem))<br />
- project has full blown testing<br />
- Protocol support no different from the Cinder storage protocols, in one sense<br />
- How many third party vendors provide tempest results <br />
- What's the common set of capabilities<br />
- Add On Module<br />
- like Heat, Designate<br />
- have an add on module called "File System Storage"<br />
- No admin API is ever tested in interop <br />
- Interop is run for Ussuri right now, will be run for Victoria when it is released<br />
- Testing a release means you're testing three releases prior<br />
- Interop is run after a release, and when a new release is adopted, the oldest one is dropped from the list supported<br />
- Weightage assigned to individual tests<br />
- Vendors commercially supporting submit test results to marketplace<br />
<br />
- Todo:<br />
Identify the capabilities in terms of API/resources<br />
CRUD tests on these resources - identify these tests - drop any that relate to admin<br />
Pre-provisioned accounts are used in tests (manila-tempest-plugin has supported this for a while)<br />
Microversion testing:<br />
- Adopt a baseline that is common for the last three releases<br />
- Baseline moves as we drop support to older releases<br />
- Baseline currently (Oct 2020): https://docs.openstack.org/manila/latest/contributor/api_microversion_history.html#maximum-in-stein<br />
https://etherpad.opendev.org/p/interop2020<br />
https://www.openstack.org/software/project-navigator/openstack-components#openstack-services<br />
<br />
Notes to be circulated for these two to get feedback from community on OpenSTack-Discussions email - AI Prakash<br />
We need Swift PTL to be informed that Interop would like to have a Swift driver for helping commercial Back ends to be tested for comaptaibility like Ceph RGW (PowerFlex)<br />
We need Manila PTL to define the Interop for File System.<br />
<br />
<br />
<br />
<br />
2. K8s conformance APIs (core k8s APIs?)<br />
3 BMaaS conformance APIs (? Ironic, MaaS, Tinker Bell?)<br />
<br />
<br />
Sept 25<br />
Attendees:<br />
Prakash Ramchandran <br />
Mark Voelker<br />
David Paterson <br />
<br />
Topic: <br />
Interop Certification test results submission? Shambu for Dell seeking clarification <br />
When yo test Run test locally it gets posted to Refstack portal (if you do: "./refstack-client upload -v -k .tempest/.testrepository/0.json"). All one needs isto send that link of test results to interop@openstack.org<br />
https://refstack.openstack.org/#/<br />
You will get message like following<br />
Hello and thanks so much for your interest in the OpenStack Foundation and our supported projects! Someone from our staff will get back to you ASAP.<br />
To add additional comments, reply to this email or click the link below:<br />
https://support.openstack.org/hc/requests/38315<br />
The ticket number issued will be followed up by OpenStack Staff (like Jimmi Mecarthur or some one in his team)<br />
<br />
Interop - Planning for discussions on topic<br />
Proposed Discussion Title - https://ethercalc.openstack.org/7xp2pcbh1ncb (Two slots on Friday 30th Oct -reserved for any additional discussions with conatiner & ironoc teams, Option is see if we can get udates om NFV4 standards for container managament)<br />
InteropWG Looking to new Branding Opportunities<br />
Abstract (1000 chars)<br />
Interop WG has been reviewing opportunities to maintain and build on defcore, refStack & Steller contributors in past. The current team would like to debate, to see what the new opportunities emerge from market disruption due to Hybrid Cloud, Edge, Container footprint over Bare-Metal & with Kubernetes clusters orchestration as the baseline for Infrastructure. Current challenges include Tempest test spread plus updates to refStack . Board is willing address all aspects from license, legal, object storage, bring in Policies for Open-Infra branding opportunities. We like to hear through Q&A session more ideas like kubernetes-ready-Stack, BMaaS add-ons etc <br />
https://etherpad.opendev.org/p/2020-Wallaby-interop-brainstorming<br />
Add-ons - Ironic, k8s conformnace for Open Infra/OpenStack modules, ceph<br />
k8s ready openstack (k8s over OpenStack)- crate volume (offer cinder or Manila for PVs) - Run Sunobuy tests for eg. over this like VIO using Swift, RHOSP with Cinder, Any OpenStack Distro or hoster OpenStack Service needing k8s conformance<br />
Cloud Provider for OpenStack: https://github.com/kubernetes/cloud-provider-openstack<br />
Octavia Load Balacer for Ingress Controller funtion <br />
<br />
<br />
<br />
Sept 11 <br />
Attendees:<br />
Prakash Ramchandran<br />
Arkady Kanevsky<br />
The old Interop presentation panel not selected for Summit to be moved to forum with minor changes<br />
https://cfp.openstack.org/app/presentations/24735/preview<br />
https://ethercalc.openstack.org/7xp2pcbh1ncb<br />
FYI only <br />
[1] https://wiki.openstack.org/wiki/Forum<br />
[2] https://www.openstack.org/summit/2020/<br />
[3] https://cfp.openstack.org<br />
[4]https://wiki.openstack.org/wiki/Forum/Virtual2020<br />
<br />
Added two slots for InteropWG Oct 30 - Friday 13-14UTC & 16-17 UTC incase we need other presentaions for containers (NFV4 Standards) , BMaaS / Ironic (APIs and consumption by Airship), Container Interop by OpenSatck (Magnum, Zun, Kuryr & Kolla teams)<br />
<br />
OCT 26 Forum plans- https://ethercalc.openstack.org/7xp2pcbh1ncb<br />
- Any inputs to/from Board for new Logo Programs<br />
-Discussions on CNTT/OPNFV Merger and Proposed RA2 using KubeVirt (https://kubevirt.io/) for VMs along with K8s for Containers? <br />
Impact on Interop for VM + COntainer workloads<br />
<br />
August 28th<br />
Prakash<br />
Cancelling No Quoram<br />
<br />
<br />
Aug 14<br />
Attendees: <br />
Prakash Ramchandran<br />
Ghanshyam Mann<br />
Arkady Kanevsky<br />
<br />
<br />
Review Forum submission for Project Updates -Prakash + Mark - not clear what is Project Update to Forum, as we don't have any Project for Interop to report? <br />
Forum Submissiom request completed for Interop WG - Prakash - https://openstackfoundation.formstack.com/forms/oct2020_vptg_survey - Filled in with cross project meetings with Intergated projects , Ironic, Container related projected(Mgnum, Kuryr, Kola, Zun), Tempest<br />
- Process - Horizontal - AT start of PTG can be brought asking PTL to acknowledge schedule..and particpate - https://ethercalc.openstack.org/7xp2pcbh1ncb<br />
- Process - Project Specific - (RefStack , Tempest)<br />
Swift - will depend on polling (working with Allison- Follow up) results and any changes to current Tempest coverage<br />
Intergated projects + add-ons (as is exisiting Logo Programs) - Need Deltas<br />
Ironic - add-ons (BM Logo) - Admin API ? should be kept aways? User needs to inherit Admin permission for Ironic APIs to make it interoperable<br />
Container - Refer Friday Juy 17th meeting notes<br />
Foundation Discussions for Open Infrastructure Logo Programs (Market Place feedback or End users need to bring to table , 4Os plus can add to Interop) - Bring to Panel Discussions<br />
OPNFV-CNTT is merging in LFN as OPNFV LLC (without chnage of name) driven by GSMAA + LFN likely Jon 2021.<br />
CNCF driver Cluster API based testing for Containerized Plane...need watching<br />
Tempest - Test Capabilities limited to Integrated Projects, add-ons like Heat & Designate is within - Its limited to QA with Integrated stack<br />
Open Infra projects have their own CI/CD & Testing<br />
RefStack is broken for Ussuri ? Need to generate a report...or file a bug for Ussuri - Check with Mark?<br />
<br />
Seperate from Proposed Panel Submit under - Open Development https://www.openstack.org/summit/2020/vote-for-presentations#/24735<br />
Follow up on Action Intems from last call - <br />
Operator Survey - Follow up with Allison -Prakash -sent email -<br />
New Guidleines for Victoria - Mark? Await an initial patch or we can take up later Victoria Time frame -TBD<br />
Any feedback on Tags for Interop - Ghanshyam from TC (How to enable tag assert:supports-api-interoperability) - Gmann working with Manila -TBD<br />
- assert:supports-api-interoperability -refer - https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml<br />
<br />
Friday July 31<br />
Prakash Ramchandran<br />
Mark Voelker<br />
Arkady Kanevsky<br />
<br />
Arkady - Everyone can update their user profile for Individual projects<br />
Q? about Interop<br />
About each about projects<br />
Do they use this for <br />
<br />
https://www.openstack.org/user-survey/faq (2014)<br />
interop@openstack.org <br />
<br />
Marketplace needs decouple from Branding? seperate <br />
Decion : All questions should go to Operator and hence Decision makers - Echosystem Operator Survey - Follow up with Allison (Action Intem - Line170-176)<br />
What is there now and response + cc Mark+Ghashyam ...<br />
<br />
Review projects for k8s conformance/Openstack provider APIs<br />
Kourier - https://developers.redhat.com/blog/2020/06/30/kourier-a-lightweight-knative-serving-ingress/<br />
Navisite Cloud Director (NCD) - https://navisite.uservoice.com/knowledgebase/articles/1902673-vcloud-director-api<br />
https://docs.vmware.com/en/VMware-Cloud-Director/index.html<br />
k8s conformance - https://github.com/cncf/k8s-conformance<br />
OpenStack confrmance - https://opendev.org/osf/refstack<br />
OpenStack Integrations testing - https://github.com/openstack/tempest<br />
CI Jobs k8s -https://github.com/kubernetes/test-infra<br />
k8s Openstack Provider - https://github.com/kubernetes/cloud-provider-openstack<br />
<br />
Swift is independent - Do you care about what back end is used with Swift API?<br />
Swift, Swiftstack, Ceph, ECS, ...<br />
<br />
Add-ons<br />
kubernetes - line 103-116(Tempest should have coverage for openstck API which the provider calling)<br />
Community has intrest ? lets wait on this?<br />
Identify requrients ? <br />
kubernets<br />
Ironic - one cycle<br />
<br />
New guidelines for Victoria- Ask PTL/Project Teams if they have anything for 2020.12(?) Guideline:<br />
* Any capabilities in the guidelines that have been depricated inTrain, Ussuri, Victoria<br />
* Any new capabilities that should be added? Must be supported in Train, Ussuri, and Victoria<br />
https://cfp.openstack.org - Project updates for Interop delata... (Add the csfp on Forum and we can knock out 10 slides later - add all 3 names Prakash, Mark & Arkady - Since Ghanshyam is leading Forum sessions<br />
)<br />
Since topics are limited we move the meeting once in two weeks - Next meeting will be on August 14th, 28th...<br />
<br />
Friday July 24th <br />
Open Agedna<br />
Sent email and followed up with <br />
Follow ups<br />
Replied email to Allison/Danny/Interop team.<br />
https://Dell.zoom.us/j/92074400967<br />
<br />
<br />
On Jul 17, 2020, at 6:30 PM, Ghanshyam Mann <gmann@ghanshyammann.com> wrote:<br />
I agree with adding question 5th to user survey (along with existing 2 questions) and adding all 5 to marketplace survey to get their feedback.<br />
<br />
-gmann<br />
<br />
<br />
---- On Fri, 17 Jul 2020 16:30:52 -0500 prakash RAMCHANDRAN <pramchan@yahoo.com> wrote ----<br />
Allison,<br />
In short yes both user-survey & marketplace survey.<br />
1. Based on review of user-survey pointed below, if I understand correctly the questions in them relate to existing deployments , its scale and use cases for OSF decision making.<br />
2. The other question you have posted below is questions related to, if the decision makers used the Logo program guidance formulated by InteropWG and challenges they faced in evaluating offers from commercial providers supporting OpenStack.<br />
We like to add the question 5 from InteropWG to be added to user-survey in case they like to deploy Bare metal & "Kubernetes-ready OpenStack" in their deployments as below or some edited form to bring in as decision makers focus on using facts presented in marketplace by participants in logo program.{5.What would you like to see improve in current Marketplace Logo Program?[a] Do you want to add Interop for bare metal service?[b] Do you want to see a new Logo progam called "Kubernetes-Ready OpenStack"? This designation would basically say "any Kubernetes distribution that supports the OpenStack cloud provider should run on this vendor's OpenStack product"}<br />
<br />
3. Sure you can add question to users-survey regarding Object Storage Swift and the back end drivers they use for maintaining them in-tree. Plus any additional guidelines or logo programs we may need to enhance its usability.<br />
4. Finally, we do want to hear from marketplace participants polling as all questions 1-5 (https://etherpad.opendev.org/p/interop-polling-2020) we have framed for reviving their interests in leveraging and enhancing InteropWG future branding opportunities for OSF.<br />
<br />
Hope this clears the questions you have posed and lets know what we can do to sustain and enhance InteropWG efforts.Like other InteropWG members to pitch-in or a simple +1 reply to let Alison handle the rest.<br />
ThanksPrakash<br />
For InteropWG On Friday, July 17, 2020, 12:23:27 PM PDT, Allison Price <allison@openstack.org> wrote: <br />
<br />
Hi Prakash,<br />
I can help. Going to move some folks to bcc because I have a few questions that I want to clarify with you as I review these additions.<br />
Are you wanting these added to the OpenStack User Survey (openstack.org/user-survey) that we share results on annually? Or are you referring to a different survey? Some of these questions seem more directed towards Marketplace vendors, so I wasn’t sure if there was another survey you were referencing. There are already two Interop questions added in the survey that I have included a screenshot of below.<br />
Some of these questions, we can get the information from other responses in the User Survey, like around Object Storage<br />
<br />
Any additional context will be helpful, including what you’re hoping to understand from the results. Happy to help in any way I can.<br />
Thanks,Allison<br />
<br />
On Jul 17, 2020, at 2:11 PM, Mark Collier <mark@openstack.org> wrote:<br />
adding Allison price, who works on a lot of our survey designs.<br />
Allison, can you take a look?<br />
On Jul 17, 2020, at 1:57 PM, prakash RAMCHANDRAN <pramchan@yahoo.com> wrote:<br />
<br />
Ashlee,<br />
Here is InteropWG suggested questions to OSF Exec team to edit as necessary and provide us feedback from marketplace participants as well include as part of Open Infrastructure Summit 2020 for annual OpenStack 2020 survey.<br />
OpenDev Etherpad<br />
OpenDev Etherpad<br />
<br />
<br />
Since you have been facilitating other Projects to add their questions for poll, here is our efforts to help arrive at what's the direction interopWG need to take based on feedback.<br />
If you have any questions to clarify please reply all as we have been formulating this questions over several meetings and deliberations and have documented the logic etc. in our regular community meetings in https://etherpad.opendev.org/p/interop<br />
<br />
ThanksFor InteropWG Prakash<br />
<br />
<br />
Friday Juy 17th<br />
<br />
Refer to remianing one from last week - went through last weeks AIs.<br />
<br />
Some discussions on Licensing Open Stack Open License (OS OL) for Open Infra projects exception processing<br />
This is part of discussions to be taken to board based on new https://openinfralabs.org/ inclusiaon as new project or seperate org<br />
Described university network use case for Manageability but turns out Interop can not touch admin APIs.<br />
Hence we look at some of the followings<br />
Some discussion of possible interop programs:<br />
<br />
Kuberentes<br />
-----------------<br />
* If I as a vendor want to offer Kuberentes and OpenStack to end users...<br />
* I'll probably provide Kubernetes conformance test suite results (to show I have an interoperable K8s) and RefStack results (to show I have an interoperably OpenStack).<br />
* There's not really anything we (InteropWG) need to do for this use case...it's covered by the existing tools/programs.<br />
* If I as a vendor want to offer a product that runs OpenStack in Kubernetes...<br />
* Again, there's not a lot for us to do here: if OpenStack is what is exposed to the end user, then I simply need to run RefStack against that OpenStack to show compliance with Powered guidelines<br />
* If I as a vendor want to provide an OpenStack offering that provides all the necessary API's and capabilities needed by the OpenStack cloud provider for K8s (K8s on top of OpenStack):<br />
* https://github.com/kubernetes/cloud-provider-openstack<br />
* Are all these API's coverged in the OpenStack Powered program today? ¯\_(ツ)_/¯<br />
* Should we have a new logo program (let's call it "Kubernetes-Ready OpenStack" for the moment) that lets vendors certify that their product is interoperable with the OpenStack cloud provider?<br />
* This could be done with a new guideline document that includes tests & designated sections of code specifically for the API's that the OpenStack cloud provider calls.<br />
* This designation would basically say "any Kubernetes distribution that supports the OpenStack cloud provider should run on this vendor's OpenStack product"<br />
* How many vendors would be interested in this? - Can we add his to poll question? +1+1+1<br />
<br />
July 10th<br />
<br />
AI-03 - (for Core + Add-ons for OpenStack Integrated Projects) - Can you volunteer to add tag assert:supports-api-interoperability to your projects?<br />
Any comments on what Projects need to do to claim this based on 2020.06 - interop - https://opendev.org/osf/interop/src/branch/master/2020.06.json <br />
<br />
- We should send email notcies to marketplace participants to update their distros/hsoted solutions/public cloud etc. - OSF foundation should havd the list to send.<br />
- We should send the Quationnair as poll to marketplace and other reevant partciapnts (openirrastructure.labs/ OPen Infrastucuture)<br />
<br />
Can someone take a crack at documenting how to for one project like nova compute api does now?<br />
- assert:supports-api-interoperability<br />
Need guidelines standardization for interoperability<br />
- Version & Discovery should be consistant despite variations in flow <br />
AI-04 - Seeking volunteers to maintain - Refstack - https://opendev.org/osf/refstack<br />
- Maintenance of refstack - Ganesh Hiregaudar (VMWare) + Pavan Dikonkar (team) and/or University/Student support.<br />
<br />
<br />
AI-05 - Can someone volunteer to present at next Interop meeting Friday 3rd at 17 UTC (10 AM PDT) - https://github.com/cncf/k8s-conformance<br />
Presenter to be identified.<br />
??*<br />
*. Ideas for new logo programs to propose to Board working with TC<br />
- Any legal disclaimers or change required - Conformance or validation vs. compliance?<br />
- Revising Object Storage Logo for Swift Compliance (For Platinum/Gold partners)<br />
- Bare Metal Ironic - Independent then how will it release and maintain Interop in Victoria? - https://releases.openstack.org/victoria/index.html - cycle-with-intermediary? likely 3 releases / when will we introduce interop (assert interop)<br />
https://releases.openstack.org/reference/process.html <br />
- Container Projects (Zun, Magnum, Kola, Kuryr) - Container projects - How do they follow release goverance https://governance.openstack.org/tc/reference/projects/release-management.html / how will we introduce k8s conforamce? how with or without tempest?<br />
- Airship Cloud to StarlingX Edge Interop, Can we introduce k8s conformance - what is anyway, any tests - <br />
- kubernetes Conformance for OpenStack & Open Infra Projects. - Where is CI/CD in CNCF for k8s conformance- Can we borrow or we already have in Tempest for Zun?<br />
- Can Serchlight - Resource Type {OS::<br />
<br />
Next Friday - July 3rd - Meeting Canceled due to July 4 long week end in USA<br />
<br />
<br />
Friday June 26th<br />
<br />
1.Interop Ussuri Guidelines established - documented the details in here and merged.<br />
https://storyboard.openstack.org/#!/story/2007510<br />
<br />
https://storyboard.openstack.org/#!/story/2007509<br />
<br />
<br />
(Add above your suggestions)<br />
level 2 Q&A<br />
1. Do you use data on add-on programs in the OpenStack Marketplace?<br />
1.1 If yes which ones?<br />
<br />
<br />
<br />
2. To supersede or abandon this.https://blueprints.launchpad.net/refstack/+spec/interop-2020.06 - Ghanshyam or Mark - please confirm<br />
AI-01 - GM to update/close? launchpad item - https://blueprints.launchpad.net/refstack/+spec/interop-2020.06<br />
With following two references to storyboard for all API guidelines for 2020.06.json.<br />
https://storyboard.openstack.org/#!/story/2007509<br />
https://storyboard.openstack.org/#!/story/2007510<br />
<br />
3. Marketplace participants <br />
AI-02 Regards to Survey questions - https://storyboard.openstack.org/#!/story/2007511<br />
<br />
6/26/2020 - AT todays Interop call it was decided to add following questions and is being circulated for updates via openstack-discuss list.<br />
<br />
1. Do you use OpenStack Marketplace data for your decision on use of OpenStack Cloud? - User Survey/Operator Survey<br />
2. Do you look for at Interoperability OpenStack Powered Logo when selecting an OpenStack product reports available to you on different offerings in Marketplace portal? -User Survey/OperatorSurvey<br />
3. If you offer OpenStack Cloud do you use the OpenStack logo programs.? -Ecosystem Survey/Opertor Survey<br />
4. If you are using Object Storage for your cloud do you use Swift? - User Survey/Operator Survey<br />
5.What would you like to see improve in current Marketplace Logo Program? -Ecosystem Survey/Operator Survey<br />
[a] Do you want to add Interop for bare metal service?<br />
[b] Do you want to see a new Logo progam called "Kubernetes-Ready OpenStack"? This designation would basically say "any Kubernetes distribution that supports the OpenStack cloud provider should run on this vendor's OpenStack product"<br />
<br />
4. The Content & Procedure of Survey to be identified and agreed<br />
- How to send message to Vendors , Distro's, Hosting Partners and other Marketplace participants to test for Logo updates for 2020.06 Ussuri cycle - Consistency in meeting times on irc and websites <br />
- Update site for logo - https://www.openstack.org/brand/interop/<br />
- update site for irc meeting time - https://refstack.openstack.org/#/about#about <br />
<br />
5. Implementing updates to project governance - https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml<br />
How to enable tag assert:supports-api-interoperability (for Core + Add-ons for Integrated Projects)<br />
tags:<br />
- tc:approved-release<br />
- starter-kit:compute<br />
- vulnerability:managed<br />
- assert:follows-standard-deprecation<br />
- assert:supports-upgrade<br />
- assert:supports-rolling-upgrade<br />
- assert:supports-accessible-upgrade<br />
- stable:follows-policy<br />
- assert:supports-api-interoperability<br />
<br />
Chair / Interop WG (Prakash Ramchandran)<br />
Co-Chairs (Mark V.Voelker & Ghanshyam Maan)<br />
Rep. from Board (Arkady Kanevsky)<br />
<br />
<br />
Friday 19th <br />
Meeting cancelled<br />
<br />
===================================<br />
Please use thi bride for PTG June 1 : monday 6/1/2020 **************************************************************************<br />
Please join Interop WG meeting Jun1 UTC 13-15 (2 hrs) <br />
Austin room zoom link - https://www.openstack.org/ptg/rooms/austin <br />
**********************************************************************************************<br />
=======================================<br />
<br />
Management Meetings (Master for all refrences)<br />
Refere to link for technical details for 2020.06 guideliens - https://etherpad.opendev.org/p/interop2020 / <br />
Meeting Bridge : https://zoom.us/j/914761969 (NA/EU -PDT Fridays 10 AM) 10-10.45 Please use?<br />
Meeting Bridge: : (APJ -BJT Fridays 9 AM ) - APJ Bridge<br />
<br />
Next Meeting<br />
May 29th - PDT 10.00 AM Bridge will try both<br />
https://meetpad.opendev.org/Interop-WG-weekly-meeting (Sorry this did not work) <br />
https://Dell.zoom.com/wc/join/99829924353 <br />
< password: 101045 **********************************************************************************************<br />
<br />
Attendees<br />
Prakash<br />
Ghanshyam<br />
Mark (late)<br />
Topics<br />
1. Meetpad does not work as expected /Decided that we will use Zoom instead <br />
<br />
2. Nova - compute api testing<br />
https://refstack.openstack.org/#/results/d950f90f-fcc9-4216-962e-2bd0ce4b6fea<br />
We just pickedup NOT PASSED in "next " to see why compute list failure show up in Refstack when the regular nova is passing it?<br />
stack@ubuntu-os-host:~/tempest$ tempest run --regex tempest.api.compute.servers.test_list_server_filters.ListServerFiltersTestJSON.test_list_servers_filtered_by_ip<br />
Make sure the Usuri has cirros image to test<br />
<br />
3. Tasks to complete for approving guidelines for 2020.06 by June 10th<br />
a. Verify all changes<br />
Reviewed relevant APIs<br />
Identity (Keystone)<br />
https://docs.openstack.org/api-ref/identity/v3/index.html#<br />
Comute + Image (Nova, Glance)<br />
https://docs.openstack.org/api-ref/compute/<br />
https://docs.openstack.org/api-ref/image/v2/index.html<br />
Networking (Neutron)<br />
https://docs.openstack.org/api-ref/network/v2/index.html<br />
Block Storage - Cinder<br />
https://docs.openstack.org/api-ref/block-storage/v3/index.html<br />
Object Store (Swift)<br />
https://docs.openstack.org/api-ref/object-store/<br />
<br />
add-ons<br />
Orchestartion<br />
https://docs.openstack.org/api-ref/orchestration/v1/index.html<br />
DNS<br />
https://docs.openstack.org/api-ref/dns/<br />
<br />
b. Clean up the flagged tests<br />
<br />
Myay 29th - AsiaPacifc meeting 9 AM BJT<br />
Dr Li Kiai<br />
Prakash Ramchandran<br />
Tried - https://meetpad.opendev.org/Interop-WG-weekly-meeting (Failed)<br />
Tried - , https://Dell.zoom.com.cn/j/94921799892?pwd=R3RESHVQWWl6WC8vTUcvUEROTW9sUT09 - Failed<br />
<br />
The Audio did not work and decides to abnndon but send info to marketing@99cloud.net for follow up for adding topics to<br />
https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020<br />
<br />
<br />
Friday May 22<br />
Prakash Ramchandran<br />
Mark Voelker<br />
<br />
Request email to community for guidelines review<br />
<br />
Interop WG approvel sceduled for June 11 - https://wiki.openstack.org/wiki/Governance/Foundation#OpenStack_Board_of_Director_Meetings<br />
<br />
<br />
Friaday May 15th<br />
Prakash Ramchandran<br />
Kanevsky Arkady<br />
Ghanshyam Mann<br />
<br />
<br />
Ussuri Release announcement<br />
http://lists.openstack.org/pipermail/openstack-announce/2020-May/002035.html<br />
<br />
Reviewing Release Notes for API changes<br />
https://review.opendev.org/#/c/722137/<br />
<br />
TODO:<br />
Ghanshyam to remove the deprecated tests from new guidlines and add a patch<br />
https://review.opendev.org/#/c/728564/<br />
Review 'Advisory' with Mark and apply new patch<br />
Prakash to check for new 'Required' capabilities from Ussuri release.<br />
Send mail to PTL on openstack-discuss about new core capabilities: Core + adds-on<br />
Review microversion(or any API versioning mechanism) is deffered to post release.<br />
<br />
<br />
Review Next in Refstck for test passings<br />
https://refstack.openstack.org/#/results/d950f90f-fcc9-4216-962e-2bd0ce4b6fea<br />
<br />
<br />
<br />
<br />
Friday May 8<br />
Prakash Ramchandran<br />
Mark Voelker<br />
<br />
Worked through core and add-ons reviiewing scores and API and finally decided to commit Patch 4.<br />
Mark Added Prakash for +2 Interop WG Reop<br />
Prakash Added for Arkady +2 InteropWG Repo<br />
We still will retaning Egle Sigler for the work she has done and hope she may return infuture.<br />
For now Draft is mearged for testing.<br />
Once we have few tests run by current or any new Marketplace Distro or Vendor offerings <br />
Plest test for 2020.06 draft and provide feedback...over next few weeks<br />
x<br />
<br />
Board Approval request? - Got email from Alan scheduling it for June<br />
planning for PTG<br />
https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020<br />
<br />
Core Scoring - Cutoff - 74 of 102<br />
A - Atomic - 6<br />
U - Used by Clients (Nova, Neutron etc.) - 10<br />
C - Complete - 10<br />
W - Widely Deployed - (muliple Proviers) - 8<br />
D - Discoverable (Service through keystone and introspection) - 8<br />
D - Documented - 8<br />
F - Foundation - Tests for uinversl Dependencies - 9<br />
F - Future Direction (TC recommended for verions & compatible) - 11<br />
P - Proximity reletaed to Coe - 8<br />
S - Stable - 9<br />
S - Sticky -Must pass per release - 9<br />
U - Used by Tools of External Providers like Rackspace, RightScale, JCloud - 6<br />
<br />
<br />
Add-ons scorinng<br />
Cutoff 60<br />
AUCDDF<br />
A - Atmoic - 6<br />
U - Used by Clients - 10<br />
C - Complete -10<br />
D -Discoverable -8<br />
D - Documented - 8<br />
F- Future -11<br />
<br />
Reviewed relevant APIs<br />
Identity (Keystone)<br />
https://docs.openstack.org/api-ref/identity/v3/index.html#<br />
Comute + Image (Nova, Glance)<br />
https://docs.openstack.org/api-ref/compute/<br />
https://docs.openstack.org/api-ref/image/v2/index.html<br />
Networking (Neutron)<br />
https://docs.openstack.org/api-ref/network/v2/index.html<br />
Block Storage - Cinder<br />
https://docs.openstack.org/api-ref/block-storage/v3/index.html<br />
Object Store (Swift)<br />
https://docs.openstack.org/api-ref/object-store/<br />
<br />
add-ons<br />
Orchestartion<br />
https://docs.openstack.org/api-ref/orchestration/v1/index.html<br />
DNS<br />
https://docs.openstack.org/api-ref/dns/<br />
<br />
<br />
Tempest for Testing APIs with idempotetnt_id for tests with 1-to-may releations / API testing may use multiple ids in guidelines file<br />
https://opendev.org/openstack/tempest/src/branch/master/tempest/api/compute/test_versions.py<br />
<br />
<br />
Friday May 1<br />
<br />
eed few decisions <br />
1. Should-add ons for Heat and Designate be in separate file like 2020.06.json or 2020.06.nn.json - keep it seperate but can submit as sinle patch<br />
Past guidelines: https://opendev.org/openstack/interop/src/branch/master/add-ons/<br />
Chat notes for Mark for creating add-ons for 2020 for orchestartion & dns<br />
wget https://github.com/openstack/interop/blob/master/add-ons/orchestration.2019.11.json<br />
Or rather: wget https://github.com/openstack/interop/blob/master/add-ons/orchestration.2019.11.json<br />
<br />
Complete 3rd Patch<br />
Done - https://review.opendev.org/722137 [Call for content review]<br />
<br />
Please add your name for review if you have time, we need few +1s and two +2's<br />
Mark & Egle can review and give +2<br />
All others including Arkady, Ghansyam, Dr Likai & Mohammad can provide a +1 after reviewing for us to close with zero or more patches as needed based on review.<br />
<br />
<br />
2. If separate can some one volunteer or should I add to single file and we filter out test<br />
results for logo mark as part of validations.<br />
The Process used to be Next in Refstack Window lie<br />
https://refstack.openstack.org/#/results/d950f90f-fcc9-4216-962e-2bd0ce4b6fea<br />
So pre-approval testing was done through next json file.<br />
Since we are short on time have decided to lump in basic plus add-ons as one patch and after code review we will merge and let tests be done with pending board approval.<br />
But will ask for approval at next Baord meeting<br />
<br />
3. Do we review in meeting and make a call and then send to opestack-discuss mail for confirming release changes for needed 80 + 18 current api scenario's (Compute + Storage) or other way round?<br />
This is answered in 2 above as we are short circuting the process, as all we cars is user level APIs for respective modules and scores included from 2019.11.json gudieleines<br />
<br />
4. Plans for beyond June In Victoria for interop.<br />
There are two ways to support Edge Cloud logos in OpenStack<br />
1.Use hierarchial Openstack with Central and Distributed nodes with different stack components (specifically Glance matser and Glance with replication for local availability of images to boot for Edge Applications per tenant)<br />
2. Federated Edges with Stacks as they need to run OpenStack at scale individual locations need<br />
<br />
How to do this and what APIs additions this brings in, we willreview next week.<br />
1. <br />
<br />
<br />
<br />
<br />
5. Other suggestions from Asia Pacific team.<br />
<br />
Check this out for Compute<br />
https://etherpad.opendev.org/p/interop2019<br />
or<br />
https://refstack.openstack.org/#/results/d950f90f-fcc9-4216-962e-2bd0ce4b6fea<br />
See if can get something for 2020.06 without approval?<br />
<br />
<br />
<br />
<br />
API-Docs - https://docs.openstack.org/api-ref/<br />
US/EU<br />
APJ <br />
<br />
Friday 24, April 2020 / 10 AM PDT<br />
Present<br />
Prakash Ramchandran<br />
Arkady Kanevsky<br />
Ghanshyam Mann<br />
<br />
Topic:<br />
To Review : https://blueprints.launchpad.net/refstack/+spec/interop-2020.06 (new bp reday for review -refer tech work link at the top)<br />
Fix metadat -> 2020..06 to 2020.06 -Arkady (Done)<br />
Mark's reviews & questions - discuss and fix online<br />
Add DNS? combine or seperate?<br />
<br />
Add Orchestration? combine or seperate?<br />
Drop Ceilometer? ( No replacers with Aodh or any telemetry modules?) - For now dropping out, will check with Mark/Mohammad for add-on for telemetry<br />
<br />
Sure this is draft not approved, we can correct. - fixed removed approved to draft<br />
<br />
Also any other thoughts on alternate orchestration based on kubernetes api as sub for heat orchestration?<br />
TBD - for now assiging heat orchestartion work to Mark if he can volunteer<br />
<br />
Heat creates VM stacks and k8s for crio based for containers or pods (? stacks not sure, may be clusters+pods/+servcies).<br />
<br />
Also openstack control plane using containers as CAPO provider.<br />
<br />
Let's do review these crazy possibilities too.<br />
What was the logic earlier in 2019.11 to keep DNS and Orchestration out of core?<br />
Comparing the flexibility offered by k8s to use cluster DNS as a "Service" over coreDNS as internal name registry for PODs.<br />
In OpenStack case we have mixup between Glance rgeistry versus designate versus Heat and may need relook as how to simplify, if we really want to make it flexible.<br />
<br />
Revise the story2000-7507,-7509,-7510<br />
Review OpenStack Controle Plane in CAPI - <br />
Review Image needed for container based Openstack Controller in SCI Image builder - https://image-builder.sigs.k8s.io/capi/providers/openstack.html<br />
<br />
Friday 24, April 2020 / 9 AM BJT<br />
Present<br />
Prakash Ramchandran<br />
Dr Li Kai<br />
<br />
How do we handle new Profiles for NFV, Edge, Hybrid Cloud, HPC<br />
We shoul look at Contianer based OpenStack Control plane as a target.<br />
This will also mean we need an image that we can use for different mdules or service_types as in microservcies<br />
We can review Adjecensies as how Airship uses OpenStack Control plane and workloads - Refer <br />
https://etherpad.opendev.org/p/interop2020<br />
Zun APIs for Capsules/PoDs may be an answer along with Magnum or kuryr<br />
https://wiki.openstack.org/wiki/Kuryr<br />
We will see if add-ons like orchestartion & desgnate , we can add for Zun...<br />
<br />
<br />
Friday 17, April 2020 /10 AM PDT<br />
Prakash Ramchandran<br />
Mark T. Voelker<br />
Arkady Kanevsky<br />
Topic:<br />
Discovering what to do now and beyond in 2020<br />
<br />
Minutes:<br />
Discussed on CAPI over OpenStack API for K8s based cluster<br />
Whay not do Direct in OpenStack through Zun or OoK like Airshi? <br />
<br />
Friday 10 , April 2020 /10 AM PDT<br />
Attendees: Prakash Ramchandran<br />
Mark T. Voelker<br />
Mohammad Naser<br />
Topic: <br />
Prakash started working on Train Refstack and created a BP for Train<br />
https://blueprints.launchpad.net/refstack/+spec/refstack-train-api - Superseded as suggeted by Mark.<br />
story2007510 -on hold<br />
story2007507 -on hold<br />
story2007509 -on hold<br />
Define the Specs: INPROGRESS (will be revised based on new bp/2020.06 refer next week entry)<br />
Approve the Specs: TODO<br />
Implement the Specs for One Vendor: TODO<br />
Minutes: <br />
2019.06 does cover Train but not Usuri [1], 2019.11 covers both [2] <br />
[1] https://opendev.org/openstack/interop/src/branch/master/2019.06.json#L75<br />
[2] https://opendev.org/openstack/interop/src/branch/master/2019.11.json#L75<br />
More discussions on covering Hybrid and Multi-cloud<br />
<br />
Friday 10. April 20 / 9 AM BJT (6.30 PDT Thu) -APJ bridge<br />
Attendees: Prakash Ramchandran<br />
Dr Li Kai <br />
https://Dell.zoom.com/wc/join/94921799892 (APJ -BJT Fridays 9 AM ) - APJ Bridge Password 200011<br />
Topic: Briefing APJ partcpants what was presented to Board 0n April 4 - https://wiki.openstack.org/wiki/Governance/Foundation/14April2020BoardMeeting<br />
Feedback needs to adddress new areas<br />
Minutes: <br />
Sugessions from Dr Li Kai for looking at Edge & Hybrid CLoud Interoperability<br />
<br />
Friday 3, April 2020<br />
Attendees: Prakash Ramchandran<br />
Mark T. Voelker<br />
Ghanshyam Maan<br />
Topic:<br />
Where to Start and What to do?<br />
Reviwe RefStack, Tempest and Interop<br />
Minutes: <br />
Show we expand the Program to cover NFV, Containers etc. - First get to do minimum for next release<br />
Can we look at K8s compliance for OpenStack Projects. - May be not since Source codes may not be owned by or Licenses my differ<br />
Think out-of box for other compliance + Compatibility logo marks like Oen Infra Logog Mark etc.<br />
Prakash to review Refstack & Tempest<br />
Prakash Preparing slides for Board for rebooting InteropWG -Shared tentative Slides</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Release_Naming/Z_Proposals&diff=180324Release Naming/Z Proposals2022-01-11T16:50:13Z<p>Arkady: /* Proposed Names */</p>
<hr />
<div>=== Z Release Naming ===<br />
<br />
According to the [https://governance.openstack.org/tc/reference/release-naming.html#release-naming-process Release Naming Process], this page will contain a list of nominated names for the Z release of OpenStack. We will accept nominations until Jan 24, 2022, 23:59:59 UTC.<br />
<br />
=== Release Name Criteria ===<br />
<br />
The way we do release naming has changed slightly from past releases. Rather than restricting name candidates to the geographic region where the Summit is held, we will now accept any name a member of the community would like to propose, as long as the name begins with the appropriate letter. The current release naming criteria are defined in [https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria Release Name Criteria]<br />
<br />
Names that do not meet [https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria Release Name Criteria] but otherwise sound really cool should be added to a separate section of the wiki page and the [https://governance.openstack.org/tc/ OpenStack Technical Committee] may make an exception for one or more of them to be considered in the Condorcet poll. The naming official is responsible for presenting the list of exceptional names for consideration to the [https://governance.openstack.org/tc/ OpenStack Technical Committee] before the poll opens.<br />
<br />
=== Proposed Names ===<br />
<br />
Please list names with any relevant links for more details. If there is a particular reason you think a name would be a good choice, please add a brief rationale with the name.<br />
* [https://en.wikipedia.org/wiki/Zagreb Zagreb- capital of Croatia]<br />
* [https://en.wikipedia.org/wiki/Zebra Zebra]<br />
* [https://en.wikipedia.org/wiki/Zenith Zenith]<br />
* [https://en.wikipedia.org/wiki/Zeta Zeta]<br />
* [https://en.wikipedia.org/wiki/Zeus Zeus]: "king of the gods" or "god of the sky, lightning, thunder, law, order, justice".<br />
* [https://matrix.fandom.com/wiki/Zion Zion]<br />
* [https://villains.fandom.com/wiki/Jean-Baptiste_Emanuel_Zorg Zorg]: Jean-Baptiste Emanuel Zorg<br />
* Zomicron<br />
* [https://en.wikipedia.org/wiki/Zorro Zorro]: A masked hero who defends the commoners against villains<br />
* [https://villains.fandom.com/wiki/Zurg Zurg]: Toy Story<br />
* [https://en.wikipedia.org/wiki/Zachary Zachary]: A biblical character<br />
* [https://en.wikipedia.org/wiki/Zorba_(dog) Zorba]: The heaviest and longest dog in the world<br />
* [https://en.wikipedia.org/wiki/Zatanna Zatanna]: A fictional superhero fighting for justice<br />
* Zoo<br />
* Zoom: Feature in graphical edition software and object use to close up on a remote object.<br />
* [https://en.wikipedia.org/wiki/Zoidberg Zoidberg]<br />
* [https://starcraft.fandom.com/wiki/Zerg Zerg]<br />
* [https://en.wikipedia.org/wiki/Zen Zen]<br />
* [https://en.wikipedia.org/wiki/Zaphod_Beeblebrox Zaphod]<br />
<br />
=== Proposed Names that do not meet the criteria ===<br />
*<br />
<br />
<br />
[[Category:Releases]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=179980Governance/InteropWG2021-11-11T17:05:29Z<p>Arkady: updated leadership team</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" that is supported by all implementations as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/Lexicon.html Terms Definition]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/CoreDefinition.html 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://opendev.org/openinfra/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/DesignatedSections.html10 Designed Sections Principles] (board approved December 2014)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/GovernanceProcess.html Interop Working Group Governance:]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/2021A.html Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/next.json draft of the next OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://docs.opendev.org/openinfra/interop/latest/guidelines/index.html OpenStack Powered and Add-on Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines Source Directory of all previous OpenStack Powered Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/ Source Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since September 23 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Thursday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Thursday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/102303/martin-kopec Martin Kopec] (chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=179979Governance/InteropWG2021-11-11T17:02:15Z<p>Arkady: /* Current Committee Leaders */</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" that is supported by all implementations as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/Lexicon.html Terms Definition]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/CoreDefinition.html 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://opendev.org/openinfra/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/DesignatedSections.html10 Designed Sections Principles] (board approved December 2014)<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/GovernanceProcess.html Interop Working Group Governance:]<br />
# [https://docs.opendev.org/openinfra/interop/latest/process/2021A.html Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines/next.json draft of the next OpenStack Powered guideline]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://docs.opendev.org/openinfra/interop/latest/guidelines/index.html OpenStack Powered and Add-on Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/guidelines Source Directory of all previous OpenStack Powered Guidelines]<br />
### [https://opendev.org/openinfra/interop/src/branch/master/add-ons/guidelines/ Source Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since September 23 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Thursday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Thursday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Martin Kopec] (chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=179467Governance/InteropWG2021-09-17T23:36:47Z<p>Arkady: move meeting time to Th noon EST</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" that is supported by all implementations as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json draft of the next OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since September 23 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Thursday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Thursday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178954Governance/InteropWG2021-07-02T23:29:59Z<p>Arkady: cleanup</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" that is supported by all implementations as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json draft of the next OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since July 9 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 2pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/14pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 2pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178953Governance/InteropWG2021-07-02T23:19:47Z<p>Arkady: </p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json draft of the next OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since July 9 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 2pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/14pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 2pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178952Governance/InteropWG2021-07-02T23:18:48Z<p>Arkady: replaced symbolic links</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.2020.11.json Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.2020.11.json Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.2020.11.json Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json (draft of the next OpenStack Powered guideline)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since July 9 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 2pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/14pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 2pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178951Governance/InteropWG2021-07-02T23:16:15Z<p>Arkady: </p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/2020.11.json Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/orchestration_current_guideline Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/dns_current_guideline Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system_current_guideline Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json (draft of the next OpenStack Powered guideline)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since July 9 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 2pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/14pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 2pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178950Governance/InteropWG2021-07-02T20:50:26Z<p>Arkady: meeting time change</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/current_guideline Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/orchestration_current_guideline Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/dns_current_guideline Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system_current_guideline Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json (draft of the next OpenStack Powered guideline)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since July 9 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 2pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/14pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 2pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178949Governance/InteropWG2021-07-02T15:31:36Z<p>Arkady: /* Important Artifacts */</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/current_guideline Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/orchestration_current_guideline Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/dns_current_guideline Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system_current_guideline Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json (draft of the next OpenStack Powered guideline)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178948Governance/InteropWG2021-07-02T15:31:15Z<p>Arkady: /* Important Artifacts */</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/current_guideline Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/orchestration_current_guideline Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/dns_current_guideline Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system_current_guideline Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json (draft of the next OpenStack Powered guideline)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178947Governance/InteropWG2021-07-02T15:30:43Z<p>Arkady: /* Important Artifacts */</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/current_guideline Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/orchestration_current_guideline Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/dns_current_guideline Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system_current_guideline Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json (draft of the next OpenStack Powered guideline)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration.next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns.next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system.next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
#### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178946Governance/InteropWG2021-07-02T15:29:49Z<p>Arkady: /* Important Artifacts */</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/current_guideline Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/orchestration_current_guideline Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/dns_current_guideline Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system_current_guideline Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json (draft of the next OpenStack Powered guideline)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration_next.json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns_next.json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system_next.json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
#### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178945Governance/InteropWG2021-07-02T15:27:42Z<p>Arkady: /* Important Artifacts */</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/current_guideline Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/orchestration_current_guideline Current Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/dns_current_guideline Current DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system_current_guideline Current Shared File System add-on program guideline (Manila)]<br />
## Draft of the Next Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json (draft of the next OpenStack Powered guideline)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration_next_json draft of the next Orchestration add-on program guideline (Heat)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns_next_json draft of the next DNS add-on program guideline (Designate)]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system_next_json draft of the next Shared File System add-on program guideline (Manila)]<br />
## Previous Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines Directory of all previous OpenStack Powered Guidelines]<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
#### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/ Directory of all previous Add-on Guidelines]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178944Governance/InteropWG2021-07-02T15:26:13Z<p>Arkady: /* Important Artifacts */</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/current_guideline Current OpenStack Powered guideline]<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/orchestration_current_guideline] Current Orchestration add-on program guideline (Heat)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/dns_current_guideline] Current DNS add-on program guideline (Designate)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system_current_guideline] Current Shared File System add-on program guideline (Manila)<br />
## Draft of the Next Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json ] (draft of the next OpenStack Powered guideline)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration_next_json] draft of the next Orchestration add-on program guideline (Heat)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns_next_json] draft of the next DNS add-on program guideline (Designate)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system_next_json] draft of the next Shared File System add-on program guideline (Manila)<br />
## Previous Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines] Directory of all previous OpenStack Powered Guidelines<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
#### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/] Directory of all previous Add-on Guidelines<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178943Governance/InteropWG2021-07-02T15:25:36Z<p>Arkady: update pointers to all guidelines</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## Current Guidelines<br />
### [https://opendev.org/osf/interop/src/branch/master/current_guideline] Current OpenStack Powered guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/orchestration_current_guideline] Current Orchestration add-on program guideline (Heat)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/dns_current_guideline] Current DNS add-on program guideline (Designate)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/shared_file_system_current_guideline] Current Shared File System add-on program guideline (Manila)<br />
## Draft of the Next Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines/next.json ] (draft of the next OpenStack Powered guideline)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/orchestration_next_json] draft of the next Orchestration add-on program guideline (Heat)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/dns_next_json] draft of the next DNS add-on program guideline (Designate)<br />
### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/shared_file_system_next_json] draft of the next Shared File System add-on program guideline (Manila)<br />
## Previous Guideline<br />
### [https://opendev.org/osf/interop/src/branch/master/guidelines] Directory of all previous OpenStack Powered Guidelines<br />
#### [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03] [https://opendev.org/osf/interop/src/branch/master/guidelines2015.03.rst 2015.03.json JSON] Example of 2015.03 guidelines in RST and JSON forms<br />
#### [https://opendev.org/osf/interop/src/branch/master/add-ons/guidelines/] Directory of all previous Add-on Guidelines<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178942Governance/InteropWG2021-07-02T14:41:13Z<p>Arkady: Arkady no longer on the baord</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178941Governance/InteropWG2021-07-02T14:40:15Z<p>Arkady: board approved process</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Interop Working Group Process] (board approved June 2021)<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on OFTC IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack], [https://opendev.org/osf/refstack-client Refstack-client] and [https://opendev.org/x/ansible-role-refstack-client ansible-role-refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178676Governance/InteropWG2021-06-03T14:56:33Z<p>Arkady: </p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Draft Interop Working Group Process] ([https://opendev.org/osf/interop/src/branch/master/doc/source/process/2017A.rst current process])<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178675Governance/InteropWG2021-06-03T14:55:07Z<p>Arkady: </p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://opendev.org/osf/interop/src/branch/master/doc/source/process/2021A.rst Draft Interop Working Group Process] (current process is at https://opendev.org/osf/interop/src/branch/master/doc/source/process/2017A.rst )<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178674Governance/InteropWG2021-06-03T14:53:24Z<p>Arkady: added pointer to 2021 process and removed old process nomenclature</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/2021A.rst Draft Interop Working Group Process] (current process is at https://github.com/openstack/interop/blob/master/doc/source/process/2017A.rst )<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178534Governance/InteropWG2021-05-21T19:50:07Z<p>Arkady: changed meetup to point to interop etherpad</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/2017A.rst Interop Working Group Process]<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/interop at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Process Cycles ==<br />
<br />
Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to Interop Working Group but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant). <br />
<br />
See [https://github.com/openstack/interop/blob/master/doc/source/process/ProcessCycles.rst Process Cycles]<br />
<br />
The current cycle is named the '''''Scale Cycle'''''.<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178370Governance/InteropWG2021-04-30T16:55:09Z<p>Arkady: fixed time of the meetings</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/2017A.rst Interop Working Group Process]<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since April 30 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/Interop-WG-weekly-meeting at 4pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/16pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 4pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Process Cycles ==<br />
<br />
Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to Interop Working Group but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant). <br />
<br />
See [https://github.com/openstack/interop/blob/master/doc/source/process/ProcessCycles.rst Process Cycles]<br />
<br />
The current cycle is named the '''''Scale Cycle'''''.<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178281Governance/InteropWG2021-04-26T15:51:29Z<p>Arkady: updating meeting time</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/2017A.rst Interop Working Group Process]<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since May 1 2021, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/Interop-WG-weekly-meeting at 5pm UTC every Friday<br />
Convert time to your timezone: https://mytime.io/15pm/UTC<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 5pm UTC on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Process Cycles ==<br />
<br />
Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to Interop Working Group but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant). <br />
<br />
See [https://github.com/openstack/interop/blob/master/doc/source/process/ProcessCycles.rst Process Cycles]<br />
<br />
The current cycle is named the '''''Scale Cycle'''''.<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178192Governance/InteropWG2021-04-19T14:08:45Z<p>Arkady: updated pointer to latest process document 2017A</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/2017A.rst Interop Working Group Process]<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since June 2020, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/Interop-WG-weekly-meeting at 10 AM PST every friday<br />
See 10 AM in your timezone: https://mytime.io/10am/PST<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 10 AM PST on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Process Cycles ==<br />
<br />
Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to Interop Working Group but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant). <br />
<br />
See [https://github.com/openstack/interop/blob/master/doc/source/process/ProcessCycles.rst Process Cycles]<br />
<br />
The current cycle is named the '''''Scale Cycle'''''.<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178191Governance/InteropWG2021-04-19T13:11:20Z<p>Arkady: </p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/2015A.rst Interop Working Group Process]<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since June 2020, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/Interop-WG-weekly-meeting at 10 AM PST every friday<br />
See 10 AM in your timezone: https://mytime.io/10am/PST<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 10 AM PST on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Process Cycles ==<br />
<br />
Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to Interop Working Group but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant). <br />
<br />
See [https://github.com/openstack/interop/blob/master/doc/source/process/ProcessCycles.rst Process Cycles]<br />
<br />
The current cycle is named the '''''Scale Cycle'''''.<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi Goutham Pacha Ravi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann Ghanshyam Mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178190Governance/InteropWG2021-04-19T13:10:23Z<p>Arkady: updated co-chair for the WG</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/2015A.rst Interop Working Group Process]<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since June 2020, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/Interop-WG-weekly-meeting at 10 AM PST every friday<br />
See 10 AM in your timezone: https://mytime.io/10am/PST<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 10 AM PST on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Process Cycles ==<br />
<br />
Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to Interop Working Group but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant). <br />
<br />
See [https://github.com/openstack/interop/blob/master/doc/source/process/ProcessCycles.rst Process Cycles]<br />
<br />
The current cycle is named the '''''Scale Cycle'''''.<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/35705/goutham-pacharavi] (co-chair)<br />
* [https://www.openstack.org/community/members/profile/6461/ghanshyam-mann] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178034Governance/InteropWG2021-03-30T21:23:03Z<p>Arkady: </p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/2015A.rst Interop Working Group Process]<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since June 2020, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/Interop-WG-weekly-meeting at 10 AM PST every friday<br />
See 10 AM in your timezone: https://mytime.io/10am/PST<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 10 AM PST on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop.<br />
Agenda is also posted to Etherpad: https://etherpad.opendev.org/p/interop and hashed at the start of the meeting.<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Process Cycles ==<br />
<br />
Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to Interop Working Group but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant). <br />
<br />
See [https://github.com/openstack/interop/blob/master/doc/source/process/ProcessCycles.rst Process Cycles]<br />
<br />
The current cycle is named the '''''Scale Cycle'''''.<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/13489/prakash-ramchandran Prakash Ramachandran] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/54 Mark T. Voelker] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Governance/InteropWG&diff=178033Governance/InteropWG2021-03-30T21:12:20Z<p>Arkady: added https://etherpad.opendev.org/p/interop link for minutes/notes</p>
<hr />
<div>This Committee was formed during the OpenStack Ice House Summit in Hong Kong by Board Resolution on 11/4.<br />
<br />
''Interop Working Group sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."''<br />
<br />
Our mission is to define "OpenStack Core" as chartered by the by-laws.<br />
<br />
== Important Artifacts ==<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/Lexicon.rst Terms Definition]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreDefinition.rst 10 Core Principles] (board approved Hong Kong Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/PlatformCap.rst Capability Levels: Component and Platform] (board approved October 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/CoreCriteria.rst 12 Scoring Criteria] (board approved Atlanta Summit)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/DesignatedSections.rst 10 Designed Sections Principles] (board approved December 2014)<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/GovernanceProcess.rst Interop Working Group Governance:]<br />
# [https://github.com/openstack/interop/blob/master/doc/source/process/2015A.rst Interop Working Group Process]<br />
# Capabilities & Sections<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.03.rst 2015.03] (review [https://github.com/openstack/interop/blob/master/2015.03.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.04.rst 2015.04] (review [https://github.com/openstack/interop/blob/master/2015.04.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.05.rst 2015.05] (review [https://github.com/openstack/interop/blob/master/2015.05.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2015.07.rst 2015.07] (review [https://github.com/openstack/interop/blob/master/2015.07.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.01.rst 2016.01] (review [https://github.com/openstack/interop/blob/master/2016.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2016.08.rst 2016.08] (review [https://github.com/openstack/interop/blob/master/2016.08.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/doc/source/guidelines/2017.01.rst 2017.01] (review [https://github.com/openstack/interop/blob/master/2017.01.json JSON] for details)<br />
## [https://github.com/openstack/interop/blob/master/next.json next.json (current draft of next Guideline) ]<br />
<br />
== Objective / Scope ==<br />
<br />
The Interop Working Group is around how the OpenStack brand is applied for commercial uses. Initially, this focus is on "what is core" and sustaining that definition over time. The scope will likely expand since brand is an ongoing concern related to specialized marks and other use cases.<br />
<br />
There are three ways in which the community uses the OpenStack brand including referring to projects.<br />
# General community use of the mark<br />
# Project-specific use associated with development activity<br />
# Governed commercial use<br />
<br />
While the top two of these uses are out of scope for Interop Working Group, the committee has a need to participate in the discussion to ensure consistent and clear use.<br />
<br />
== How to Engage? ==<br />
<br />
* Join #openstack-interop and #refstack on Freenode IRC<br />
* Follow the [https://opendev.org/osf/interop Interop code] and associated repositories: [https://opendev.org/osf/refstack Refstack] and [https://opendev.org/osf/refstack-client Refstack-client]<br />
* Join our weekly [[Governance/InteropWG#Meetings|meetings]]<br />
* Learn the [https://opendev.org/osf/interop/src/master/HACKING.rst rules for submitting changes]<br />
<br />
== Meetings ==<br />
<br />
Since June 2020, the Interop WG meetings have been held on meetpad on https://meetpad.opendev.org/Interop-WG-weekly-meeting at 10 AM PST every friday<br />
See 10 AM in your timezone: https://mytime.io/10am/PST<br />
<br />
If you cannot use Meetpad, you can ping the #openstack-interop channel at 10 AM PST on Friday. <br />
Latest meetings notes/minutes are posted on the Etherpad: https://etherpad.opendev.org/p/interop<br />
<br />
Logs of past IRC meetings [http://eavesdrop.openstack.org/meetings/interopwg/ can be found here]. Much Older meetings logs from [http://eavesdrop.openstack.org/meetings/defcore/ when the interop group was called "Defcore" are here].<br />
<br />
== Process Cycles ==<br />
<br />
Defining OpenStack Core is a long term process and we are doing the work in progressive cycles. For reference, we have named the cycles. This helps describe concrete deliverables for a cycle while allowing discussion of the broader long term issues. For example, we may say that "item X is important to Interop Working Group but out of scope for Elephant." We have found that this approach to breaking down the problem is necessary to maintain community consensus because we are taking smaller bites of the larger challenge (aka eating the elephant). <br />
<br />
See [https://github.com/openstack/interop/blob/master/doc/source/process/ProcessCycles.rst Process Cycles]<br />
<br />
The current cycle is named the '''''Scale Cycle'''''.<br />
<br />
== Current Committee Leaders ==<br />
Current Leaders:<br />
* [https://www.openstack.org/community/members/profile/13489/prakash-ramchandran Prakash Ramachandran] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/7713/arkady-kanevsky Arkady Kanevsky] (board member, co-chair)<br />
* [https://www.openstack.org/community/members/profile/54 Mark T. Voelker] (co-chair)<br />
<br />
The interop WG is assisted by the [https://review.opendev.org/admin/groups/8cd7203820004ccdb67c999ca3b811534bf76d6f,members "refstack" core group] who help maintain various code repositories. <br />
<br />
[[category: InteropWG]]<br />
[[Category: Working_Groups]]</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Release_Naming/X_Proposals&diff=176680Release Naming/X Proposals2020-11-02T21:01:46Z<p>Arkady: /* Proposed Names */</p>
<hr />
<div>== X Release Naming ==<br />
<br />
According to the [http://governance.openstack.org/reference/release-naming.html Release Naming Process], this page will contain a list of nominated names for the X release of OpenStack. We will accept nominations until November 26, 2020 23:59:59 UTC.<br />
<br />
=== Release Name Criteria ===<br />
<br />
The way we do release naming has changed slightly from past releases. Rather than restricting name candidates to the geographic region where the Summit is held, we will now accept any name a member of the community would like to propose, as long as the name begins with the appropriate letter. The current release naming criteria are:<br />
<br />
* Each release name must start with the letter of the ISO basic Latin alphabet following the initial letter of the previous release, starting with the initial release of "Austin". After "Z", the next name should start with "A" again.<br />
* The name must be composed only of the 26 characters of the ISO basic Latin alphabet. Names which can be transliterated into this character set are also acceptable.<br />
* The name must be a single word with a maximum length of 10 characters.<br />
<br />
Names which do not meet these criteria but otherwise sound really cool<br />
should be added to a separate section of the wiki page and the TC may<br />
make an exception for one or more of them to be considered in the<br />
Condorcet poll. The naming official is responsible for presenting the<br />
list of exceptional names for consideration to the TC before the poll<br />
opens.<br />
<br />
=== Proposed Names ===<br />
<br />
Please list names with any relevant links to more details. If there is a particular reason you think a name would be a good choice, please add a brief rationale with the name.<br />
<br />
* [https://en.wikipedia.org/wiki/Xanadu Xanadu] (an ancient Mongolian capital, also the title of Gene Kelly's last film appearance, also the fictional estate of Charles Foster Kane in Citizen Kane, also Mandrake the Magician's high-tech mansion)<br />
* [https://en.wiktionary.org/wiki/xylocarp xylocarp]<br />
* [https://en.wiktionary.org/wiki/xylyl xylyl] (just a crazy-looking word)<br />
* [https://en.wiktionary.org/wiki/xenomorph Xenomorph] - I think this is fun and 2020 needs fun right now<br />
* [http://www.catb.org/~esr/jargon/html/X/xyzzy.html Xyzzy] - the only magic word you'll ever need (except maybe plugh)<br />
* [https://en.wikipedia.org/wiki/Xylophone xylophone] - an instrument played with sticks having a soft sound<br />
* [https://en.wikipedia.org/wiki/Xerxes_Peak Xerxes] - A few different uses, I've linked the mountain but also an ancient ruler<br />
* [https://en.wikipedia.org/wiki/Xenon Xenon] - A chemical element, part of the noble gases<br />
* [https://en.wikipedia.org/wiki/X-ray X-Ray] - A penetrating form of high-energy electromagnetic radiation<br />
* [https://en.wikipedia.org/wiki/Xerus Xerus] - A genus of coarse-haired long-tailed African ground squirrels<br />
* [https://www.marvel.com/characters/Xenith Xenith] - A Marvel female superhero and galactic peace keeper<br />
* [https://en.wikipedia.org/wiki/Xiamen Xiamen] - A major city in Fujian province, China<br />
* [https://www.dictionary.com/browse/xoanon xoanon] - a simple, carved image, especially one in which the original block of stone or wood is readily apparent.<br />
* [https://en.wikipedia.org/wiki/Exclusive_or xor] - Exclusive or or exclusive disjunction is a logical operation that outputs true only when inputs differ.<br />
* [https://www.dictionary.com/browse/xebec xebec] - a small, three-masted vessel of the Mediterranean, formerly much used by corsairs, now employed to some extent in commerce.<br />
* [https://en.wikipedia.org/wiki/Xena Xena] - a fictional warrior princess<br />
* [https://en.wikipedia.org/wiki/Xalapa Xalapa] - city in Mexico<br />
* [https://en.wikipedia.org/wiki/Xenia Xenia] - city in Ohio, USA<br />
* [https://en.wikipedia.org/wiki/Xi'an Xi'an] - large city in China, Fujian province (there are a couple of dozen large cities in China that start with X)<br />
* [https://en.wikipedia.org/wiki/Xanthi Xanthi] - town in Greece<br />
* [https://en.wikipedia.org/wiki/Xangongo Xangongo] - town in Angola<br />
<br />
=== Proposed Names that do not meet the criteria ===</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=PTG/Train/Etherpads&diff=170663PTG/Train/Etherpads2019-06-11T23:03:06Z<p>Arkady: added baremetal SIG</p>
<hr />
<div>__NOTOC__<br />
<br />
This is the list of etherpads for the Projects Team Gathering for the Train release in Denver, 2019. Each team can organize the content on their allocated day(s) in the way that seems to most appropriate to them. We suspect most teams will avoid strict timeboxed slots and will use etherpads to list topics to cover. This page lists those etherpads for easy reference.<br />
<br />
For more details on the event, see the [https://www.openstack.org/ptg/ event website].<br />
<br />
For what's happening '''right now''' (during the event), see the [http://ptg.openstack.org/ptg.html ptgbot page].<br />
<br />
=== Projects ===<br />
* Barbican - https://etherpad.openstack.org/p/barbican-train-ptg<br />
* Blazar - https://etherpad.openstack.org/p/blazar-ptg-train<br />
* Charms - https://etherpad.openstack.org/p/charms-train-ptg<br />
* Cinder - https://etherpad.openstack.org/p/cinder-train-ptg-planning<br />
* Cyborg - https://etherpad.openstack.org/p/cyborg-ptg-train<br />
* Docs/I18n - https://etherpad.openstack.org/p/docs-i18n-ptg-train<br />
* Fenix<br />
** Fenix general - https://etherpad.openstack.org/p/DEN2019-fenix-PTG<br />
** Fenix - ETSI NFV - https://etherpad.openstack.org/p/DEN2019-fenix-ETSI-NFV-PTG<br />
* Glance - https://etherpad.openstack.org/p/Glance-Train-PTG-planning<br />
* Heat - https://etherpad.openstack.org/p/DEN-Train-Heat<br />
* Horizon - https://etherpad.openstack.org/p/horizon-train-ptg<br />
* Infra - https://etherpad.openstack.org/p/2019-denver-ptg-infra-planning<br />
* Ironic - https://etherpad.openstack.org/p/DEN-train-ironic-ptg<br />
* Keystone - https://etherpad.openstack.org/p/keystone-train-ptg<br />
* Loci - https://etherpad.openstack.org/p/loci-train-ptg<br />
* Magnum - https://etherpad.openstack.org/p/magnum-train-ptg<br />
* Manila<br />
** Planning: https://etherpad.openstack.org/p/manila-denver-train-ptg-planning<br />
** Minutes/Proceedings: https://etherpad.openstack.org/p/manila-ptg-train<br />
* Monasca - https://etherpad.openstack.org/p/monasca-ptg-train<br />
* Neutron - https://etherpad.openstack.org/p/openstack-networking-train-ptg<br />
* Nova - https://etherpad.openstack.org/p/nova-ptg-train<br />
* Octavia - https://etherpad.openstack.org/p/octavia-train-ptg<br />
* OpenStackAnsible - https://etherpad.openstack.org/p/osa-train-ptg<br />
* OpenStack Client - https://etherpad.openstack.org/p/train-ptg-osc<br />
* OpenStack Helm - https://etherpad.openstack.org/p/osh-ptg-train<br />
* Oslo - https://etherpad.openstack.org/p/oslo-train-topics<br />
* Placement - https://etherpad.openstack.org/p/placement-ptg-train<br />
* QA<br />
** Schedule: https://ethercalc.openstack.org/Train-PTG-QA-Schedule<br />
** Etherpad: https://etherpad.openstack.org/p/qa-train-ptg<br />
* Release Team - https://etherpad.openstack.org/p/relmgmt-train-ptg<br />
* StoryBoard - https://etherpad.openstack.org/p/sb-train-ptg<br />
* Swift - https://etherpad.openstack.org/p/swift-ptg-train<br />
* Tripleo <br />
** Schedule: https://etherpad.openstack.org/p/tripleo-ptg-train<br />
** Topic Planning: https://etherpad.openstack.org/p/tripleo-train-topics<br />
* Vitrage - https://etherpad.openstack.org/p/vitrage-train-ptg<br />
<br />
=== Cross-Project ===<br />
* Nova/Cinder - https://etherpad.openstack.org/p/ptg-train-xproj-nova-cinder<br />
* Nova/Cyborg - https://etherpad.openstack.org/p/ptg-train-xproj-nova-cyborg<br />
* Nova/Ironic - https://etherpad.openstack.org/p/ptg-train-xproj-nova-ironic<br />
* Nova/Keystone - https://etherpad.openstack.org/p/ptg-train-xproj-nova-keystone<br />
* Nova/Neutron - https://etherpad.openstack.org/p/ptg-train-xproj-nova-neutron<br />
* Nova/Placement - https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement<br />
* Cyborg/Ironic - https://etherpad.openstack.org/p/ptg-train-xproj-ironic-cyborg<br />
<br />
=== SIG/Theme/Other ===<br />
* API SIG - https://etherpad.openstack.org/p/api-sig-ptg-train<br />
* Baremetal SIG - https://etherpad.openstack.org/p/DEN-bare-metal-SIG<br />
* Auto-scaling SIG - https://etherpad.openstack.org/p/DEN-auto-scaling-SIG<br />
* Edge WG - https://etherpad.openstack.org/p/edge-wg-ptg-preparation-denver-2019<br />
* Elections - https://etherpad.openstack.org/p/election-train-ptg<br />
* Interop WG - https://etherpad.openstack.org/p/interop-ptg-denver<br />
* K8s SIG - https://etherpad.openstack.org/p/k8s-sig-ptg-train<br />
* Public Cloud SIG - https://etherpad.openstack.org/p/DEN-public-cloud-SIG<br />
* Scientific SIG - https://etherpad.openstack.org/p/scientific-sig-ptg-train<br />
* Self-healing SIG - https://etherpad.openstack.org/p/DEN-self-healing-SIG<br />
* Security SIG - https://etherpad.openstack.org/p/security-sig-ptg-train<br />
* Technical Committee - https://etherpad.openstack.org/p/tc-train-ptg<br />
* Upgrades SIG - https://etherpad.openstack.org/p/upgrade-sig-ptg-train<br />
<br />
=== Pilot Projects ===<br />
* Airship - https://etherpad.openstack.org/p/airship-ptg-train<br />
* StarlingX - https://etherpad.openstack.org/p/stx-ptg-agenda<br />
<br />
=== Other ===<br />
* PTG feedback - https://etherpad.openstack.org/p/OIS-PTG-denver-feedback</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Edge_Computing_Group/Use_Cases&diff=168516Edge Computing Group/Use Cases2019-02-25T21:04:10Z<p>Arkady: /* Use cases template */</p>
<hr />
<div>=Definition of terms=<br />
Additional definitions were crafted at the [[OpenStack_Edge_Discussions_Dublin_PTG#Definitions|Dublin meeting]]. <br />
* Scenarios - like in the white paper, scenarios are broad general descriptions of problems edge computing are being used to solve.<br />
* Business Cases - business cases are a sub-category of scenarios. They are an opportunity to provide specific examples of edge computing scenarios.<br />
<br />
* [[MappingOfUseCasesFeaturesRequirementsAndUserStories]]<br />
<br />
=Use cases template=<br />
<pre><br />
=={Name of use case}==<br />
'''Status''': Draft/Under Discussion/Confirmed <br/><br />
'''Priority''': Normal/High<br />
'''Author'': <Your Name> <br/><br />
====Description====<br />
Provide a 1 sentence - 1 paragraph summary of the business case.<br />
* '''''Edge cloud service user''''' - Who is the intended end user of the service? What types of services is the user running?<br />
* '''''Edge cloud infrastructure user''''' - Who is supporting the infrastructure?<br />
* '''''Edge site(s)''''' - What is the nature of the compute/controller resources of the edge site? <br />
* '''''Connectviity reliability''''' - What is the expectation for reliability? <br />
* '''''Edge Size''''' - What is the size? (One from [here https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/development/requirements/requirements.html#edge-sites-conditions-deployment-scenarios]. If something is missing please contribute there.)<br />
<br />
====Business Cases====<br />
Provide bullet point cases. <br />
<br />
====Derrived Requirements====<br />
* Title of requirement hyperlinked to requirement from [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Requirements here] (if the requirement does not exist below, please add it)<br />
<br />
====Links====<br />
Links to relevant resources. <br />
<br />
</pre><br />
<br />
=Use Cases=<br />
<br />
==Mobile service provider 5G/4G virtual RAN deployment and Edge Cloud B2B2X.==<br />
'''Status''': Draft <br/><br />
'''Priority''': high <br/><br />
'''Author''': Paul-Andre Raymond (Case 1), Hyde Sugiyama (Case 2) <br/><br />
===Description===<br />
There are at least three use cases related to this (e.g. vRAN, NFV, MEC). While the use cases are different, the expectation is that they will run on the same infrastructure. So it makes sense to treat them together.<br />
Case 1:<br />
1- vRAN: Here the l focus on virtual Baseband Unit (BBU) which has stringent requirements on processing for timing controls with 'remote radio heads' <br />
2- NFV: Here the focus is on running the Core applications as virtual machines at the edge. This includes, vEPC elements, vRouters, Virtual Firewall (vFW), Virtual Load Balancer (vLB). <br />
3- MEC: Here the focus is on running 3rd party or operator applications at the edge. The MEC resource pools could be supporting a variety of other MEC applications (smart city, v2x, consumer AR). <br />
<br />
* '''''Edge cloud service user''''' - for vRAN and NFV the user is the wireless network operator. For MEC it could be the operator, a 3rd party application provider or the wireless end-user.<br />
* '''''Edge cloud infrastructure user''''' - The Edge Cloud infrastructure user would be the network operator. <br />
* '''''Edge site(s)''''' - An operator's network could include thousands of sites. Each site could range from a handful of servers to dozens of racks.<br />
* '''''Connectviity reliability''''' - Front Haul reliability is driven by Radio requirements and is high. Backhaul reliability is driven by operator service requirements (5 9s)<br />
* '''''Edge Size''''' - medium to large<br />
<br />
Case 2: <br />
By splitting CU-DU (from BBU), vCU can run on the same NFVI edge computing platform that runs UPF(5G) ( or S/P-GW-U in 4G) and other VNFs including vFW and vLB. <br />
End users/devices traffic can be released at the clear demarcation point placing UPF in Edge DC. <br />
We can install Kubernetes based cloud on top of NFVI and put UPF(and other VNFs) in front of Kubernetes to carry the user's traffic to cloud native apps in the Kubernetes.<br />
<br />
===Business Cases===<br />
Case 1:<br />
1- The vBBU deployment is driven by need for : easy life cycle management, vendor independence, automatic scaling (and energy savings).<br />
2- The NFV deployments is driven by need for automatic scaling and vendor independence.<br />
3- The MEC deployment is driven by opportunities for new revenue streams possibly from new sources.<br />
<br />
Case 2:<br />
1) Edge Cloud B2B2X model<br />
In the traditional Telco service provider model, the Telco provided services(the first B of B2B2X) directly to either individual or corporate consumers to increase revenue. In the Edge Cloud B2B2X model, Telco collaborates with diverse partners in other industries(the second B of B2B2X)to deliver added value to consumers/devices(X of B2B2X) through a wide range of the biz service providers.<br />
Here, the value that Telco Edge Cloud can provide biz service providers can take various forms, such as IoT & Edge Intelligence, Containerized micro service, AI framework, and other advanced ICT technologies, user interface technologies, and security tools.<br />
<br />
===Requirements===<br />
Case 2<br />
RU<----->DU<->[vCU <--> UPF <--> VNFs <-->K8s]/NFVI & Ceph data lake <br />
<br />
1) CU-DU split in vRAN<br />
2) Ingress/Egress enhancement for bringing the user's traffic to Kubernetes cloud. <br />
IPv6/IPv4 NAT, Core DC & Edge DC federation and etc.<br />
3) Since Edge needs more intelligence, Ceph object storage(Data lake) also will be needed at Edge within limited space. <br />
Small Edge can implement distributed NFVI model with Ceph based Hyper-converged model.<br />
Medium Edge & Large Edge can implement standard OpenStack NFV and Ceph Data Lake.<br />
4) Container registry Geo replication storage technology from Core/Cloud will be needed so that Edge DC can run same Container App that built at Central Data Center or Cloud.<br />
<br />
===Suitable MVP architecture===<br />
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario Distributed Control Plane Scenario]<br />
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario Centralized Control Plane Scenario]<br />
<br />
===Links===<br />
* ETSI MEC White paper: https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp24_MEC_deployment_in_4G_5G_FINAL.pdf<br />
* ETSI CRAN White Paper: https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp23_MEC_and_CRAN_ed1_FINAL.pdf<br />
* NGMN overview of 5G RAN: https://www.ngmn.org/fileadmin/ngmn/content/downloads/Technical/2018/180226_NGMN_RANFSX_D1_V20_Final.pdf<br />
* O-RAN WP: https://www.o-ran.org/resources/<br />
* xRAN WP & low-layer spliut spec: http://www.xran.org/resources/<br />
* OPNFV edge cloud slides (China Mobile): https://wiki.opnfv.org/display/PROJ/Edge+cloud?preview=/20743670/20745005/20180502_Edge%20Cloud_requirement.pdf<br />
* OPNFV VCO 2.0 demo: https://www.opnfv.org/resources/virtual-central-office<br />
<br />
==Universal customer premise equipment (uCPE) for Enterprise Network Services==<br />
'''Status''': Drafting <br/> <br />
'''Priority''': normal <br/><br />
'''Author''': Trevor Cooper <br/><br />
<br />
===Description===<br />
uCPE describes an Enterprise edge use-case for replacing many dedicated network appliances with virtual network functions (VNFs) running on a single, universal platform (i.e. COTS server). While this is considered an NFV use-case we can envisage additional Edge workloads also running on the same box (e.g. AWS Greengrass software for IoT messaging, data caching, sync, etc.).<br />
<br />
Communication Service Providers (CommSPs) see uCPE platforms as an opportunity to “expand the range of choices available to our customers, accelerate the enterprise transformation to cloud based architectures, and increase the agility of organizations to respond to market challenges.” Enterprises want the ability to mix and match VNFs depending on what functions are needed at each Enterprise location and based on vendor preferences.<br />
<br />
IDC expects worldwide spending on vCPE infrastructure hardware and software to reach $3 billion by 2021.<br />
<br />
"uCPE" (universal) is not to be confused with vCPE (virtual) where CPE functions run in the service provider network on virtualized platforms.<br />
<br />
===Users===<br />
<br />
The uCPE is part of the Enterprise network with the infrastructure aspect a service provided by the Telco (Comms. Service Provider). The Enterprise is hence the user of the Edge Cloud infrastructure service.<br />
<br />
VNFs or other applications that run on the uCPE will usually be provisioned and managed by the Enterprise as part of their business network infrastructure. For example firewall rules managed by Enterprise IT.<br />
<br />
From the perspective of the Enterprise IT their customers are the end-users (i.e. users of the network services are employees, departments, branch offices, etc.)<br />
<br />
===Support===<br />
* The uCPE infrastructure is supported by the Communication Service Providers (CommSPs). This includes life-cycle management e.g. infrastructure software upgrades and software to install VMs and/or containers.<br />
* The VNFs will typically be owned and supported by the Enterprise (who in turn may have a service contract with the VNF vendor)<br />
<br />
===Edge site(s)===<br />
* Enterprise<br />
<br />
===Connectivity reliability===<br />
* Business critical infrastructure, typically fixed-line for high reliability WAN connectivity <br />
<br />
===Edge Size===<br />
* [https://gerrit.opnfv.org/gerrit/#/c/58959/7/docs/development/requirements/requirements.rst@214 Small]<br />
<br />
===Business Cases===<br />
* firewall, <br />
* WAN routing, <br />
* virtual private network, <br />
* intrusion prevention system, <br />
* session border control, <br />
* carrier-grade network address translation, <br />
* Wi-Fi, LAN controller<br />
* software-defined WAN (SD-WAN)<br />
* vRouter<br />
* WAN optimizer<br />
* ... and combinations of above (and/or other network functions)<br />
* ... and other possible applications (e.g. AWS Greengrass workloads)<br />
<br />
===Requirements===<br />
* Hardware is based on COTS server platforms<br />
* Virtualized environment ... VMs, containers or both<br />
* Support multi-vendor applications (VNFs or other workloads). This does not preclude the possibility of running a single application at any one time.<br />
* Deployment model - zero touch (ideally drop ship and does not need any hands-on from Telco to provision the uCPE at the Enterprise). APIs for OOB management (e.g. Redfish, etc.) may be used.<br />
* Linux environments for Cloud Management solutions<br />
* Support disaster scenarios with e.g. "safe" mode for loss of connectivity, graceful failure, reboot/recovery of applications, etc.<br />
* Need out-of-band management capability (e.g. could be wired or wireless or even POTS!)<br />
* Scalable to accommodate different capacities (e.g. size of branch offices) and allow for Enterprise growth ... types of scale may include 1) run on a more powerful server 2) run as a cluster of servers 3) add more VNFs (or other apps).<br />
<br />
===Suitable MVP architecture===<br />
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario Distributed Control Plane Scenario]<br />
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario Centralized Control Plane Scenario]<br />
<br />
===Links to relevant resources===<br />
* https://www.sdxcentral.com/articles/contributed/understanding-use-universal-cpe/2017/07/<br />
* https://www.sdxcentral.com/reports/2017/sd-wan-vcpe-ucpe/universal-cpe/<br />
* https://newsroom.intel.com/news/intel-rolls-out-ucpe-intel-select-solution-accelerate-network-transformation/<br />
* https://www.lightreading.com/the-edge/intel-cooks-up-recipes-to-speed-ucpe-adoption/d/d-id/743080<br />
<br />
==Unmanned Aircraft Systems (Drones)==<br />
'''Status''': Draft <br/><br />
'''Priority''': normal <br/><br />
'''Author''': Abraham Arce <br/><br />
===Description===<br />
Description of the use case in detail.<br />
<br />
* '''''Edge cloud service user''''' - <br />
* '''''Edge cloud infrastructure user''''' - Drone user, commercial or hobbyist, etc.<br />
* '''''Edge site(s)''''' - Edge Drone Base Station<br />
* '''''Connectivity reliability''''' - Low to Medium (IoT) <br />
* '''''Edge Size''''' - Base Station.<br />
<br />
===Business Cases===<br />
Provide bullet point cases.<br />
<br />
* Agriculture<br />
** Mapping<br />
** Terrain Inspection<br />
** Crop Monitoring<br />
** Soil Data Collection<br />
* Commerce / Transportation<br />
** Delivery Services<br />
** Air Taxis<br />
* Environmental<br />
* Public Safety<br />
** Surveillance<br />
** Traffic Management<br />
* Health<br />
** Emergency Management<br />
** First Responder Network<br />
** Search and Rescue<br />
* Urban<br />
** Photography<br />
** Mapping<br />
** Inspection<br />
** Insurance<br />
** Scan / Map areas of interest<br />
* Others<br />
** Rural Support<br />
** Long-range surveillance<br />
<br />
===Requirements===<br />
<br />
These are high level requirements based on the different use cases not tight to specific OpenStack infrastructure requirements due to my limited understanding of the OpenStack architecture.<br />
<br />
* Data Monitoring<br />
* Video Streams<br />
* Documentation through video stream collection<br />
* Live video analysis<br />
* Artificial Intelligence features<br />
* Multiple aerial and ground units Coordination<br />
* Ground control stations<br />
* Immediate response / real time<br />
* Connectivity extension<br />
* Dynamic Routing<br />
<br />
===Links===<br />
<br />
* [https://github.com/xunankab XunanKab Github Organization]<br />
* [https://twitter.com/IoTLearningInit/status/1065582081139507200 XunanKab Twitter Executive Presentation Thread]<br />
* [https://docs.google.com/spreadsheets/d/1vGWLTH_3hS9aD_ogoAa_TjY0Am714FEFBjLApZYYDWU/edit?usp=sharing XunanKab Project Roadmap]<br />
* [https://drive.google.com/drive/folders/0B6h7kxp-oIy8X1pSOFd0UHBZRzA Workshop bit.ly/DroneSoftwareDevelopment]<br />
* [https://theiotlearninginitiative.gitbook.io/bitol Workshop Drone Software Development Gitbook Repository]<br />
* [https://github.com/TheIoTLearningInitiative/Bitol Workshop Drone Software Development Github Repository]<br />
<br />
===XunanKab Project===<br />
<br />
XunanKab Version 0.1 is ready which includes the deployment of the use case through Docker container infrastructure with the following components:<br />
<br />
* Core<br />
** Unmanned Aerial Vehicle<br />
** Communication Protocol<br />
** Ground Control Station<br />
* Tasks<br />
** Take Off<br />
** Return To Launch<br />
** To<br />
** Land<br />
** Square<br />
* Services<br />
** Hardware<br />
*** CPU<br />
**** Face Detect<br />
** Computer Vision<br />
*** OpenCV<br />
** Telemetry<br />
*** MQTT<br />
<br />
Current roadmap of activities: https://docs.google.com/spreadsheets/d/1vGWLTH_3hS9aD_ogoAa_TjY0Am714FEFBjLApZYYDWU/edit?usp=sharing<br />
<br />
===Suitable MVP architecture===<br />
* None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event<br />
<br />
=== Questions and comments ===<br />
* What is the exact use case here? Who should do what?<br />
** Working in the answer<br />
* For Edge Size please use something from here: https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/development/requirements/requirements.html#edge-sites-conditions-deployment-scenarios<br />
* Is XunanKab an open source project? I could not get any reference to it from Google.<br />
* Are there VM-s needed here or everything should run in containers?<br />
<br />
==Cloud Storage Gateway - Storage at the Edge==<br />
'''Status''': Draft <br/><br />
'''Priority''': normal <br/><br />
'''Author''': Beth Cohen <br/><br />
===Description===<br />
A Cloud Storage Gateway is when data (in some form further defined below) is stored in an edge location or device and shared either with other shared data remote locations. It is assumed that the storage communicates with a Cloud Service Provider (CSP) storage service at the core; however this is not strictly required to meet the use case criteria. Examples with a core storage location include: AWS S3 Storage Gateway, Microsoft Avere Flash Cloud..<br />
<br />
The use case requirement is to allow a CSP storage service to extend the storage out to the Edge appliance or uCPE that has the ability to store some amount of data locally, but still communicate to the central repository. Need to support VTL, Volume, Object Store and File type data storage. The data can be generated from the cloud to the Edge ( Gaming, Video Streaming, etc.) or generated from Edge back to Cloud (data archiving of records, IoT, Augmented Reality, backup, etc.) or in both directions. Need for low latency/high performance network (IoT, gaming, etc.). Moving IoT over cellular/5G networks storage requirements: Cache what is needed locally. Storage would need to be sized based on density of area covered and type of data.<br />
<br />
* '''''Edge cloud service user''''' - Gamer, Mobile apps, VR/AR, IoT devices and apps, etc. Any app that needs persistent and semi-persistent data that is network performance sensitive.<br />
* '''''Edge cloud infrastructure user''''' - Company data centers, public and private cloud service providers, Telecom infrastructure support, CDN providers (Edgecast, Akamai, Fastly, Cloudfront, etc.)<br />
* '''''Edge site(s)''''' - Edge appliance or uCPE that is configured with SSD or HDD to support lots of storage. <br />
* '''''Connectivity reliability''''' - Medium (POS, IoT) to High (Gaming, Mobile call management, targeted advertiements) reliability. Eventual sync back to cloud storage. Edge connectivity needs to be more reliable than cloud.<br />
* '''''Edge Size''''' - Single unit hardware.<br />
<br />
===Business Cases===<br />
Provide bullet point cases.<br />
<br />
===Requirements===<br />
* Title of requirement hyperlinked to requirement below (if the requirement does not exist below, please add it)<br />
Glance -- centralized or Glance controller at the edge nodes to manage storage instance. Need to look at meta data between Glance/Nova.<br />
When lots of data is stored at the edge, data storage application implies that the data is processed in some way at the edge -- think IoT data compression or first pass at analytics at the local site.<br />
<br />
===Links===<br />
Add AWS S3 Gateway link. -- Can we leverage S3 or other lightweight edge.<br />
Add Glance<br />
<br />
===Suitable MVP architecture===<br />
* None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event<br />
<br />
=== Questions and comments ===<br />
* Isn't the data distribution is a Cinder backend or application level problem?<br />
* Is there a requirement to cache the data in case of network partitioning?<br />
* Is it possible to identify one size from [the defined edge sizes [https://opnfv-edgecloud.readthedocs.io/en/stable-gambia/development/requirements/requirements.html#edge-sites-conditions-deployment-scenarios] in '''''Edge Size''''' ?<br />
* Is there a requirement for automated management of cloud metadata?<br />
* Is there a requirement for single management interface?<br />
<br />
==Open Caching - stream/store data at the edge==<br />
'''Status''': Drafting <br/><br />
'''Priority''': Normal <br/><br />
'''Author''': David Paterson (July 16)<br />
<br />
===Description===<br />
Enable OpenStack to support standards based open caching workloads at the edge.<br />
<br />
The Video Streaming Alliance's - Open Caching subgroup has the following two objectives:<br />
# To identify the critical components of a non-proprietary caching system.<br />
# To establish basic architectural guidelines for implementation of an open caching system.<br />
<br />
The output from this subgroup is a collection of documents that define:<br />
* Open Cache System Functional Requirements<br />
* Open Cache Request Routing Technical Specification<br />
* Open Cache Request Routing Service Provisioning Specification<br />
* Open Cache Logging Requirements Specification<br />
<br />
To quote the Open Cache Functional Requirements abstract an Open Cache Solution is:<br /><br />
''A distributed architecture leveraging common compute and storage resources deployed at the network edge in close proximity to consumers. The open caching layer establishes a universal delivery layer operating across a range of content provider and used as an extension of the existing content delivery infrastructure.''<br />
<br />
The Open Caching standard is gaining popularity among Content Delivery Networks (CDNs) in a move towards standardization and away from proprietary technology. Essential difference between storage and caching is that with caching, the data is not processed, but stored for use in its final state. Store and forward is an example of caching use.<br />
High availability of the data could be populated from adjacent edge locations or from the central core store.<br />
<br />
Main benefits of open-caching:<br />
* Improved QoE<br />
* Reduction of back-haul<br />
* On Demand Streaming of video content<br />
<br />
Relationship between distance, latency and quality<br /><br />
[[File:Page-oec-section-distance-from-chart.png|frameless|Source: Akamai]]<br /><br />
''Source: Akamai''<br />
<br />
* '''''Edge cloud service user''''' - Digital media consumer.<br />
* '''''Edge cloud infrastructure user''''' - Open Caching management admin, CDN admin.<br />
* '''''Edge site(s)''''' - Open Caching nodes remotely managed via cloud.<br />
* '''''Connectivity/Reliability''''' - MEC, Cable, 5G, public internet. If a Open Caching node is unreachable the manager, running in cloud, redirects requests to closest available live caching node.<br />
<br />
===Business Cases===<br />
* Streaming video optimization in a mobile network context.<br />
* Streaming video to set top box and cable modem local LAN/Wifi<br />
* Streaming high quality lossless compression (FLAC for example) audio<br />
* Distributing any large files such as video games, while not streaming clearly could take advantage of open-caching<br />
<br />
===Edge Size===<br />
* [https://gerrit.opnfv.org/gerrit/#/c/58959/7/docs/development/requirements/requirements.rst@275 Medium]<br />
<br />
=== Requirements ===<br />
* Storage - 40TB hot swappable<br />
* Throughput - up to 10 Gbps<br />
* Compute - Old PCs at the clinic. No major nodes<br />
* Memory - basic data so not much.<br />
* Bare-metal management - out-of-band RAID and BIOS configuration (Redfish seems only reasonable viable way to accomplish), as well as remote deployment of OS services and Open Caching node workload. Ideally a touch-free bare-metal orchestration framework would enable all aforementioned requirements, [https://github.com/openstack/airship-drydock Airship-drydock] looks interesting. <br />
* Management - Open Caching Management software running as workload in main cloud.<br />
* Network connectivity - 14 x 10 GbE Interfaces 12 for connectivity, 2 for delivery.<br />
* HA - Controller HA desirable, currently there are Open Cache vendors running on bare-metal, single-point-of-failure nodes at the edge. HA would be a compelling reason to run Open Caching nodes on IaaS or PaaS at the edge. <br />
* Security - RBAC dictated by manager running as workload in main cloud.<br />
* May have Nova or Neutron or Cinder or .. considerations. Some fundamentals in ETSI GS MEC IEG 004 (and a bunch of proofs of concept since that time). (Need to link to requirements).<br />
<br />
===Suitable MVP architecture===<br />
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Distributed_Control_Plane_Scenario Distributed Control Plane Scenario]<br />
* [https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Centralized_Control_Plane_Scenario Centralized Control Plane Scenario]<br />
<br />
===Links===<br />
[https://www.streamingvideoalliance.org/technical-work/working-groups/open-caching// Streaming Video Alliance - Open Caching Subgroup]<br /><br />
[https://www.streamingvideoalliance.org/technical-work/working-group-output// Streaming Video Alliance - Working Group Technical Documents]<br />[https://www.streamingvideoalliance.org/download/4474/ Streaming Video Alliance - Open Cache System Functional Requirements (pdf)]<br/><br />
[https://about.att.com/content/dam/inside_connections_blogdocs/Whitepaper%20-%20Airship%20a%20New%20Open%20Infrastructure%20Project%20for%20OpenStack%20v1.0.pdf Airship Overview]<br />
<br />
==Smart City as Software-Defined closed-loop system ==<br />
'''Status''': Draft <br/><br />
'''Priority''': Normal <br/><br />
'''Author''': Giovanni <br/><br />
<br />
===Description===<br />
An horizontal platform for most, if not all, Smart City verticals: extending OpenStack to support the I/Ocloud [[https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Links 1]] paradigm through sensor/actuator-hosting far-Edge/IoT nodes, and thus enable the Software-Defined City [[https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Links 2]] approach<br />
* '''''Edge cloud service user''''' - Municipalities, operators, utilities, police<br />
* '''''Edge cloud infrastructure user''''' - City, third-party managing, research institutions, utility, telecoms<br />
* '''''Edge site(s)''''' - Single board computers (raspberry pis), mobiles, smart cameras, smart meters. <br />
* '''''Connectviity reliability''''' - LTE, WiFi coverage, satellite, <br />
* '''''Edge Size''''' - Small<br />
<br />
===Business Cases===<br />
* Surveillance<br />
* Parking tracking<br />
* Traffic monitoring <br />
* Energy optimization / smart meters<br />
* Environmental monitoring<br />
<br />
===Requirements===<br />
* Linux environments<br />
* Client side agent capable of supporting node.js or Python<br />
* Data processing application at the edge<br />
* GPU at the edge<br />
* [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Discovering_of_data_sources Discovering data sources]<br />
* [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_aggregator_part Operability data aggregation data aggregator part ]<br />
* [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Operability_data_aggregation_data_provider_part Operability data aggregation data provider part]<br />
<br />
===Links===<br />
[1] [https://ieeexplore.ieee.org/document/8267996// I/Ocloud: adding an IoT dimension to Cloud Infrastructures]<br /><br />
[2] [https://ieeexplore.ieee.org/document/7518353// Software-Defined Cities: a novel paradigm for Smart Cities through IoT Clouds]<br />
<br />
==Augmented Reality -- Sony Gaming Network==<br />
'''Status''': Under Discussion <br/><br />
'''Priority''': normal <br/><br />
'''Author''': N/A <br />
===Description===<br />
A network of nodes that allow people to share immercive gaming experiences. Assume that the nodes are using end user consoles to deliver the servcies. <br />
* '''''Edge cloud service user'''''<br />
Gamers, Gaming shops (where users gather to play together), Individual consumers, delivered on subscription basis, so need to think about way to turn on and off service based on subscription status.<br />
* What types of services is the user running? -- types of applications, security types (access controls), network services, etc that are used in support of the use case.<br />
-- Graphics accelerators, enduser apps, networking servcies, WAN optimization, authentication service. goggle apps, printing device controls, consoles<br />
* '''''Edge cloud infrastructure user''''' Consumer and Storefront, Gaming company, Cloud CSP, Transport communications provider <br />
* '''''Edge site(s)''''' Accessable(hostile) (Pokemon go type)<br />
* '''''Edge Environment''''' Data center/office/vault/hostile/Power profile (DC/AC, PoE? (cell towers, oil rigs, light poles, ships, drones, moving vehicles, edge of a volcano)<br />
Consumer home, or retail outlet<br />
* '''''Application reuirements''''' - Memory intensive, compute heavy, Storage heavy, Network heavy, etc.<br />
* '''''Edge Storage''''' - Related to size, but capture the spcific requirements here in size, type, etc. SSD/HDD? Distributed/Local/Cloud only/Local Cache/Geo caching<br />
Could be substantial, SSD, local, geo caching, might need local for building VR interactive environment , storage/per game+user profiles, persistant (profiles+game characteristics) /ephemoral (cache needed for in game play)<br />
* '''''Edge Compute''''' -- Number of cores?, CPU required to run the set of applications at the edge Distributed/Local/Cloud only/Memory centric/ - CPU per instance per user/player<br />
* '''''Edge Memory''''' -- Memory required to run the set of applications at the edge: ???GB per instance/per user/player<br />
* '''''Connectviity Characteristics''''' - What is the expectation for reliability? Need Latency requirements here in addition to reliability and uptime. How about characteristics to cover the broader requirements; reliabiliy, latency, connection bandwidth size <br />
Broadband, LTE depending on if home based, retail or on a tablet/cellphone<br />
* '''''Edge Management Characteristics ''''' -- Behavior when it is connected to central management, and behavior when it is not connected "off-line". Connected: authentication, routing to backend data nodes, geocaching, software updates, global user metadata Disconnected: network config, user credendials, output specifications<br />
* '''''Edge HA''''' -- Uptime SLA requirements<br />
5 9's, be able to work in some fashion locally while off line.<br />
* '''''Edge Security''''' -- regulatory requirements (HIPPA, GDPR, PCI, etc.), insecure environments with physical access, hostile environments<br />
No regulatory requirements, but need to protect PCI, GDPR for players, physical security<br />
* '''''Edge Size''''' - What is the size? -- Need to quanitfy this a bit more. Each Node size (IoT device, box or rack, or small data center: Use the small, medium, large based on Dublin requirements doc), number of nodes? (hundreds, thoughsands, millions) <br />
Console (single box) and mobile device<br />
<br />
===Suitable MVP architecture===<br />
* None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event<br />
<br />
<br />
<br />
==Analytics/control at the edge==<br />
'''Status''': Drafting <br/><br />
'''Priority''': normal <br/><br />
'''Author''': Jess Lampe <br/><br />
===Description===<br />
Systems performing complext analytics near the edge, possibly ML systems reacting to real-time data. <br />
* '''''Edge cloud service user''''' - <br />
* '''''Edge cloud infrastructure user''''' - <br />
* '''''Edge site(s)''''' - <br />
* '''''Connectviity reliability''''' - <br />
* '''''Edge Size''''' - <br />
<br />
===Business Cases===<br />
* A manufacturing edge computing use case involving 'real-time' control loops and/or large volumes of production data flows and analytics (to feed the production control loops). The 99Cloud case example from Vancouver is a reasonable case; there are others from different industry sectors/participants. Might be GPU support or other unique functionality to account for.<br />
<br />
===Requirements===<br />
* TK<br />
<br />
===Suitable MVP architecture===<br />
* Not known<br />
<br />
===Links===<br />
TK<br />
<br />
==Manage retail chains - chick-fil-a==<br />
'''Status''': Draft <br/><br />
'''Priority''': normal <br/><br />
'''Author''': Beth <br/><br />
===Description===<br />
Provide a 1 sentence - 1 paragraph summary of the business case.<br />
* '''''Edge cloud service user''''' - TK<br />
* '''''Edge cloud infrastructure user''''' - TK<br />
* '''''Edge site(s)''''' - TK<br />
* '''''Connectviity reliability''''' - TK<br />
* '''''Edge Size''''' - TK<br />
<br />
===Business Cases===<br />
TK<br />
<br />
===Requirements===<br />
* <br />
<br />
===Suitable MVP architecture===<br />
* N/A<br />
<br />
===Links===<br />
https://medium.com/@cfatechblog/bare-metal-k8s-clustering-at-chick-fil-a-scale-7b0607bd3541<br />
<br />
==Smart Home==<br />
'''Status''': Draft <br/><br />
'''Priority''': normal <br/><br />
'''Author''': David Paterson <br/><br />
<br />
===Description===<br />
Smart Home Enablement will require edge computing resources for a variety of purposes including:<br />
Pushing usage data to central data store for reporting/trending.<br />
Retrieving and installing firmware updates to smart endpoints.<br />
* '''''Edge cloud service user''''' - Home owner<br />
* '''''Edge cloud infrastructure user''''' - Home owner, utility company<br />
* '''''Edge site(s)''''' - Could be a single edge node per home or edge node per community.<br />
* '''''Connectviity reliability''''' - A single non-HA edge node supporting eventual consistency with core cloud is probably sufficient. Smart home features must be able to operate without edge node running. This means the Smart Home Bridge and Edge Node are uncoupled, independent devices.<br />
* '''''Edge Size''''' - Small<br />
<br />
===Business Cases===<br />
* Gathering and pushing usage metrics to core cloud<br />
* Firmware management for smart endpoints<br />
* TBD ...<br />
<br />
===Requirements===<br />
* Linux environments<br />
* Must support a variety of Bluetooth network topologies (Point-to-point, broadcast and mesh)<br />
* Client side agent capable of supporting node.js or Python<br />
* Data processing application at the edge<br />
* GPU at the edge<br />
* Discovering data sources<br />
* Operability - data aggregation data aggregator and provider components<br />
<br />
===Suitable MVP architecture===<br />
* None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event<br />
<br />
===Links===<br />
[https://openconnectivity.org/specs/OIC_SmartHome_Device_Specification_v1.1.0.pdf Smart Home Device Specification]<br /><br />
[https://www.bluetooth.com/bluetooth-technology/topology-options Bluetooth topologies]<br /><br />
[https://drive.google.com/drive/folders/1r8YWocD6yvVlDHKDsDLenDAyX8lUIS4l Edge Computing Smart Home Solution Workshop]<br />
<br />
==Data Collection - Smart cooler/cold chain tracking==<br />
'''Status''': Drafting <br/><br />
'''Priority''': normal <br/><br />
'''Author''': Group <br/><br />
<br />
===Description===<br />
Since edge devices can also produce terabytes of data, taking the analytics closer to the source of the data on the edge can be more cost-effective by analyzing data near the source and only sending small batches of condensed information back to the centralized systems. <br />
* '''''Edge cloud service user''''' - WHO partner organizations, medical workers transporting vaccine goods from production facilitates to remote health care locations. <br />
* '''''Edge cloud infrastructure user''''' - IT groups for the partner organizations. <br />
* '''''Edge site(s)''''' - Remote facilities with intermittent internet/ no internet connectivity. <br />
* '''''Connectviity reliability''''' - Unreliable. <br />
* '''''Edge Size''''' - 1,000s of devices. <br />
<br />
===Business Cases===<br />
* Smart cooler/cold chain tracking. IoT sensors aggregating data. There are development agencies working to improve the vaccine supply chain delivery. Their project goal is to deliver vaccines to remote regions of developing countries and ensure that environmental factors for the vaccines are kept within a certain threshold. If they are not, they want to gather data (temp over time and voltage over time) to determine root cause.<br />
<br />
===Requirements===<br />
* Storage - tiny SSDs on individual IoT devices.<br />
* Compute - Old PCs at the clinic. No major nodes<br />
* Memory - basic data so not much.<br />
* Management - <br />
* Connectivity requirement - <br />
* HA - <br />
* Security - is there anything that needs to happen from a security perspective related to patient info and the vaccine? <br />
<br />
===Suitable MVP architecture===<br />
* None - assuming that this Use Case requires a Small Edge instance which can work in case of a network partitioning event<br />
<br />
===Links===<br />
http://www.healthcaretechnologies.com/using-the-internet-of-things-for-vaccine-supply-chain<br />
<br />
==VPN Gateway Service Delivery==<br />
'''Status''': Drafting <br/><br />
'''Priority''': normal <br/><br />
'''Author''': Ben Silverman <br/><br />
<br />
===Description===<br />
Offloads the VPN service so that the endpoints are as close to the users as possible.<br />
<br />
===Suitable MVP architecture===<br />
* N/A<br />
<br />
==Additional Use Cases==<br />
====Remote Surveillance / Security====<br />
====Unmanned Aerial Systems (Drones)====<br />
====Compliance requirements====<br />
====Network function virtualization====<br />
====Real-time====<br />
====Immersive====<br />
====Network Efficicency====<br />
====Self-contained and autonomous site operations====<br />
====Respect data privacy====<br />
====Industrial control / factory automation====<br />
====5G Service Delivery Platform over non-IP SDN-based Core====<br />
====Automotive Edge Computing====<br />
<br />
=Requirements=<br />
The requirements collected before the use case analyzis work are defined in [https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG#Requirements here]. These requirements will be linked to the use cases under the '''derrived requirements''' section of each use case description. If additional requirements are identified during the use case analyzis the requirements are added to this chapter.</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Meetings/product-team&diff=154646Meetings/product-team2017-06-12T20:10:44Z<p>Arkady: </p>
<hr />
<div>= Jun 12th, 2017 (Monday @ 2100 UTC) Product Team Meeting Agenda =<br />
* Review of action items<br />
** Arkady_Kanevsky and AndyU to work on updating/simplifying PWG wiki<br />
** mrhillsman and AndyU to work on standalone wiki page for video, moderator template, ops meetups moderator guide, FAQs<br />
** all to review existing+wip proposals and decide which one is ready to move forward with wider participation from PTL/core<br />
* Action Plan<br />
** Value 1: Properly documenting ideas, getting a structured workflow, and integration into development workflow<br />
** Value 2: Periodic coordination/collaboration across WGs/Product Managers<br />
* Post-forum report<br />
** Next step on ##hashtag - https://github.com/openstack/development-proposals/tree/master/forum/201705-bos<br />
* Development Proposals review<br />
** https://review.openstack.org/#/q/project:openstack/development-proposals+status:open<br />
* PTG PWG<br />
** https://www.openstack.org/ptg/<br />
** https://docs.google.com/spreadsheets/d/1xmOdT6uZ5XqViActr5sBOaz_mEgjKSCY7NEWcAEcT-A/edit#gid=397241312<br />
** attendees<br />
** agenda<br />
** room requirements<br />
* Open<br />
<br />
<br><br><br />
<br />
''Information on previous agendas: https://etherpad.openstack.org/p/pwg_previous_agendas''</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Meetings/product-team&diff=154645Meetings/product-team2017-06-12T20:09:28Z<p>Arkady: added PTG</p>
<hr />
<div>= Jun 12th, 2017 (Monday @ 2100 UTC) Product Team Meeting Agenda =<br />
* Review of action items<br />
** Arkady_Kanevsky and AndyU to work on updating/simplifying PWG wiki<br />
** mrhillsman and AndyU to work on standalone wiki page for video, moderator template, ops meetups moderator guide, FAQs<br />
** all to review existing+wip proposals and decide which one is ready to move forward with wider participation from PTL/core<br />
* Action Plan<br />
** Value 1: Properly documenting ideas, getting a structured workflow, and integration into development workflow<br />
** Value 2: Periodic coordination/collaboration across WGs/Product Managers<br />
* Post-forum report<br />
** Next step on ##hashtag - https://github.com/openstack/development-proposals/tree/master/forum/201705-bos<br />
* Development Proposals review<br />
** https://review.openstack.org/#/q/project:openstack/development-proposals+status:open<br />
* PTG PWG<br />
** https://www.openstack.org/ptg/<br />
** attendees<br />
** agenda<br />
** room requirements<br />
* Open<br />
<br />
<br><br><br />
<br />
''Information on previous agendas: https://etherpad.openstack.org/p/pwg_previous_agendas''</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Forum/Boston2017&diff=154019Forum/Boston20172017-05-11T15:13:56Z<p>Arkady: </p>
<hr />
<div>The grand list of all of the Boston 2017 Forum etherpads. Please include Date, Time, and links to etherpads when adding new content. An [https://etherpad.openstack.org/p/BOS-forum-moderator-template etherpad template] (optional) is available if you need one.<br />
<br />
<br />
'''See also - [https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146 Full Forum Schedule]'''<br />
<br />
'''See also - [[Forum/Boston2017#Thursday_Afternoon_session_sign-up|Thursday Afternoon session signup]]'''<br />
<br />
'''See also - [https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms Hacking Rooms Schedule]'''<br />
<br />
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3"><br />
__NOTOC__<br />
</div><br />
<br />
= Event intro/closure =<br />
* Forum 101 - https://etherpad.openstack.org/p/BOS-forum-101<br />
* Boston feedback session - https://etherpad.openstack.org/p/BOS-summit-feedback<br />
<br />
= Monday =<br />
* [11:15am-11:55am] - Operating the VM and Baremetal platform (1/2) - https://etherpad.openstack.org/p/BOS-forum-operating-vm-and-baremetal<br />
* [11:15am-12:45pm] - Nova - Project Onboarding - https://etherpad.openstack.org/p/BOS-forum-nova-project-onboarding<br />
* [12:05pm-12:45pm] - OpenStack documentation: The future depends on all of us - https://etherpad.openstack.org/p/doc-future<br />
* [12:05pm-12:45pm] - WG chairs collaboration and WG overviews - https://etherpad.openstack.org/p/BOS-forum-wg-chairs-collaboration-and-WG-overviews <br />
* 12:05 etcd as a base service - https://etherpad.openstack.org/p/BOS-etcd-base-service<br />
* [12:45pm-2:00pm] - Zaqar Project Onboarding - https://etherpad.openstack.org/p/BOS-forum-zaqar-project-onboarding<br />
* [2:00pm-3:30pm] - Hierarchical Quotas - https://etherpad.openstack.org/p/BOS-forum-quotas<br />
* [2:00pm-2:40pm] - Evolving the Community Generated Roadmap - https://etherpad.openstack.org/p/BOS-forum-evolving-the-community-generated-roadmap<br />
* [2:00pm-3:30pm] - Zun Project Onboarding - https://etherpad.openstack.org/p/BOS-forum-zun-project-onboarding<br />
* [2:00pm-2:40pm] - Ironic Feedback Session - https://etherpad.openstack.org/p/BOS-forum-ironic-feedback<br />
* [2:50pm-3:30pm] - Evolving the User Survey - https://etherpad.openstack.org/p/BOS-forum-evolving-the-user-survey<br />
* [2:50pm-3:30pm] - Future of Configuration Management - https://etherpad.openstack.org/p/BOS-forum-future-of-configuration-management<br />
* [3:40pm-4:20pm] - neutron multi-site https://etherpad.openstack.org/p/pike-neutron-multi-site<br />
* [3:40pm-4:20pm] - Making keystone consumable outside of OpenStack - https://etherpad.openstack.org/p/BOS-forum-consumable-keystone<br />
* [3:40pm-4:20pm] - Deprecating Postgresql https://etherpad.openstack.org/p/BOS-postgresql<br />
* [4:40pm-5:20pm] - Next steps for RBAC and policy - https://etherpad.openstack.org/p/BOS-forum-next-steps-for-rbac-and-policy<br />
* [4:40pm-5:20pm] - Should we kill Stackalytics? - https://etherpad.openstack.org/p/BOS-forum-should-we-kill-stackalytics<br />
* [4:40pm-5:20pm] - CellsV2 Developer/Operator/Community Coordination - https://etherpad.openstack.org/p/BOS-forum-cellsv2-developer-community-coordination<br />
* [4:40pm-6:10pm] - QA onboarding at the forum - https://etherpad.openstack.org/p/BOS-QA-onboarding<br />
* [5:30pm-6:10pm] - How do you use Glance? - https://etherpad.openstack.org/p/BOS-forum-how-do-you-use-glance<br />
* [5:30pm-6:10pm] - Using Searchlight to list instances across cells in nova-api - https://etherpad.openstack.org/p/BOS-forum-using-searchlight-to-list-instances<br />
* [5:30pm-6:10pm] - https://etherpad.openstack.org/p/BOS-k8s-SIG-PM<br />
<br />
= Tuesday =<br />
* [11:15am-11:55am] Distributed SNAT with DVR - https://etherpad.openstack.org/p/boston-dvr<br />
* [11:15am-11:55am] Feedback from Users for I18n & Translation - Important Part? - https://etherpad.openstack.org/p/BOS-forum-i18n-translation-feedback-from-users<br />
* [12:05pm-12:45pm] Enhancing Log Message Headers for RT Debug and Traceability - https://etherpad.openstack.org/p/BOS-forum-log-messages<br />
* [12:05pm-12:45pm] LCOO Roadmap Working Session - https://etherpad.openstack.org/p/BOS-forum-LCOORoadmap<br />
* [2:00pm-2:40pm] ETSI NFV Specs’ Requirements vs OpenStack Reality - https://etherpad.openstack.org/p/BOS-ETSI-NFV-Specs-Reqs-vs-OpenStack-Reality<br />
* [2:00pm-2:40pm] Swift ops feedback session - https://etherpad.openstack.org/p/BOS-Swift-ops-feedback-session<br />
* [2:00pm-3:30pm] Barbican and Security Projects Onboarding - https://etherpad.openstack.org/p/BOS-forum-barbican-onboarding<br />
* [2:00pm-3:30pm] OpenStack User API Improvements - https://etherpad.openstack.org/p/BOS-forum-openstack-user-api-improvements<br />
* [2:50pm-3:30pm] Skip-level upgrading - jumping ahead to catch up - https://etherpad.openstack.org/p/BOS-forum-skip-level-upgrading<br />
* [2:50pm-3:30pm] Openstack on The Edge - Fog Edge Massively Distributed clouds - birds-of-a-feather - https://etherpad.openstack.org/p/BOS-Fog-Edge-MassivelyDistributed-BoF<br />
* [2:50pm-3:30pm] Container Sharding - https://etherpad.openstack.org/p/BOS-swift-container-sharding<br />
* [3:40pm-4:20pm] OpenStack-Ansible Operator Feedback - https://etherpad.openstack.org/p/BOS-osa-ops-feedback<br />
* [3:40pm-4:20pm] Swift lots of small files (losf) optimisation - https://etherpad.openstack.org/p/swift-losf-base<br />
* [3:40pm-4:20pm] https://etherpad.openstack.org/p/BOS-financial-WG<br />
* [3:40pm-4:20pm] API Microversion Discussion Hour - https://etherpad.openstack.org/p/BOS-api-microversions<br />
* [4:40pm-5:20pm] Using Cinder for Nova Ephemeral Storage Backend - https://etherpad.openstack.org/p/BOS-forum-using-cinder-for-nova-ephemeral-storage<br />
* [4:40pm-5:20pm] Exposing Deployer Differences Without Death https://etherpad.openstack.org/p/BOS-forum-exposing-deployer-differences<br />
* [5:30pm-6:10pm] Features missing in OpenStack core for Public Cloud provider - https://etherpad.openstack.org/p/BOS-forum-Features-Missing-For-Public-Clouds<br />
* [5:30pm-6:10pm] https://etherpad.openstack.org/p/BOS-forum-future-of-hypervisor-tuning<br />
<br />
= Wednesday =<br />
* [9:00am-9:40am] Oslo developer/operator feedback - https://etherpad.openstack.org/p/BOS-Oslo-brainstorming<br />
* [9:00am-9:40am] Special hardware - https://etherpad.openstack.org/p/BOS-forum-special-hardware<br />
* [9:00am-9:40am] Collaboration between Telecom/NFV related groups - https://etherpad.openstack.org/p/BOS-forum-telecom-nfv-collaboration <br />
* [9:50am-10:30am] oslo.messaging: Recommendations for Non-RabbitMQ Backends - https://etherpad.openstack.org/p/BOS_Forum_Oslo.Messaging_driver_recommendations<br />
* [9:50am-10:30am] Vitrage Usability and New Insights: Where Do We Go Next? - https://etherpad.openstack.org/p/BOS-forum-vitrage-usability-and-new-insights<br />
* [9:50am-10:30am] Advanced Instance Scheduling: Reservations and Preemption - https://etherpad.openstack.org/p/BOS-forum-advanced-instance-scheduling<br />
* [11:00am-11:40am] Compliance/Security Certification for upstream OpenStack - https://etherpad.openstack.org/p/BOS-forum-Compliance-Security-Certification<br />
* [11:00am-11:40am] - Operating the VM and Baremetal platform (2/2) - https://etherpad.openstack.org/p/BOS-forum-operating-vm-and-baremetal<br />
* [11:00am-11:40am] - Large Deployment Team (1/2) https://etherpad.openstack.org/p/BOS-forum-large-deployment-team<br />
* [11:00am-11:40am] - The Future of VPN as a Service (VPNaaS) https://etherpad.openstack.org/p/boston-vpnaas<br />
* [11:50am-12.30pm] - OpenStack Operators Ops Meetup Team Catch-Up - https://etherpad.openstack.org/p/BOS-forum-ops-catch-up<br />
* [11:50am-12:30pm] Comparing OpenStack and Kubernetes Resource Tracking - https://etherpad.openstack.org/p/BOS-forum-openstack-k8s-resource-tracking<br />
* [11:50am-12:20pm] Making Neutron Easy for people who want basic Networking - https://etherpad.openstack.org/p/pike-neutron-making-it-easy<br />
* [11:50am-12:30pm] App Developer Enablement Working Group - https://etherpad.openstack.org/p/BOS-forum-developer-openstack-org<br />
* [12:30pm-1:50pm] - OpenStack Karbor project onboarding - https://etherpad.openstack.org/p/BOS-Karbor-onboarding<br />
* [1:50pm-2:30pm] Neutron pain points - https://etherpad.openstack.org/p/neutron-boston-painpoints<br />
* [1:50pm-2:30pm] Kubernetes Ops on OpenStack - https://etherpad.openstack.org/p/BOS-forum-kubernetes-ops-on-openstack<br />
* [1:50pm-2:30pm] App Developer Enablement - https://etherpad.openstack.org/p/BOS-forum-app-dev-enablement<br />
* [1:50pm-2:30pm] Keystone Operator Feedback - https://etherpad.openstack.org/p/BOS-forum-keystone-operator-feedback<br />
* [2:40pm-3:20pm] Product WG Working Session - https://etherpad.openstack.org/p/BOS-forum-product-wg-working-session<br />
* [2:40pm-3:20pm] Key Management Developer/Operator/Community Coordination - https://etherpad.openstack.org/p/BOS-forum-key-management<br />
* [2:40pm-3:20pm] Scientific OpenStack BoF - https://etherpad.openstack.org/p/Scientific-WG-boston<br />
* [2:40pm-3:20pm] Methods and Projects for Deploying OpenStack with Containers - https://etherpad.openstack.org/p/boston-deploying-openstack-on-k8s<br />
* [3:30pm-4:10pm] Compute Instance/Volume Affinity for HPC - https://etherpad.openstack.org/p/BOS-forum-compute-instance-volume-affinity-hpc<br />
* [3:30pm-4:10pm] Neutron Diagnostics Tools - https://etherpad.openstack.org/p/pike-neutron-diagnostics<br />
* [3:30pm-4:10pm] LCOO Main Working Group-Continue Roadmap Dicussion: https://etherpad.openstack.org/p/BOS-forum-LCOOWG<br />
* [3:30pm-4:10pm] API-WG BoF https://etherpad.openstack.org/p/BOS-API-WG-BOF<br />
* [4:30pm-5:10pm] Moving Resource Claims from nova-compute to nova-scheduler - https://etherpad.openstack.org/p/BOS-forum-move-claims-from-compute-to-scheduler<br />
* [4:30pm-5:10pm] Ops Tags WG session - https://etherpad.openstack.org/p/BOS-forum-ops-tags-wg-session<br />
* [4:30pm-5:10pm] Horizon operator / plugin feedback - https://etherpad.openstack.org/p/horizon-pike-feedback<br />
* [5:20pm-6:00pm] Large Heat Stacks (users/ops/developers) - https://etherpad.openstack.org/p/BOS-forum-Large-Heat-stacks<br />
* [5:20pm-6:00pm] Fog/Edge/Massively Distributed Clouds (working group session) - https://etherpad.openstack.org/p/Massively_distributed_wg_boston_summit<br />
* [5:20pm-6:00pm] Cloud-Native Design/Refactoring Across OpenStack https://etherpad.openstack.org/p/cloud-native-forum<br />
<br />
= Thursday =<br />
* [9:00am-9:40am] Containers lifecycle management: https://etherpad.openstack.org/p/BOS-forum-containers-lifecycle-management<br />
* [9:00am-9:40am] Users/Operators: Contributing Multi-Project Requirements - https://etherpad.openstack.org/p/BOS-forum-contributing-multi-project-requirements<br />
* [9:00am - 9:40am] Users / Operators adoption of QA tools / plugins - https://etherpad.openstack.org/p/BOS-forum-qa-tools-plugins<br />
* [9:50am-10:30am] - Writing Applications for the VM and Baremetal Platform - https://etherpad.openstack.org/p/BOS-forum-using-vm-and-baremetal<br />
* [9:50am-10:30am] - Strategy for Unanswered Requirements - https://etherpad.openstack.org/p/BOS-forum-unanswered-requirements<br />
* [11:00am-12:30pm] Queens Goals - https://etherpad.openstack.org/p/BOS-forum-Queens-Goals<br />
* [11:00am - 11:40] Zun Developer/Operator Feedback - https://etherpad.openstack.org/p/BOS-forum-zun-developer-operator-feedback<br />
* [11:00am - 11:40] High Availability in OpenStack - https://etherpad.openstack.org/p/BOS-forum-HA-in-openstack<br />
* [11:50am-12:30pm] Shared Commercial Goals for OpenStack Public Cloud Providers - https://etherpad.openstack.org/p/BOS-forum-Shared-Commercial-Goals-Public-Clouds<br />
* [11:50am-12:30pm] LCOO Get to know us at the Boston Summit - https://etherpad.openstack.org/p/BOS-forum-LCOOGetToKnow<br />
* [11:50am-12:30pm] Achieving Resiliency at Scales of 1000+ - https://etherpad.openstack.org/p/Achieving_Resiliency_at_Scales_of_1000+<br />
* [1:30pm-2:10pm] User Committee Session - https://etherpad.openstack.org/p/BOS-forum-user-committee-session<br />
* [2:20pm-3:00pm] Cloud-aware Application Support - https://etherpad.openstack.org/p/pike-forum-cloud-applications<br />
* [5:00pm-5:40pm] UC Governance and Support of WGs - https://etherpad.openstack.org/p/BOS-forum-uc-governance-and-support-of-wgs<br />
<br />
<br />
==Thursday Afternoon session sign-up==<br />
If something new comes up during the week, or a session runs over and you need more time, please sign up for another Fishbowl slot on Thursday Afternoon here:<br />
<br />
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3"><br />
* 1:30-2:10 MR102 - Continuing the discussion from container deployment session https://etherpad.openstack.org/p/boston-deploying-openstack-on-k8s<br />
* 2:20-3:00 MR102 - Swift Rebalance Optimizations https://etherpad.openstack.org/p/swift-rebalance<br />
* <s>3:10-3:50 MR102</s><br />
* <s>3:50-4:10 MR102</s><br />
* <s>4:10-4:50 MR102</s><br />
* <s>5:00-5:40 MR102</s><br />
* 1:30-2:10 MR103 - available<br />
* 2:20-3:00 MR103 - [https://etherpad.openstack.org/p/pike-forum-cloud-applications Cloud-aware Application Support]<br />
* <s>3:10-3:50 MR103</s><br />
* <s>3:50-4:10 MR103</s><br />
* <s>4:10-4:50 MR103</s><br />
* <s>5:00-5:40 MR103</s><br />
* 1:30-2:10 MR104 - Discussion of use cases for alternate messaging technology with oslo.messaging https://etherpad.openstack.org/p/BOS_Forum_Oslo.Messaging_driver_recommendations<br />
* 2:20-3:00 MR104 - available<br />
* 3:10-3:50 MR104 - available<br />
* 3:50-4:10 MR104 - available<br />
* 4:10-4:50 MR104 - available<br />
* 5:00-5:40 MR104 - [https://etherpad.openstack.org/p/pike-forum-tc-gathering TC members open gathering]<br />
</div><br />
<br />
<br />
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░<br />
<br />
==(old) Brainstorming==<br />
Below here were the etherpads used during the agenda brainstorming process...<br />
<br />
====Catch-alls====<br />
* [https://etherpad.openstack.org/p/BOS-TC-brainstorming TC Catch-all]<br />
* [https://etherpad.openstack.org/p/BOS-UC-brainstorming UC Catch-all]<br />
<br />
====Project Teams====<br />
<br />
=====Barbican=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Barbican-brainstorming<br />
<br />
=====Cinder=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Cinder-brainstorming<br />
<br />
=====Freezer=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Freezer-brainstorming<br />
<br />
=====Glance=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Glance-brainstorming<br />
<br />
=====Heat=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Heat-brainstorming<br />
<br />
=====I18n=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-I18n-brainstorming<br />
<br />
=====Ironic=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-ironic-brainstorming<br />
<br />
=====Keystone=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Keystone-brainstorming<br />
<br />
=====Nova=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Nova-brainstorming<br />
<br />
=====Oslo=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Oslo-brainstorming<br />
<br />
=====Watcher=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Watcher-brainstorming<br />
<br />
=====QA=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-QA-brainstorming<br />
<br />
=====Swift=====<br />
Brainstorming: https://etherpad.openstack.org/p/BOS-Swift-brainstorming<br />
<br />
====UC Working Groups ====<br />
<br />
<br />
<br />
=====Telecom/NFV Requirements=====<br />
https://etherpad.openstack.org/p/BOS-UC-brainstorming-Telecom&NFV<br />
<br />
=====Scientific WG=====<br />
https://etherpad.openstack.org/p/BOS-UC-brainstorming-scientific-wg<br />
<br />
=====Massively Distributed (Fog/Edge) WG=====<br />
https://etherpad.openstack.org/p/BOS-UC-brainstorming-MassivelyDistributed-Fog-Edge<br />
<br />
=====Public Cloud WG=====<br />
https://etherpad.openstack.org/p/publiccloud-boston-forum-session<br />
<br />
====Other Working Groups====<br />
<br />
=====VM and Bare-metal platform group=====<br />
<br />
Developer lead group looking for user and operator feedback around the user experience across Nova, Ironic, Cinder and Neutron. Looking at both humans using the system, those operating the system, and projects building on the "VM and Bare-metal" platform. Main activity will be ranking the relative priority of current efforts, and looking to identify any gaps.<br />
<br />
https://etherpad.openstack.org/p/BOS-TC-vm-baremetal-platform</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=CrossProjectLiaisons&diff=142280CrossProjectLiaisons2016-11-21T21:11:27Z<p>Arkady: /* Product Working Group */</p>
<hr />
<div>Many of our cross-project teams need focused help for communicating with the other project teams. This page lists the people who have volunteered for that work.<br />
<br />
== Oslo ==<br />
<br />
There are now more projects consuming code from the Oslo incubator than we have Oslo contributors. That means we are going to need your help to make these migrations happen. We are asking for one person from each project to serve as a liaison between the project and Oslo, and to assist with integrating changes as we move code out of the incubator into libraries.<br />
<br />
* The liaison should be active in the project and familiar with the project-specific requirements for having patches accepted, but does not need to be a core reviewer or the PTL.<br />
* The liaison should be prepared to assist with writing and reviewing patches in their project as libraries are adopted, and with discussions of API changes to the libraries to make them easier to use within the project.<br />
* Liaisons should pay attention to [Oslo] tagged messages on the openstack-dev mailing list.<br />
* It is also useful for liaisons to be able to attend the Oslo team meeting ([[Meetings/Oslo]]) to participate in discussions and raise issues for real-time discussion.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Douglas Mendizábal || redrobot<br />
|-<br />
| Ceilometer || Julien Danjou || jd__<br />
|-<br />
| Cinder || Jay Bryant || jungleboyj<br />
|-<br />
| Congress || Tim Hinrichs || thinrichs<br />
|-<br />
| Cue || Min Pae || sputnik13<br />
|-<br />
| Designate || || <br />
|-<br />
| Freezer || Saad Zaher || szaher<br />
|-<br />
| Glance || Flavio Percoco || flaper87<br />
|-<br />
| Heat || Thomas Herve || therve<br />
|-<br />
| Horizon || Kirill Zaitsev || kzaitsev_<br />
|-<br />
| Ironic || Ruby Loo || rloo<br />
|-<br />
| Keystone || Brant Knudson || bknudson<br />
|-<br />
| Manila || Thomas Bechtold || toabctl<br />
|-<br />
| Mistral || Renat Akhmerov || rakhmerov<br />
|-<br />
| Murano || || <br />
|-<br />
| Neutron || Armando Migliaccio || armax<br />
|-<br />
| Nova || ChangBo Guo <glongwave@gmail.com> || gcb<br />
|-<br />
| [[Octavia]] || Michael Johnson || johnsom<br />
|-<br />
| Sahara || Huichun Lu, Ethan Gafford || huichun, egafford<br />
|-<br />
| Senlin || Yanyan Hu || Yanyanhu<br />
|-<br />
<br />
| Swift || || <br />
|-<br />
| TripleO || Ben Nemec || bnemec<br />
|-<br />
| Trove || Amrith Kumar || amrith<br />
|-<br />
| Zaqar || Flavio Percoco || flaper87<br />
|-<br />
|}<br />
<br />
== Release management ==<br />
<br />
The Release Management Liaison is responsible for communication with the Release Management team. Its tasks are described in the project team guide: http://docs.openstack.org/project-team-guide/release-management.html . That task has been traditionally filled by the PTL, but they may now delegate this task if they wish.<br />
<br />
* By default, the liaison will be the PTL.<br />
* The liaison may further delegate work to other subject matter experts<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Dave McCowan || dave-mccowan<br />
|-<br />
| Ceilometer || gordon chung || gordc<br />
|-<br />
| Cinder || Sean McGinnis || smcginnis<br />
|-<br />
| Congress || Tim Hinrichs || thinrichs<br />
|-<br />
| Designate || Graham Hayes || mugsie<br />
|-<br />
| Freezer || Pierre Mathieu || slashme<br />
|-<br />
| Glance || Ian Cordasco || sigmavirus<br />
|-<br />
| Heat || Thomas Herve || therve<br />
|-<br />
| Horizon || David Lyle || david-lyle<br />
|-<br />
| Ironic || Dmitry Tantsur || dtantsur<br />
|-<br />
| Keystone || Steve Martinelli || stevemar<br />
|-<br />
| Kolla || Jeffrey Zhang || Jeffrey4l<br />
|-<br />
| Magnum || Adrian Otto || adrian_otto<br />
|-<br />
| Manila || Ben Swartzlander || bswartz<br />
|-<br />
| Mistral || Lingxian Kong || kong<br />
|-<br />
| Murano ||Kirill Zaitsev || kzaitsev_<br />
|-<br />
| Neutron || Dariusz Smigiel || dasm<br />
|-<br />
| Nova || Sylvain Bauza || bauzas<br />
|-<br />
| OpenStack-Ansible || Jean-Philippe Evrard || evrardjp<br />
|-<br />
| Oslo || Joshua Harlow || harlowja<br />
|-<br />
| PuppetOpenStack || Alex Schultz || mwhahaha<br />
|-<br />
| Sahara || Vitaly Gridnev || vgridnev<br />
|-<br />
| Searchlight || Steve McLellan || sjmc7<br />
|-<br />
| Senlin || Qiming Teng || Qiming<br />
|-<br />
| Solum || Devdatta Kulkarni || devkulkarni<br />
|-<br />
| Swift || John Dickinson || notmyname<br />
|-<br />
| TripleO || Emilien Macchi || EmilienM<br />
|-<br />
| Trove || Amrith Kumar || amrith<br />
|-<br />
| Watcher || Antoine Cabot || acabot<br />
|-<br />
| Winstackers || Claudiu Belu || claudiub<br />
|-<br />
| Zaqar || Fei Long Wang || flwang <br />
|}<br />
<br />
== QA ==<br />
<br />
There are now more projects that are being tested by Tempest, and Grenade or a part deployable by Devstack than we have QA contributors. That means we are going to need your help to keep on top of everything. We are asking for one person from each project to serve as a liaison between the project and QA, and to assist with integrating changes as we move forward.<br />
<br />
The liaison should be a core reviewer for the project, but does not need to be the PTL. The liaison should be prepared to assist with writing and reviewing patches that interact with their project, and with discussions of changes to the QA projects to make them easier to use within the project.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Steve Heyman || hockeynut <br />
|-<br />
| Ceilometer || Chris Dent || cdent<br />
|-<br />
| Cinder || Scott DAngelo and Ivan Kolodyazhny || scottda and e0ne<br />
|-<br />
| Congress || Tim Hinrichs || thinrichs<br />
|-<br />
| Freezer || Guillermo Garcia || m3mo<br />
|-<br />
| Glance || Nikhil Komawar || nikhil<br />
|-<br />
| Heat || Steve Baker || stevebaker<br />
|-<br />
| Horizon || Timur Sufiev || tsufiev<br />
|-<br />
| Ironic || John Villalovos || jlvillal<br />
|-<br />
| Keystone || David Stanek || dstanek<br />
|-<br />
| Manila || Valeriy Ponomaryov || vponomaryov<br />
|-<br />
| Murano || Victor Ryzhenkin || freerunner<br />
|-<br />
| Neutron || Salvatore Orlando || salv-orlando<br />
|-<br />
| Nova || Matt Riedemann || mriedem<br />
|-<br />
| Oslo || Davanum Srinivas || dims <br />
|-<br />
| Sahara || Luigi Toscano || tosky<br />
|-<br />
| Senlin || Haiwei Xu || haiwei-xu<br />
|-<br />
| Swift || Thiago da Silva || tdasilva<br />
|-<br />
| Trove || Craig Vyvial and Nirav Shah || cp16net and nshah<br />
|-<br />
| Zaqar || Fei Long Wang || flwang <br />
|}<br />
<br />
== Documentation ==<br />
<br />
The OpenStack Documentation is centralized on docs.openstack.org but often there's a need for specialty information when reviewing patches or triaging doc bugs. A doc liaison should be available to triage doc bugs when the docs team members don't know enough to triage accurately, and be added to doc reviews that affect your project. You'd be notified through email when you're added either to a doc bug or a doc review. We also would appreciate attendance at the [https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting weekly doc team meeting], We meet weekly in #openstack-meeting every Wednesday at alternating times for different timezones:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Douglas Mendizábal || redrobot <br />
|-<br />
| Ceilometer || Ildiko Vancsa || ildikov<br />
|-<br />
| Cinder || Sean Mcginnis || smcginnis <br />
|-<br />
| Congress || Tim Hinrichs || thinrichs <br />
|-<br />
| Designate || Graham Hayes || mugsie<br />
|-<br />
| Freezer || Guillermo Garcia || m3mo<br />
|-<br />
| Glance || Alexander Bashmakov || abashmak<br />
|-<br />
| Heat || Randall Burt || randallburt<br />
|-<br />
| Horizon || Rob Cresswell || robcresswell<br />
|-<br />
| I18n || KATO Tomoyuki || katomo<br />
|-<br />
| Ironic || Jay Faulkner || JayF<br />
|-<br />
| Keystone || Lance Bragstad || lbragstad<br />
|-<br />
| Kolla || Steven Dake || sdake<br />
|-<br />
| Magnum || Spyros Trigazis || strigazi<br />
|-<br />
| Manila || Ben Swartzlander || bswartz<br />
|-<br />
| Mistral || Renat Akhmerov || rakhmerov<br />
|-<br />
| Murano || Kirill Zaitsev || kzaitsev_<br />
|-<br />
| Neutron || Matthew Kassawara || Sam-I-Am <br />
|-<br />
| Nova || Michael Still and Sean Dague (api-ref and api-guide) || mikal and sdague<br />
|-<br />
| OpenStack-Ansible || Alexandra Settle || asettle<br />
|-<br />
| Ops || Robert Starmer || <br />
|-<br />
| Oslo || Doug Hellmann || dhellmann<br />
|-<br />
| Puppet OpenStack || Emilien Macchi || EmilienM<br />
|-<br />
| Rally || Boris Pavlovic || boris-42<br />
|-<br />
| Sahara || Chad Roberts, Michael Ionkin || crobertsrh mionkin<br />
|-<br />
| Senlin || Cindia Blue || lixinhui<br />
|-<br />
| Swift || John Dickinson || notmyname<br />
|-<br />
| Tripleo || Steven Hardy || shardy<br />
|-<br />
| Trove || Laurel Michaels || laurelm<br />
|-<br />
| Watcher || Antoine Cabot || acabot<br />
|-<br />
| Zaqar || Fei Long Wang || flwang<br />
|}<br />
<br />
== Stable Branch ==<br />
<br />
The Stable Branch Liaison is responsible for making sure backports are proposed for critical issues in their project, and make sure proposed backports<br />
are reviewed. They are also the contact point for stable branch release managers around point release times.<br />
<br />
* By default, the liaison will be the PTL.<br />
* The Stable Branch Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in its PTL election.<br />
* The liaison may further delegate work to other subject matter experts<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Dave McCowan || dave-mccowan<br />
|-<br />
| Ceilometer || Eoghan Glynn || eglynn<br />
|-<br />
| Cinder || Jay Bryant || jungleboyj<br />
|-<br />
| Congress || Masahito Muroi || masahito<br />
|-<br />
| Freezer || Pierre Mathieu || slashme<br />
|-<br />
| Heat || Zane Bitter || zaneb<br />
|-<br />
| Horizon || Matthias Runge || mrunge <br />
|-<br />
| Ironic || Dmitry Tantsur || dtantsur <br />
|-<br />
| Keystone || Dolph Mathews || dolphm<br />
|-<br />
| Mistral || Renat Akhmerov || rakhmerov<br />
|-<br />
| Murano || Kirill Zaitsev || kzaitsev_<br />
|-<br />
| Neutron || Ihar Hrachyshka || ihrachys<br />
|-<br />
| Nova || Matt Riedemann || mriedem <br />
|-<br />
| Sahara || Vitaly Gridnev || vgridnev <br />
|-<br />
| Senlin|| Qiming Teng || Qiming<br />
|-<br />
| Swift || Matthew Oliver || mattoliverau <br />
|-<br />
| Trove || Amrith Kumar || amrith<br />
|-<br />
| Watcher || David Tardivel || dtardivel<br />
|-<br />
| Zaqar || Fei Long Wang || flwang<br />
|-<br />
|}<br />
<br />
== Vulnerability management ==<br />
<br />
The Vulnerability Management Team needs domain specialists to help assessing the impact of reported issues, coordinate the development of patches, review proposed patches and propose backports. The liaison should be familiar with the [https://security.openstack.org/vmt-process.html Vulnerability Management process] and embargo rules, and have a good grasp of security issues in software design.<br />
<br />
* The liaison should be a core reviewer for the project, but does not need to be the PTL.<br />
* By default, the liaison will be the PTL.<br />
* The liaison is the first line of contact for the Vulnerability Management team members<br />
* The liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL<br />
* The liaison may further delegate work to other subject matter experts<br />
* The liaison maintains the members of the $PROJECT-coresec team in Launchpad (which can be given access to embargoed vulnerabilities)<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Douglas Mendizábal or Charles Neill || redrobot / ccneill<br />
|-<br />
| Ceilometer || Lianhao Lu or Gordon Chung || llu/gordc <br />
|-<br />
| Cinder || || <br />
|-<br />
| Congress || Masahito Muroi || masahito <br />
|-<br />
| Glance || Hemanth Makkapati or Nikhil Komawar || hemanthm or nikhil <br />
|-<br />
| Heat || Steve Hardy || shardy<br />
|-<br />
| Horizon || Rob Cresswell || robcresswell<br />
|-<br />
| Ironic || Jay Faulkner || JayF<br />
|-<br />
| Keystone || Dolph Mathews || dolphm<br />
|-<br />
| Kolla || Steven Dake || sdake<br />
|-<br />
| Murano || Victor Ryzhenkin || freerunner<br />
|-<br />
| Neutron || Salvatore Orlando || salv-orlando<br />
|-<br />
| Nova || Michael Still || mikal<br />
|-<br />
| Sahara || Michael McCune, Vitaly Gridnev || elmiko vgridnev<br />
|-<br />
| Searchlight || Travis Tripp or Steve McLellan || TravT or sjmc7<br />
|-<br />
| Senlin || Qiming Teng || Qiming<br />
|-<br />
| Swift || || <br />
|-<br />
| Trove || Amrith Kumar, Craig Vyvial or Nikhil Manchanda || amrith, cp16net or SlickNik <br />
|-<br />
| Zaqar || Fei Long Wang || flwang <br />
|-<br />
|}<br />
<br />
== API Working Group ==<br />
<br />
The [[API_Working_Group|API Working Group]] seeks API subject matter experts for each project to communicate plans for API updates, review API guidelines with their project's view in mind, and review the API Working Group guidelines as they are drafted. The liaison should be familiar with the project's REST API design and future planning for changes to it.<br />
<br />
The members of the [http://specs.openstack.org/openstack/api-wg/liaisons.html API Working Group Cross-Project Liaisons] are maintained in our repo. If you want to read the entire list of CPLs or add/remove yourself from the list, you'll need to update the [http://git.openstack.org/cgit/openstack/api-wg/tree/doc/source/liaisons.json liaisons.json] file. If you don't want to make the update yourself, please ask in #openstack-sdks on IRC and someone can make the change for you.<br />
<br />
== Logging Working Group ==<br />
<br />
The [[LogWorkingGroup|Log Working Group]] seeks experts for each project to assist with making the logging in projects match the new [http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html Logging Guidelines]<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Glance || Erno Kuvaja || jokke_<br />
|-<br />
| Oslo || Doug Hellmann || dhellmann<br />
|-<br />
| Nova || John Garbutt || johnthetubaguy<br />
|-<br />
| Murano || ||<br />
|-<br />
| Sahara || Ethan Gafford || egafford<br />
|}<br />
<br />
== Infra ==<br />
<br />
These are the project specific groups of people that Infra will look to ACK changes to that project's test configuration. Changes to project-config and devstack-gate should be +1'd by these groups when they are related to their project. Note that in an emergency this may not always be possible and Infra will ask for forgiveness but generally we should look for these +1s.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Glance || Flavio Percoco, Nikhil Komawar|| flaper87, nikhil<br />
|-<br />
| Ironic || Dmitry Tantsur, Jim Rollenhagen || dtantsur, jroll<br />
|-<br />
| Kolla || Any Kolla Core Reviewer may ack an infra change on behalf of the PTL || pbourke, sdake are primary contacts<br />
|-<br />
| Neutron || Nate Johnston, Armando Migliaccio, Doug Wiegley|| njohnston, armax, dougwig<br />
|-<br />
| Documentation || Andreas Jaeger|| AJaeger<br />
<br />
|-<br />
| Trove || Amrith Kumar, Nikhil Manchanda || amrith, SlickNik<br />
<br />
|-<br />
| Murano || Victor Ryzhenkin || freerunner<br />
<br />
|-<br />
| Sahara || Sergey Lukjanov || SergeyLukjanov<br />
<br />
|-<br />
| Fuel || Aleksandra Fedorova, Igor Belikov || bookwar, igorbelikov<br />
<br />
|-<br />
| Puppet OpenStack || Emilien Macchi || EmilienM<br />
|}<br />
<br />
== Product Working Group ==<br />
The product working group consists of product managers, technologists, and operators from a diverse set of organizations. The group is working to aggregate user stories from the market-focused teams (Enterprise, Telco, etc.) and cross-project functional teams (e.g. logging, upgrades, etc.), partner with the development community on resourcing, and help gather data to generate a multi-release roadmap. Most of the user stories being tracked by this team consists of items that can span multiple releases and usually have cross-project dependencies. <br />
<br />
More information about the team can be found on the [[ProductTeam|Product WG wiki]].<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Ceilometer ||Krish Ragurham || <br />
|-<br />
| Cinder || Shamail Tahir || shamail<br />
|-<br />
| Glance || Nate Ziemann || nate_zman<br />
|-<br />
| Horizon || Carol Barrett || carolbarrett<br />
|-<br />
| Ironic || Yih Leong Sun || leong<br />
|-<br />
| Keystone || Megan Rossetti, Krish Raguram|| MeganR, KrishR<br />
|-<br />
| Kolla || Carol Barrett || barrett1<br />
|-<br />
| Magnum || Steve Gordon || sgordon<br />
|-<br />
| Manila ||Pete Chadwick || pchadwick<br />
|-<br />
| Neutron || Mike Cohen, Duane DeCapite || DuaneDeC7<br />
|-<br />
| Nova || Hugh Blemings || hughhalf <br />
|-<br />
| OSClient || Megan Rossetti || MeganR<br />
|-<br />
| Stable Release|| Rochelle Grober || rockig<br />
|-<br />
| QA || Arkady Kanevsky || arkady_kanevsky<br />
|-<br />
| Rally || Arkady Kanevsky || arkady_kanevsky<br />
|-<br />
| Sahara || Ethan Gafford || egafford<br />
|-<br />
| Senlin || Qiming Teng || Qiming<br />
|-<br />
| Swift || Phil Williams || philipw<br />
|-<br />
| Tempest || Arkady Kanevsky || arkady_kanevsky<br />
|-<br />
| Trove || Amrith Kumar || amrith<br />
|-<br />
|}<br />
<br />
== I18n ==<br />
I18n team is responsible for making OpenStack ubiquitously accessible to people of all language backgrounds. The team have translators from all over the world to translate OpenStack into different languages. <br />
<br />
If you want to communicate with translators in I18n team, send email to openstack-i18n@lists.openstack.org.<br />
<br />
* The liaison should be a core reviewer for the project and understand i18n status of the project.<br />
* The liaison should understand project release schedule very well.<br />
* The liaison should notify I18n team happens of important moments in the project release in time. For example, happen of soft string freeze, happen of hard string freeze, and happen of RC1 cutting.<br />
* The liaison should take care of translation patches to the project, and make sure the patches are successfully merged to the final release version. When the translation patch is failed, the liaison should notify I18n team.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Astara || || <br />
|-<br />
| Barbican || || <br />
|-<br />
| Cinder || || <br />
|-<br />
| Designate || Graham Hayes || mugsie<br />
|-<br />
| Glance || || <br />
|-<br />
| Heat || || <br />
|-<br />
| Horizon || Doug Fish / Akihiro Motoki || doug-fish / amotoki<br />
|-<br />
| Ironic || || <br />
|-<br />
| Keystone || || <br />
|-<br />
| Magnum || Shu Muto || shu-mutou<br />
|-<br />
| Manila || || <br />
|-<br />
| Monasca || || <br />
|-<br />
| Murano || || <br />
|-<br />
| Neutron || Akihiro Motoki || amotoki<br />
|-<br />
| Nova || Augustina Ragwitz || auggy <br />
|-<br />
| Oslo || || <br />
|-<br />
| Sahara || Nikita Konovalov || NikitaKonovalov<br />
|-<br />
| Senlin || || <br />
|-<br />
| Swift || ||<br />
|-<br />
| Tacker || || <br />
|-<br />
| Telemetry || || <br />
|-<br />
| Trove || || <br />
|-<br />
| Sahara || Chad Roberts || crobertsrh <br />
|-<br />
| Zaqar || || <br />
|-<br />
|}<br />
<br />
== Inter-project Liaisons ==<br />
<br />
In some cases, it is useful to have liaisons between projects. [http://lists.openstack.org/pipermail/openstack-dev/2015-April/062327.html For example, it is useful for the Nova and Neutron projects to have liaisons, because the projects have complex interactions and dependencies.] Ideally, a cross-project effort should have two members, one from each project, to facilitate communication and knowledge transfer.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Projects !! Name !! IRC Handle !! Role<br />
|-<br />
| Nova / Neutron || || ||<br />
|-<br />
| || Sean M. Collins || sc68cal || Neutron liaison for Nova<br />
|-<br />
| Nova / Glance || || ||<br />
|-<br />
| || Flavio Percoco, Mike Fedosin || flaper87, mfedosin || Glance liaison for Nova<br />
|-<br />
| || Jay Pipes || jaypipes || Nova liaison for Glance<br />
|-<br />
| Nova / Cinder || || ||<br />
|-<br />
| || Scott DAngelo || scottda || Cinder liaison for Nova<br />
|-<br />
| || Matt Riedemann || mriedem || Nova liason for Cinder<br />
|-<br />
| Nova / Ironic || John Villalovos || jlvillal || Ironic liaison for Nova<br />
|-<br />
| || Michael Davies || mrda || Ironic liaison for Nova<br />
|-<br />
| Neutron / Ironic || || ||<br />
|-<br />
| || Sukhdev Kapur || sukhdev || Neutron liaison for Ironic<br />
|-<br />
| || Sam Betts || sambetts || Ironic liaison for Neutron<br />
|-<br />
| Murano / Glance || || ||<br />
|-<br />
| || Alexander Tivelkov || ativelkov || Glance liaison for Murano, Murano liaison for Glance<br />
|-<br />
| Horizon / i18n || || ||<br />
|-<br />
| || Doug Fish || doug-fish || Horizon liaison for i18n<br />
|-<br />
| || TBD || || Heat liaison for Sahara<br />
|-<br />
| Sahara / Trove || || ||<br />
|-<br />
| || Ethan Gafford || egafford || Sahara liaison for Trove<br />
|-<br />
| || Amrith Kumar || amrith || Trove liaison for Sahara<br />
|-<br />
| Fuel / Puppet || || ||<br />
|-<br />
| || Alex Schultz || mwhahaha || Fuel liaison for Puppet<br />
|-<br />
| Fuel / Ironic || || ||<br />
|-<br />
| || Evgeny L || evgenyl || Fuel liaison for Ironic<br />
|-<br />
| Bareon / Ironic || || ||<br />
|-<br />
| || Evgeny L || evgenyl || Bareon liaison for Ironic<br />
|-<br />
| Magnum / Kuryr || || ||<br />
|-<br />
| || Ton Ngo || tango || Magnum liaison for Kuryr<br />
|-<br />
| || Fawad Khaliq || fawadkhaliq || Kuryr liaison for Magnum<br />
|}<br />
<br />
=== Etherpads ===<br />
<br />
The following is a list of etherpads that are used for inter-project liaisons, and are continuously updated.<br />
<br />
Nova - Neutron: https://etherpad.openstack.org/p/nova-neutron<br />
<br />
== Cross-Project Spec Liaisons ==<br />
<br />
The OpenStack project relies on the cross-project spec liaisons from each participating project to help with coordination and cross-project spec related tasks. See full set of [http://docs.openstack.org/project-team-guide/cross-project.html#cross-project-specification-liaisons responsibilities] The liaison defaults to the PTL, but the PTL can also delegate the responsibilities to someone else on the team by updating this tableː<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Astara|| Ryan Petrello || ryanpetrello<br />
|-<br />
| Barbican || Douglas Mendizabal || redrobot<br />
|-<br />
| Cinder || Kendall Nelson || diablo_rojo<br />
|-<br />
| Congress || Tim Hinrichs || thinrichs<br />
|-<br />
| Cue || Min Pae || sputnik13<br />
|-<br />
| Designate || Graham hayes || mugsie<br />
|-<br />
| Dragonflow || Gal Sagie || gsagie<br />
|-<br />
| Freezer || Pierre Mahieu || slashme<br />
|-<br />
| Fuel || Andrew Woodward || xarses<br />
|-<br />
| Glance || Nikhil Komawar || nikhil<br />
|-<br />
| Heat || Rico Lin || ricolin<br />
|-<br />
| Horizon || David Lyle || david-lyle<br />
|-<br />
| Infrastructure || Matthew Wagoner || olaph<br />
|-<br />
| Ironic || Jim Rollenhagen || jroll<br />
|-<br />
| Keystone || Samuel de Medeiros Queiroz || samueldmq<br />
|-<br />
| Kolla || Swapnil Kulkarni || coolsvap<br />
|-<br />
| Kuryr || Gal Sagie || gsagie<br />
|-<br />
| Magnum || Adrian Otto || adrian_otto<br />
|-<br />
| Manila || Ben Swartzlander || bswartz<br />
|-<br />
| Mistral || Renat Akhmerov || rakhmerov<br />
|-<br />
| Monasca || Roland Hochmuth || rhochmuth<br />
|-<br />
| Murano || Kirill Zaitsev || kzaitsev_<br />
|-<br />
| Neutron || Armando Migliaccio || armax<br />
|-<br />
| Nova || Chris Dent || cdent<br />
|-<br />
| OpenStack-Ansible || Travis Truman || automagically<br />
|-<br />
| Oslo || Davanum Srinivas || dims<br />
|-<br />
| Puppet OpenStack || Alex Schultz || mwhahaha<br />
|-<br />
| Sahara || Michael McCune, Vitaly Gridnev || elmiko vgridnev<br />
|-<br />
| Searchlight || Steve McLellan || sjmc7<br />
|-<br />
| Senlin || Qiming Teng || Qiming<br />
|-<br />
| Solum || Devdatta Kulkarni || devkulkarni<br />
|-<br />
| Swift || John Dickinson || notmyname<br />
|-<br />
| Tacker || Sridhar Ramaswamy || sridhar_ram<br />
|-<br />
| Telemetry || Gordon Chung || gordc<br />
|-<br />
| Trove || Amrith Kumar || amrith<br />
|-<br />
| Watcher || Susanne Balle || sballe <br />
|-<br />
| Zaqar || Fei Long Wang || flwang<br />
<br />
|}</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Design_Summit/Ocata/Etherpads&diff=136643Design Summit/Ocata/Etherpads2016-10-28T08:10:21Z<p>Arkady: added rally</p>
<hr />
<div>[[Category:Summit]]<br />
[[Category:Ocata]]<br />
[[Category:Etherpad]]<br />
<br />
The grand list of all the Ocata Design Summit sessions. Please include Date, Time, and links to etherpads when adding new content.<br />
<br />
<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3"><br />
__TOC__<br />
</div><br />
<br />
== Event intro/closure ==<br />
* Tue Oct 26 11:25am - Design Summit 101 - https://etherpad.openstack.org/p/ocata-design-summit-101<br />
* Fri Oct 29 12:30pm - Barcelona feedback session - https://etherpad.openstack.org/p/BCN-summit-feedback<br />
<br />
<br />
==Architecture Working Group==<br />
<br />
'''Wednesday, October 26'''<br />
* 11:25am-12:05pm - Cross Project workshops: Architecture Working Group Fishbowl - https://etherpad.openstack.org/p/ocata-summit-arch-wg<br />
<br />
==Barbican==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Barbican<br />
<br />
'''Thursday, October 27'''<br />
* 11:00am-11:40am - (128) Barbican: User and Operator Feedback Fishbowl - https://etherpad.openstack.org/p/barbican-ocata-summit-roadmap<br />
* 11:50am-12:30pm - (Montjuic) Barbican: Work Session (Roadmap) - https://etherpad.openstack.org/p/barbican-ocata-design-summit<br />
* 11:50pm-02:30pm - (130) Barbican: Work Session (Cross Project)- https://etherpad.openstack.org/p/barbican-ocata-design-summit<br />
<br />
'''Friday, October 28'''<br />
* 09:00am-09:40am - (129) Barbican: Work Session (Security) - https://etherpad.openstack.org/p/barbican-ocata-design-summit<br />
* 09:50am-10:30am - (129) Barbican: Work Session (TBD) - https://etherpad.openstack.org/p/barbican-ocata-design-summit<br />
* 11:00am-11:40am - (129) Barbican: Work Session (Resources) - https://etherpad.openstack.org/p/barbican-ocata-design-summit<br />
* 11:50am-12:30pm - (129) Barbican: Work Session (Planning) - https://etherpad.openstack.org/p/barbican-ocata-design-summit<br />
<br />
==Cinder==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Cinder<br />
<br />
'''Wednesday October 26'''<br />
* 3:05pm-3:45pm - Cinder Test Working Group progress and status - https://etherpad.openstack.org/p/Cinder-testing<br />
* 3:55-4:35 - Driver bug fixes for unsupported OpenStack releases - https://etherpad.openstack.org/p/ocata-cinder-summit-stabledriverfixes<br />
* 5:05-5:45 - Stand alone Cinder service - https://etherpad.openstack.org/p/ocata-cinder-summit-standalonecinder<br />
* 5:55-6:35 - Pike (and beyond) planning - https://etherpad.openstack.org/p/ocata-cinder-summit-pikeplanning<br />
'''Thursday October 27'''<br />
* 9:00-9:40 - Replication - https://etherpad.openstack.org/p/ocata-cinder-summit-replication<br />
* 9:50-10:30 - Cinder-Nova API changes - https://etherpad.openstack.org/p/ocata-cinder-summit-attachdetach<br />
'''Friday October 28'''<br />
* 9:00am-9:40am - Nova/Cinder cross-project session - https://etherpad.openstack.org/p/ocata-nova-summit-cinder-session<br />
* 11:00am-11:40am - NFS snapshots - https://etherpad.openstack.org/p/ocata-cinder-summit-nfssnapshots<br />
* 11:50am-12:30pm - Cinder backup improvements - https://etherpad.openstack.org/p/ocata-cinder-summit-backupimprovements<br />
* '''Lunch'''<br />
* 2:00pm-6:00pm - Contributors meetup - https://etherpad.openstack.org/p/ocata-cinder-summit-meetup<br />
<br />
==Cross Project Sessions==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Cross+Project<br />
<br />
'''Tuesday October 25'''<br />
<br />
* 3:55 PM - 4:35 PM -- Experiences with Project Decomposition, Scaling Review Teams and Subsystem Maintainers (Part 1) -- https://etherpad.openstack.org/p/ocata-summit-xp-scaling-review-teams<br />
* 3.55PM - 4.35 PM -- Cross-Service Communication -- https://etherpad.openstack.org/p/ocata-xp-cross-service-communication<br />
* 5:05 PM - 5:45 PM -- Discuss Community-Wide Release Goals -- https://etherpad.openstack.org/p/ocata-summit-xp-community-wide-goals <br />
* 5:05 PM - 5:45 PM -- Unified Capabilities Discovery API -- https://etherpad.openstack.org/p/ocata-xp-unified-capabilities-api<br />
* 5:55 PM - 6:35 PM -- Python 3 Integration Testing -- https://etherpad.openstack.org/p/ocata-python-3<br />
* 5:55 PM - 6:35 PM -- Where to Draw the Line for Proprietary Code with Drivers -- https://etherpad.openstack.org/p/ocata-xp-proprietary-drivers<br />
<br />
'''Wednesday October 26'''<br />
<br />
* 11:25 AM - 12:05 PM -- Architecture Working Group Fishbowl -- https://etherpad.openstack.org/p/BCN-architecture-wg<br />
* 11:25 AM - 12:05 PM -- Ocata goal: Remove Incubated Oslo Code -- https://etherpad.openstack.org/p/ocata-goal-oslo<br />
* 12:15 PM - 12:55 PM -- "Re-Inventing the TC", the Stewardship Working Group Discussion -- https://etherpad.openstack.org/p/Barcelona-SWG-cp<br />
* 12:15 PM - 12:55 PM -- Rolling Upgrades, and the Road to Zero-Downtime -- https://etherpad.openstack.org/p/ocata-xp-upgrades<br />
* 2:15 PM - 2:55 PM -- Experiences with project decomposition, scaling review teams and subsystem maintainers (part 2) -- https://etherpad.openstack.org/p/ocata-summit-xp-scaling-review-teams<br />
* 2:15 PM - 2:55 PM -- Driver Log Validation -- https://etherpad.openstack.org/p/driverlog-validation<br />
<br />
==Documentation==<br />
<br />
Documentation sessions in schedule: https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Documentation<br />
<br />
'''Tuesday, October 25'''<br />
* 5:05pm-6:35pm - Ops: Documentation - https://etherpad.openstack.org/p/BCN-ops-docs_(double_session)<br />
'''Wednesday, October 26'''<br />
* 5:05pm-5:45pm - User Guides Working Group - https://etherpad.openstack.org/p/BCN-Docs-UserGuidesWG<br />
'''Thursday October 27'''<br />
* 2:40pm-3:20pm - Newton Retrospective - https://etherpad.openstack.org/p/BCN-Docs-NewtonRetro <br />
* 3:30pm-4:10pm - Social Things - https://etherpad.openstack.org/p/BCN-Docs-Social <br />
* 4:40pm-5:20pm - Training Labs - https://etherpad.openstack.org/p/BCN-Docs-Training <br />
* 5:30pm-6:10pm - Toolchain - https://etherpad.openstack.org/p/BCN-Docs-Toolchain <br />
'''Friday October 28'''<br />
* 11:00am-11:40am - API Working Group - https://etherpad.openstack.org/p/BCN-Docs-APIWG <br />
* 11:50am-12:30pm - Ocata Planning Working Group - https://etherpad.openstack.org/p/BCN-Docs-OcataPlanningWG <br />
* 2:00pm-6:00pm - Contributors Meetup - no etherpad<br />
<br />
== Gluon ==<br />
<br />
View online: https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Gluon%3A<br />
<br />
Fri 28, 9:50am-10:30am: Gluon Work Session https://etherpad.openstack.org/p/ocata-gluon-work-plan<br />
<br />
==Heat==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Heat<br />
<br />
'''Thursday October 27'''<br />
<br />
* 11:00am-11:40am - Convergence Phase 1 - What worked, What didn't - https://etherpad.openstack.org/p/heat-ocata-convergence-phase-1<br />
* 11:50am-12:30pm - Performance Scalability Improvements - I (Issues with very large stacks) - https://etherpad.openstack.org/p/heat-ocata-performance-scalability-1<br />
* 2:40pm-3:20pm - Performance Scalability Improvements - II - https://etherpad.openstack.org/p/heat-ocata-performance-scalability-2<br />
* 3:30pm-4:10pm - Convergence Phase 2 - https://etherpad.openstack.org/p/heat-ocata-convergence-phase-2<br />
* 4:40pm-5:20pm - Validation Improvements - https://etherpad.openstack.org/p/heat-ocata-validation-improvements<br />
<br />
'''Friday October 28'''<br />
<br />
* 9:00am-9:40am - RPC versioning and hitless upgrades - https://etherpad.openstack.org/p/heat-ocata-hitless-upgrades<br />
* 9:50am-10:30am - API Microversions - https://etherpad.openstack.org/p/heat-ocata-api-microversions<br />
* 11:00am-11:40am - Heat Integration tests, Tempest and test candidates for DefCore Interop Testing - https://etherpad.openstack.org/p/heat-ocata-test-coverage<br />
* 11:50am-12:30pm - Improve maturity of heat - https://etherpad.openstack.org/p/heat-ocata-improve-maturity<br />
* 2:00pm-6:00pm - Contributors meetup - https://etherpad.openstack.org/p/ocata-heat-contributor-meetup<br />
<br />
<br />
==Horizon==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Horizon%3A<br />
<br />
'''Wednesday October 26'''<br />
<br />
* 16:55-17:35 - Cross-project meeting with Horizon and Keystone - https://etherpad.openstack.org/p/ocata-keystone-horizon<br />
<br />
'''Thursday October 27'''<br />
<br />
* 09:00-09:40 - Operator/ Plugin feedback - https://etherpad.openstack.org/p/horizon-ocata-feedback<br />
* 09:50-10:30 - Newton retrospective, Ocata timeline, Dependencies, Testing!! and Selenium :-( - https://etherpad.openstack.org/p/horizon-ocata-planning<br />
* 16:40-17:20 - Cross-project topics; Glance, Identity, K2K Federation, Quotas - https://etherpad.openstack.org/p/horizon-ocata-cross-project<br />
* 17:30-18:10 - AngularJS state of play (where we're going, status of panels, what CORS means, do we want a thin service proxy, deprecations, etc.) -https://etherpad.openstack.org/p/horizon-ocata-angularjs<br />
<br />
'''Friday October 28'''<br />
<br />
* 11:50-12:30 - Priority setting (and TODO review if we have time) - https://etherpad.openstack.org/p/horizon-ocata-priorities<br />
* 14:00-18:00 - General project discussion (Newton retrospective, how to improve our organisation and use of tooling)<br />
<br />
== I18n ==<br />
<br />
View online: https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=I18n%3A<br />
<br />
'''Friday October 28'''<br />
<br />
* 2:00pm-6:00pm - Contributors meetup - https://etherpad.openstack.org/p/barcelona-i18n-meetup<br />
<br />
==Infrastructure==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Infrastructure%3A<br />
<br />
'''Wednesday October 26'''<br />
<br />
* 3:05pm-3:45pm: ''Work Session: Firehose'' in AC Hotel - P3 - Montjuic<br />
** https://etherpad.openstack.org/p/ocata-infra-firehose<br />
<br />
'''Thursday October 27'''<br />
<br />
* 2:40pm-3:20pm: ''Fishbowl: Status update and plans for task tracking'' in AC Hotel - P1 - Salon Barcelona<br />
** https://etherpad.openstack.org/p/ocata-infra-community-task-tracking<br />
<br />
'''Friday October 28'''<br />
<br />
All the sessions on Friday are taking place at CCIB - Centre de Convencions Internacional de Barcelona - P1<br />
<br />
* 9:00am-9:40am: ''Work Session: Next steps for infra-cloud'' in Room 115<br />
** https://etherpad.openstack.org/p/ocata-infra-infra-cloud<br />
* 9:50am-10:30am: ''Work Session: Interactive infra-cloud debugging'' in Room 115<br />
** https://etherpad.openstack.org/p/ocata-infra-infra-cloud-debugging<br />
* 11:00am-11:40am: ''Work Session: Test environment expectations'' in Room 115<br />
** https://etherpad.openstack.org/p/ocata-infra-test-env-expectations<br />
* 11:50am-12:30pm: ''Work Session: Xenial jobs transition for stable/newton'' in Room 115<br />
** https://etherpad.openstack.org/p/ocata-infra-xenial-stable-newton<br />
* 2:00pm-6:00pm: ''Contributors Meetup'' in Room 121<br />
** https://etherpad.openstack.org/p/ocata-infra-contributors-meetup<br />
<br />
==Ironic==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Ironic:<br />
<br />
'''Wednesday October 26'''<br />
* 5ː05pm-5ː45pm - API Evolution - https://etherpad.openstack.org/p/ironic-ocata-summit-api-evolution<br />
* 5:55pm-6:35pm - Deploy-time RAID and Advanced Partitioning (w/ Nova) - https://etherpad.openstack.org/p/ironic-ocata-summit-deploy-time-raid<br />
'''Thursday October 27'''<br />
* 9:00am-9:40am - Task Framework - https://etherpad.openstack.org/p/ironic-ocata-summit-task-framework<br />
* 9:50am-10:30am - QA/CI - https://etherpad.openstack.org/p/ironic-ocata-summit-qa<br />
* 1:50pm-2:30pm - Synchronizing Events with Neutron - https://etherpad.openstack.org/p/ironic-ocata-summit-neutron-events<br />
* 2:40pm-3:20pm - Ocata Priorities - https://etherpad.openstack.org/p/ironic-ocata-summit-priorities<br />
'''Friday October 28'''<br />
* 11:00am-11:40am - VNC Console - https://etherpad.openstack.org/p/ironic-ocata-summit-vnc-console<br />
* 11:50am-12:30pm - Unblocking Priority Features - https://etherpad.openstack.org/p/ironic-ocata-summit-unblock-priorities<br />
* 2:00pm-6:00pm - Contributors Meetup - https://etherpad.openstack.org/p/ironic-ocata-summit-contributor-meetup<br />
<br />
<br />
== Karbor ==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Karbor<br />
<br />
'''Wednesday October 26'''<br />
* 5:05pm-5:45pm - Use Case Round Table - https://etherpad.openstack.org/p/karbor-ocata-use-cases<br />
'''Thursday October 27'''<br />
* 4:40pm-5:20pm - Ocata Roadmap - https://etherpad.openstack.org/p/karbor-ocata-roadmap<br />
'''Friday October 28'''<br />
* 9:00am-9:40am - Karbor Essentials and Internals - https://etherpad.openstack.org/p/karbor-ocata-essentials-internals<br />
* 9:50am-10:30am - Karbor Integration - https://etherpad.openstack.org/p/karbor-ocata-integration<br />
* 11:00am-11:40am - Cross-Site Backup and Restore - https://etherpad.openstack.org/p/karbor-ocata-cross-site<br />
* 11:50am-12:30pm - Additional Protectables - https://etherpad.openstack.org/p/karbor-ocata-additional-protectables<br />
<br />
<br />
== Keystone ==<br />
<br />
View online: https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Keystone%3A<br />
<br />
Wed 26, 3:05pm-3:45pm<br />
Keystone: Newton retrospective (Fishbowl)<br />
https://etherpad.openstack.org/p/keystone-newton-retrospective<br />
<br />
Wed 26, 3:55pm-4:35pm<br />
Keystone: keystone/horizon integration<br />
https://etherpad.openstack.org/p/ocata-keystone-horizon<br />
<br />
Thu 27, 11:00pm-11:40pm<br />
Keystone: Unconference (Fishbowl)<br />
https://etherpad.openstack.org/p/ocata-keystone-unconference<br />
<br />
Thu 27, 11:50pm-12:30pm<br />
Keystone: Ocata priorities (Fishbowl)<br />
https://etherpad.openstack.org/p/ocata-keystone-priorities<br />
<br />
Thu 27, 1:50pm-2:30pm<br />
Keystone: Work session (Federation)<br />
https://etherpad.openstack.org/p/ocata-keystone-federation<br />
<br />
Thu 27, 2:40pm-3:20pm<br />
Keystone: Work session (Testing)<br />
https://etherpad.openstack.org/p/ocata-keystone-testing<br />
<br />
Thu 27, 3:30pm-4:10pm<br />
Keystone: Work session (Documentation)<br />
https://etherpad.openstack.org/p/ocata-keystone-documentation<br />
<br />
Fri 28, 9:00am-9:40am<br />
Keystone: Work session (Authorization)<br />
https://etherpad.openstack.org/p/ocata-keystone-authorization<br />
<br />
Fri 28, 9:50am-10:30am<br />
Keystone: Work session (Authentication)<br />
https://etherpad.openstack.org/p/ocata-keystone-authentication<br />
<br />
Fri 28, 11:00pm-11:40pm<br />
Keystone: Work session (Scaling and Performance)<br />
https://etherpad.openstack.org/p/ocata-keystone-scaling<br />
<br />
Fri 28, 11:50pm-12:30pm<br />
Keystone: Work session (Integration)<br />
https://etherpad.openstack.org/p/ocata-keystone-integration<br />
<br />
Fri 28, 2:00pm-6:00pm<br />
Keystone: Contributors meetup<br />
(No etherpad)<br />
<br />
== Kolla ==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Kolla%3A<br />
<br />
Kolla Ocata Summit Master Etherpad - https://etherpad.openstack.org/p/kolla-o-summit-schedule<br />
<br />
'''Wed October 26'''<br />
<br />
* 3:55pm - 4:35pm - Operator experiences - https://etherpad.openstack.org/p/kolla-o-summit-op-experiences<br />
* 5:05pm - 5:45pm - Community roadmap planning for O - https://etherpad.openstack.org/p/kolla-o-summit-community-planning<br />
* 5:55pm - 6:35pm - Goals for Ocata - https://etherpad.openstack.org/p/kolla-o-summit-roadmap<br />
<br />
'''Thu October 27'''<br />
<br />
* 9:00am - 9:40am - Kolla-Kubernetes Architecture - https://etherpad.openstack.org/p/kolla-ocata-summit-kolla-k8s-architecture<br />
* 9:50am - 10:30am - High availability - https://etherpad.openstack.org/p/kolla-o-summit-high-availability<br />
* 1:50pm - 2:30pm - 3rd Party Plugins - https://etherpad.openstack.org/p/kolla-o-summit-3rd-party-plugins<br />
* 2:40pm - 3:20pm - Distro requirements, deprecation, levels of support - https://etherpad.openstack.org/p/kolla-o-summit-support-and-deprecation<br />
* 3:30pm - 4:10pm - Improving the CI system - https://etherpad.openstack.org/p/kolla-o-summit-improving-ci<br />
<br />
'''Fri April 28'''<br />
<br />
* 9:00am - 9:40am - Documentation - https://etherpad.openstack.org/p/kolla-o-summit-documentation<br />
* 9:50am - 10:30am - OSIC review - https://etherpad.openstack.org/p/kolla-o-summit-OSIC-review<br />
* 11:00am - 11:40am - Kolla-Kubernetes Roadmap - https://etherpad.openstack.org/p/kolla-ocata-summit-kolla-k8s-road-map<br />
* 11:50am - 12:30pm - Security VMT threat - https://etherpad.openstack.org/p/kolla-ocata-summit-threat-analysis<br />
* 2:00pm - 6:00pm - Afternoon Contributor Meetup - https://etherpad.openstack.org/p/kolla-ocata-summit-contrib-meetup<br />
<br />
==Manila==<br />
<br />
'''Thu October 27'''<br />
<br />
* 11:00 - 11:40 - Race Conditions (FB) - https://etherpad.openstack.org/p/ocata-manila-race-conditions<br />
* 11:50 - 12:30 - Data Service Jobs Table (FB) - https://etherpad.openstack.org/p/ocata-manila-data-service-jobs-table<br />
* 14:40 - 15:20 - High Availability (WS) - https://etherpad.openstack.org/p/ocata-manila-high-availability<br />
<br />
'''Fri April 28'''<br />
<br />
* 11:00 - 11:40 - Access Rules (WS) - https://etherpad.openstack.org/p/ocata-manila-access-rules<br />
* 11:50 - 12:30 - Tempest Direction (WS) - https://etherpad.openstack.org/p/ocata-manila-tempest-direction<br />
* 14:00 - 18:00 - Contributor Meetup (CM) - https://etherpad.openstack.org/p/ocata-manila-contributor-meetup<br />
<br />
==Monasca==<br />
<br />
'''Fri October 28'''<br />
<br />
* 9:00 - 9:40 - Multi-tenancy for logging - https://etherpad.openstack.org/p/monasca-ocata-log-multitenancy<br />
<br />
==Neutron==<br />
<br />
'''Wednesday October 26'''<br />
<br />
* 17:05 - 17:45 - Nova/Neutron cross-project session Nova - https://etherpad.openstack.org/p/ocata-nova-neutron-session<br />
* 17:55 - 18:35 - LBaaS retrospective and next steps - https://etherpad.openstack.org/p/ocata-neutron-octavia-lbaas-session<br />
<br />
'''Thursday October 27'''<br />
<br />
* 09:00 - 09:40 - Completing the Newton backlog - https://etherpad.openstack.org/p/ocata-neutron-core-newton-backlog<br />
* 09:50 - 10:30 - Upstream and dowstream CI and testing efforts - https://etherpad.openstack.org/p/ocata-neutron-testing<br />
* 11:00 - 11:40 - End user and operator feedback - https://etherpad.openstack.org/p/ocata-neutron-end-user-operator-feedback<br />
* 11:50 - 12:30 - Neutronclient retrospective and next steps - https://etherpad.openstack.org/p/ocata-neutron-client<br />
* 17:30 - 18:10 - Nova/Neutron cross-project session - https://etherpad.openstack.org/p/ocata-nova-neutron-session<br />
<br />
'''Friday October 28'''<br />
<br />
* 09:00 - 09:40 (Sagrada Familia) Fishbowl Neutron: Neutron-lib retrospective and next steps - https://etherpad.openstack.org/p/ocata-neutron-lib-next-steps<br />
* 09:50 - 10:30 (Sagrada Familia) Fishbowl Neutron: Neutron server: retrospective and next steps - https://etherpad.openstack.org/p/ocata-neutron-server-next<br />
* 11:00 - 11:40 (Sagrada Familia) Fishbowl Neutron: Neutron agents: retrospective and next steps - https://etherpad.openstack.org/p/ocata-neutron-agents<br />
* 11:50 - 12:30 (Sagrada Familia) Fishbowl Neutron: Stadium update - https://etherpad.openstack.org/p/ocata-nova-neutron-stadium<br />
* 14:00 - 18:00 (Room 114) Meetup Neutron: Contributors meetup - https://etherpad.openstack.org/p/ocata-neutron-contributor-meetup<br />
<br />
==Nomad==<br />
<br />
https://etherpad.openstack.org/p/nomad-ocata-design-session<br />
<br />
== Nova ==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Nova%3A<br />
<br />
'''Wednesday October 26'''<br />
* 5:05pm-5:45pm - Nova/Neutron cross-project session - https://etherpad.openstack.org/p/ocata-nova-neutron-session<br />
'''Thursday October 27'''<br />
* 9:00am-9:40am - Newton placement service retrospective - https://etherpad.openstack.org/p/ocata-nova-summit-placement-retrospective<br />
* 9:50am-10:30am - Scheduler / resource providers (quantitative) - https://etherpad.openstack.org/p/ocata-nova-summit-resource-providers-quantitative<br />
* '''Break'''<br />
* 11:00am-11:40am - Scheduler / resource provider traits (qualitative) - https://etherpad.openstack.org/p/ocata-nova-summit-resource-providers-qualitative<br />
* 11:50am-12:30pm - Organizing API work for Ocata - https://etherpad.openstack.org/p/ocata-nova-summit-api<br />
* '''Lunch'''<br />
* 1:50pm-2:30pm - Unconference - https://etherpad.openstack.org/p/ocata-nova-summit-unconference<br />
* 2:40pm-3:20pm - Cells v2 (scheduler, searchlight, multi-cell support) - https://etherpad.openstack.org/p/ocata-nova-summit-cellsv2-scheduler<br />
* 3:30pm-4:10pm - Cells v2 (quotas) - https://etherpad.openstack.org/p/ocata-nova-summit-cellsv2-quotas<br />
* '''Break'''<br />
* 4:40pm-5:20pm - Completing vendordata v2 - https://etherpad.openstack.org/p/ocata-nova-summit-vendoradatav2<br />
* 5:30pm-6:10pm - Nova/Neutron cross-project session - https://etherpad.openstack.org/p/ocata-nova-neutron-session<br />
'''Friday October 28'''<br />
* 9:00am-9:40am - Nova/Cinder cross-project session - https://etherpad.openstack.org/p/ocata-nova-summit-cinder-session<br />
* 9:50am-10:30am - Security specs and testing - https://etherpad.openstack.org/p/ocata-nova-summit-security<br />
* '''Break'''<br />
* 11:00am-11:40am - Planning the libvirt imagebackend refactor work - https://etherpad.openstack.org/p/ocata-nova-summit-libvirt-imagebackend<br />
* 11:50am-12:30pm - Ocata priorities and schedule - https://etherpad.openstack.org/p/ocata-nova-summit-priorities<br />
* '''Lunch'''<br />
* 2:00pm-6:00pm - Contributors meetup - https://etherpad.openstack.org/p/ocata-nova-summit-meetup<br />
<br />
== OpenStack-Ansible ==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=openstackansible%3A<br />
<br />
'''Wednesday October 26'''<br />
* 5:05pm-6:35pm - OpenStack-Ansible prioritization/work discussion - https://etherpad.openstack.org/p/ocata-osa-summit-work-prioritization<br />
'''Thursday October 27'''<br />
* 9:00am-9:40am - OpenStack-Ansible Newton cycle overview & Ocata preview- https://etherpad.openstack.org/p/ocata-osa-summit-overview<br />
* 9:50am-10:30am - How to get involved in OpenStack-Ansible - https://etherpad.openstack.org/p/ocata-osa-summit-onboarding<br />
* '''Break'''<br />
* 11:00am-12:30am - Upgrade improvements and discussion - https://etherpad.openstack.org/p/ocata-osa-summit-upgrades<br />
* '''Lunch'''<br />
* '''Break'''<br />
'''Friday October 28'''<br />
* 9:00am-9:40am - Inventory improvements/discussion - https://etherpad.openstack.org/p/ocata-osa-summit-inventory<br />
* 9:50am-10:30am - Testing/gating discussion - https://etherpad.openstack.org/p/ocata-osa-summit-testing<br />
* '''Break'''<br />
* 11:00am-11:40am - If we had a clean slate, what would we do differently - Ideas session - https://etherpad.openstack.org/p/ocata-osa-summit-cleanslate<br />
* 11:50am-12:30pm - Configuration/role discussion and improvements - https://etherpad.openstack.org/p/ocata-osa-summit-config<br />
* '''Lunch'''<br />
* 2:00pm-6:00pm - Contributors meetup - https://etherpad.openstack.org/p/ocata-osa-summit-contributors-meetup<br />
<br />
== Ops ==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Ops%3A<br />
<br />
'''Tuesday October 25'''<br />
<br />
3:05pm-3:45pm<br />
<br />
https://etherpad.openstack.org/p/BCN-ops-openstack-cli<br />
<br />
== Oslo ==<br />
<br />
'''Tuesday October 25'''<br />
<br />
3:05pm-3:45pm<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16217/live-from-oslo <br />
<br />
3:55pm-4:35pm<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/15683/message-routing-a-next-generation-alternative-to-rabbitmq<br />
<br />
'''Wednesday October 26'''<br />
<br />
11:25am-12:05pm<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16941/cross-project-workshops-ocata-goal-remove-incubated-oslo-code<br />
<br />
https://etherpad.openstack.org/p/ocata-goal-oslo<br />
<br />
'''Thursday October 27'''<br />
<br />
9:00am-9:40am<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16980/oslo-bring-your-library-ideas-any-ideas-welcome-2-for-1<br />
<br />
https://etherpad.openstack.org/p/ocata-oslo-bring-ideas<br />
<br />
11:00am-11:40am<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16969/oslo-deep-dive-into-implementation-of-the-amqp-1-0-driver<br />
<br />
https://etherpad.openstack.org/p/ocata-oslo-deep-dive-amqp1<br />
<br />
1:50pm-2:30pm<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16997/oslo-consistent-apis-across-different-oslo-messaging-backends<br />
<br />
https://etherpad.openstack.org/p/ocata-oslo-consistent-mq-backends<br />
<br />
2:40pm-3:20pm<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17124/oslo-work-session<br />
<br />
'''Friday October 28'''<br />
<br />
Work sessions:<br />
<br />
9:00am-9:40am<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17184/oslo-work-session<br />
<br />
https://etherpad.openstack.org/p/ocata-oslo-mq-perms<br />
<br />
9:50am-10:30am<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17185/oslo-work-session<br />
<br />
https://etherpad.openstack.org/p/ocata-oslo-policy-code<br />
<br />
11:00am-11:40am<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17186/oslo-work-session<br />
<br />
https://etherpad.openstack.org/p/ocata-oslo-zmq-deeper<br />
<br />
11:50am-12:30pm<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17187/oslo-work-session<br />
<br />
https://etherpad.openstack.org/p/ocata-oslo-jepsen<br />
<br />
Contributors meetup:<br />
<br />
2:00pm-6:00pm<br />
<br />
== Rally ==<br />
<br />
''' Friday October 28'''<br />
<br />
https://etherpad.openstack.org/p/rally-roadmap-ocata<br />
<br />
== Release Management ==<br />
<br />
'''Wednesday October 26'''<br />
<br />
* 5:55 PM - 6:35 PM -- Work session -- https://etherpad.openstack.org/p/ocata-relmgt-plan<br />
<br />
'''Thursday October 27'''<br />
<br />
* 1:50 PM - 2:30 PM -- Newton Retrospective & Ocata Schedule -- https://etherpad.openstack.org/p/ocata-release-fishbowl<br />
<br />
'''Friday October 28'''<br />
<br />
* 2:00 PM - 6:00 PM -- Contributors Meetup -- https://etherpad.openstack.org/p/ocata-relmgt-plan<br />
<br />
== RPM Packaging ==<br />
<br />
'''Thursday October 27'''<br />
<br />
* 4:40 PM - 5:20 PM -- Fishbowl -- https://etherpad.openstack.org/p/ocata-rpm-packaging-fishbowl<br />
<br />
'''Friday October 28'''<br />
<br />
* 9:00 AM - 10:30 AM -- Fishbowl -- https://etherpad.openstack.org/p/ocata-rpm-packaging-work-session<br />
<br />
== Searchlight ==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Searchlight<br />
<br />
'''Thursday October 27'''<br />
* 9:50 - 10:30 - Fishbowl: Adding service plugins to Searchlight and what it can add to UIs - https://etherpad.openstack.org/p/ocata-searchlight-summit-plugins-fishbowl<br />
* 11:00 - 11:40 - Improving ease of use for searching - https://etherpad.openstack.org/p/ocata-searchlight-summit-working-sessions<br />
* 11:50 - 12:30 - Error handling during notifications - https://etherpad.openstack.org/p/ocata-searchlight-summit-working-sessions<br />
* 2:40pm-3:20pm - Cells v2 (scheduler, searchlight, multi-cell support) - https://etherpad.openstack.org/p/ocata-nova-summit-cellsv2-scheduler<br />
<br />
== Senlin ==<br />
<br />
'''Friday October 28'''<br />
* 9:00am-9:40am - Senlin work session: policy/profile versioning - https://etherpad.openstack.org/p/ocata-summit-senlin-profile-policy-versioning<br />
* 9:50am-10:30am - Senlin work session: versioned everything - https://etherpad.openstack.org/p/ocata-summit-senlin-versioned-everything<br />
* '''Break'''<br />
* 11:00am-11:40am - Senlin work session: container cluster - https://etherpad.openstack.org/p/ocata-summit-senlin-container-cluster<br />
* 11:50am-12:30am - Senlin work session: HA - https://etherpad.openstack.org/p/ocata-summit-senlin-HA<br />
<br />
== Stewardship Working Group ==<br />
<br />
'''Wed October 26'''<br />
<br />
*12:15pm - 12:55pm - Cross Project workshops: "Re-inventing the TC", the Stewardship Working Group discussion - https://etherpad.openstack.org/p/Barcelona-SWG-cp<br />
<br />
== Telemetry ==<br />
<br />
'''Thursday October 27'''<br />
<br />
* 11:00am-11:40am – Deprecating Ceilometer API (part 1) – https://etherpad.openstack.org/p/ocata-summit-telemetry-deprecating-ceilometer-api<br />
* 11:50am-12:30pm – Deprecating Ceilometer API (part 2) – https://etherpad.openstack.org/p/ocata-summit-telemetry-deprecating-ceilometer-api<br />
* 1:50pm-2:30pm – Ceilometer roadmap – https://etherpad.openstack.org/p/ocata-summit-telemetry-ceilometer<br />
<br />
<br />
'''Friday October 28'''<br />
* 11:00am-11:40am – Aodh roadmap – https://etherpad.openstack.org/p/ocata-summit-telemetry-aodh<br />
* 11:50am-12:30pm – Gnocchi roadmap – https://etherpad.openstack.org/p/ocata-summit-telemetry-gnocchi<br />
<br />
<br />
== QA (Quality Assurance) ==<br />
<br />
'''Thursday October 27'''<br />
<br />
* 09:00am-09:40am - Workroom QA: Work session – https://etherpad.openstack.org/p/ocata-qa-tempest-cloud-testing<br />
* 09:50am-10:30am - (Devstack) devstack-plugin additional-pkg-repos – https://etherpad.openstack.org/p/ocata-qa-devstack-plugin<br />
* 11:00am-11:40am - (New project) Destructive testing (os-fault, etc) - https://etherpad.openstack.org/p/ocata-qa-destructive-testing<br />
* 13:50am-14:30am - (Tempest) Plugins: roadmap for the projects and TC proposal - https://etherpad.openstack.org/p/ocata-qa-tempest-plugin-repos<br />
* 16:40am-17:20am - (New project) Policy testing - https://etherpad.openstack.org/p/ocata-qa-policy-testing<br />
<br />
'''Friday October 28'''<br />
* 11:00am-11:40am - (OpenStack-Health) What should we add/chage features? - https://etherpad.openstack.org/p/ocata-qa-openstack-health<br />
* 11:50am-12:30am - Ocata Priorities - https://etherpad.openstack.org/p/ocata-qa-priorities<br />
<br />
== Tricircle ==<br />
<br />
Venue: https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=tricircle%3A<br />
<br />
ideas: https://etherpad.openstack.org/p/ocata-tricircle-sessions-planning<br />
<br />
'''Thu October 27'''<br />
<br />
* 5:30pm - 6:10pm - Cross Neutron networking automation: feature review and what's to do in Ocata : https://etherpad.openstack.org/p/ocata-tricircle-feature-review-priorities-roadmap<br />
<br />
'''Fri April 28'''<br />
<br />
* 9:00am - 9:40am - Ocata work session: https://etherpad.openstack.org/p/ocata-tricircle-work-session<br />
* 9:40am - 12:00am - Tricricle contributors meetup<br />
<br />
== TripleO ==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=tripleo%3A<br />
<br />
https://etherpad.openstack.org/p/ocata-tripleo<br />
<br />
===== TripleO: Containers - Current Status and Roadmap =====<br />
Wed 26 3:55pm-4:35pm<br />
https://etherpad.openstack.org/p/ocata-tripleo-containers<br />
<br />
=====TripleO: Work Session - Growing the team=====<br />
Wed 26 5:05pm-5:45pm -<br />
https://etherpad.openstack.org/p/ocata-tripleo-team-growing<br />
<br />
===== TripleO: Work Session - CI - current status and roadmap=====<br />
Wed 26 5:55pm-6:35pm -<br />
https://etherpad.openstack.org/p/ocata-tripleo-ci<br />
<br />
===== TripleO: Upgrades - current status and roadmap=====<br />
Thu 27 1:50pm-2:30pm -<br />
https://etherpad.openstack.org/p/ocata-tripleo-upgrades<br />
<br />
===== TripleO: Work Session - Composable Undercloud deployment with Heat=====<br />
Fri 28 9:00am-9:20am -<br />
https://etherpad.openstack.org/p/tripleo-composable-undercloud<br />
<br />
===== TripleO: Work Session - GUI, CLI, Validations current status, roadmap, requirements=====<br />
Fri 28 9:20am-9:40am -<br />
https://etherpad.openstack.org/p/gui-ocata<br />
<br />
===== TripleO: Work Session - Multiple topics=====<br />
Fri 28 9:50am-10:30am -<br />
Blueprints, specs, tools and Ocata summary.<br />
See bottom of https://etherpad.openstack.org/p/ocata-tripleo<br />
<br />
== Trove ==<br />
<br />
https://etherpad.openstack.org/p/trove-barcelona-sessions <br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Trove<br />
<br />
==Watcher==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Watcher<br />
<br />
'''Wed October 26'''<br />
<br />
* 5.55pm - 6.35pm - [https://etherpad.openstack.org/p/watcher-ocata-design-session Existing & new infrastructure optimization strategies]<br />
<br />
'''Thu October 27'''<br />
<br />
* 9.50am - 10.30am - [https://etherpad.openstack.org/p/watcher-ocata-design-session Watcher Newton retrospective]<br />
<br />
'''Fri April 28'''<br />
<br />
* 11am - 12.30am - [https://etherpad.openstack.org/p/watcher-ocata-design-session Ocata priorities & roadmap]<br />
* 2pm - 6pm - [https://etherpad.openstack.org/p/watcher-ocata-design-session Contributors meetup]<br />
<br />
==Zaqar==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Zaqar<br />
<br />
'''Thursday, October 27'''<br />
<br />
9:50am-10:30am [https://etherpad.openstack.org/p/zaqar-ocata-performance Zaqar's profile and performance gate]<br />
<br />
4:40pm-5:00pm [https://etherpad.openstack.org/p/zaqar-ocata-notification-delivery-policy Notification delivery policy]<br />
<br />
5:00pm-5:20pm [https://etherpad.openstack.org/p/zaqar-ocata-purge-queue Purge queue]<br />
<br />
5:30pm-6:10pm [https://etherpad.openstack.org/p/zaqar-ocata-subscription-confirmation-email Subscription Confirmation - Email]<br />
<br />
==Storlets==<br />
<br />
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Storlets<br />
<br />
https://etherpad.openstack.org/p/storlets-otaca-design-summit<br />
<br />
'''Wednesday, October 26'''<br />
<br />
3:05pm-3:45pm Spark-Storlets and Storlets Deep-Dive<br />
<br />
3:55pm-4:35pm [https://etherpad.openstack.org/p/storlets-ocata-work-session Work session]<br />
<br />
...</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=ProductTeam/MultiRelease_Roadmap&diff=124185ProductTeam/MultiRelease Roadmap2016-04-19T22:32:19Z<p>Arkady: add QA and Rally</p>
<hr />
<div>== Multi-Release Roadmap Sub-Team ==<br />
<br />
The Product Working Group, in partnership with the OpenStack Foundation, is building a multi-release directional view of the OpenStack cloud platform by collecting (and aggregating) feedback from multiple PTLs (Project Team Leads). The roadmap covers 20 projects as of the Mitaka release but this list will continue to expand over time. This wiki page will maintain a link to previous versions of the roadmap, team member information, explanation of the various "views" shown in the roadmap slides, and status for the upcoming roadmap refresh/release.<br />
<br />
==== <b>Next Roadmap Presentation: OpenStack Summit in Austin (April 26th, 2016)</b> ====<br />
Session details can be found on the [https://www.openstack.org/summit/austin-2016/summit-schedule/events/9029 OpenStack Summit Schedule]<br />
<br />
=== Disclaimer ===<br />
The information presented in the "roadmap slides" for information only. It is the authors’ interpretation of information collected and does not represent commitments for features or timelines by the projects or PTLs.<br />
<br />
As with any open-source project, items proposed by the team can be impacted by number of developers, hurdles, external forces, and change in direction… All decisions for the accepted blueprints/specs will ultimately be at the discretion of the project core teams. We can merely show a snapshot of a point-in-time in the projects’ evolution and the actual “delivery” of items may shift after that point-in-time. We will try our best to keep this snapshot updated.<br />
<br />
=== Previous Roadmap Presentations ===<br />
October 2015 (Liberty release; Mitaka Design Summit): [http://www.openstack.org/assets/tokyo-summit/OpenStack-Roadmap-Mitaka-Update.pptx OpenStack Community Generated Roadmap]<br />
<br>May 2015 (Kilo release; Liberty Design Summit): [http://www.slideshare.net/ShamailXD/a-glimpse-at-the-roadmap-deck-v5-final SlideShare]<br />
<br />
Note: Future versions of the roadmap presentation will be stored at [[https://www.openstack.org/roadmap OpenStack.org Roadmap Page]]<br />
<br />
=== Methodology ===<br />
The roadmap refresh team uses a questionnaire to collect feedback from the PTLs about the state of their projects. The roadmap refresh team engages with the developer community twice during a release cycle to refresh our understanding of current/future release plans after key release cycle milestones. The first questionnaire is sent out approximately 2-3 weeks after the design summit for the upcoming release and the primary focus of this engagement is to go back and update our understanding of what used to be the future release as it becomes the upcoming release. The second questionnaire is sent out after feature freeze for the current release cycle and we use this time to refresh our understanding of what actually made it into the upcoming release along with start building a view for the next couple of releases. <br />
<br />
<center>[[File:Pwgroadmaptimeline.png|center|Roadmap Refresh Milestones]]</center><br />
<br />
=== Product WG Cross-Project Liaisons ===<br />
The roadmap team consists of the Product WG cross project liaisons (CPL) and additional team members. If a project already has a CPL then that is the person who works with the project team to refresh the questionnaire data. If a project does not have an assigned Product WG CPL then one of the roadmap team members will contact the PTL.<br />
<br />
More information can be found on the Product WG Cross-Project Liaisons on [[CrossProjectLiaisons|this page]].<br />
<br />
=== Tracked OpenStack Projects and Status ===<br />
The "Liaison" column denotes a CPL if there is an asterisk next to the persons' name, otherwise the person is only helping with the collection of the roadmap data and is not the CPL.<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Project !! Liaison !! Status !! Additional Comments<br />
|-<br />
| Nova|| Hugh B.*|| Updated at Liberty FF|| <br />
|-<br />
| Neutron|| Mike C.*|| Updated at Liberty FF|| <br />
|-<br />
| Cinder|| Shamail T.*|| Updated at Liberty FF|| <br />
|-<br />
| Glance|| Nate Z.*|| Updated at Liberty FF|| <br />
|-<br />
| Keystone|| Sheena G.*|| Updated at Liberty FF|| <br />
|-<br />
| Heat|| Kenny J.|| Updated at Liberty FF|| <br />
|-<br />
| Swift|| Phil W.*|| Updated at Liberty FF|| <br />
|-<br />
| Trove|| Leong S.|| Updated at Liberty FF|| <br />
|-<br />
| Ceilometer|| Krish R.|| Updated at Liberty FF|| <br />
|-<br />
| Horizon|| Carol B.*|| Updated at Liberty FF|| <br />
|-<br />
| Ironic|| Shamail T.|| Updated at Liberty FF|| <br />
|-<br />
| Triple O|| Carol B.|| Updated at Liberty FF|| <br />
|-<br />
| Sahara|| Shamail T.|| Updated at Liberty FF|| <br />
|-<br />
| Manila|| Pete C.*|| Updated at Liberty FF|| <br />
|-<br />
| Oslo|| Sheena G.|| Updated at Liberty FF|| <br />
|-<br />
| OSClient|| Carol B.|| Updated at Liberty FF|| <br />
|-<br />
| Magnum|| Mike C.*|| Updated at Liberty FF|| <br />
|-<br />
| Kolla|| Carol B.*|| Updated at Liberty FF|| <br />
|-<br />
| Designate|| Kenny J.|| Updated at Liberty FF|| <br />
|-<br />
| Kuryr|| Shamail T.|| Updated at Liberty FF||<br />
|-<br />
| Rally|| Arkady K || Updated at Mitaka FF||<br />
|-<br />
| QA || Arkady K || Updated at Mitaka FF||<br />
|}<br />
<br />
Contact Information<br />
The best way to contact the roadmap sub-team is to post on the [http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg Product Working Group Mailing List] and add "[roadmap]" to your subject line.</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=Meetings/product-team&diff=124114Meetings/product-team2016-04-18T21:12:28Z<p>Arkady: added themes update to agenda for Monday call</p>
<hr />
<div>= April 18, 2016 Product Team Meeting Agenda =<br />
* Slide Deck review for Joint Board/TC Discussion (Carol, Shamail)<br />
** Slide Link: https://docs.google.com/presentation/d/1zD3sc90WtcdCIwOsCPIrY1fsEvmk1wHmUTFmRE8mChc/edit?usp=sharing<br />
** Session Info: https://wiki.openstack.org/wiki/Governance/Foundation/24Apr2016BoardMeeting<br />
**Link to SpreadSheet of WG Led Sessions: https://docs.google.com/spreadsheets/d/1Z5GbBueeE6sf1gpcrcYRZg-DqdrPda-VzkUami0zTiU/edit?usp=sharing<br />
* Content review for Cross-Project Design Session (Carol, Shamail)<br />
**Content Link: see Board/TC slides<br />
**Session Link: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9477<br />
**Split Summit Brainstorm Session Link: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9478<br />
* Agenda review for Product WG working session (All)<br />
**Content Link: https://etherpad.openstack.org/p/PWG_Austin_Working_Session_Planning<br />
**Session Link: https://www.openstack.org/summit/austin-2016/summit-schedule/events/8358<br />
* Agenda review for Product WG BoF (Carol)<br />
**Content Link: https://drive.google.com/open?id=1sv6ipcZ97mVBMRM70pLWK6c8mowXCQ8ntCSzTEkB4oc<br />
** Session Link: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9041<br />
*Community Roadmap Update (Shamail)<br />
** Content Link: https://drive.google.com/open?id=0B_yCSDGnhIbzTDZTN1lwT3A1M1E<br />
** Review Schedule: Review will occur at next roadmap sub-team meeting (Tuesday 4/19 @ 1800 UTC)<br />
*Community Roadmap Session Review (Carol, Hugh, Nate)<br />
**Content Link: https://drive.google.com/open?id=1OVDC9-u4fVM_XcfskMiVVutfsUHQO_gyML12u7_Ljis<br />
**Session Link: https://www.openstack.org/summit/austin-2016/summit-schedule/events/9029<br />
*Upcoming Meeting Plan (All)<br />
* Themes update session review (Pete, Arkady)<br />
** https://docs.google.com/presentation/d/1jAtkJVMYua7v9t0gaHJbwFMIvg-AuRLiDPzyX5f3YRg/edit#slide=id.g129bd00c3d_3_9<br />
**Cancel 4/25 and 5/2<br />
**IRC meetings resume on 5/9<br />
*Opens (All)<br />
** User Story Prioritization followup: https://etherpad.openstack.org/p/PWG_4_4_2016<br />
<br><br />
<br />
= April 19th, 2016 (UTC) Product Team Regional Meeting Agenda =<br />
* Action Item Review<br />
* Summary of Last Two PWG Meetings<br />
* Upcoming Meeting Plan<br />
* Opens<br />
<br><br><br />
<br />
''Information on previous agendas: https://etherpad.openstack.org/p/pwg_previous_agendas''</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=CrossProjectLiaisons&diff=99596CrossProjectLiaisons2015-12-14T21:31:54Z<p>Arkady: /* Product Working Group */</p>
<hr />
<div>Many of our cross-project teams need focused help for communicating with the other project teams. This page lists the people who have volunteered for that work.<br />
<br />
== Oslo ==<br />
<br />
There are now more projects consuming code from the Oslo incubator than we have Oslo contributors. That means we are going to need your help to make these migrations happen. We are asking for one person from each project to serve as a liaison between the project and Oslo, and to assist with integrating changes as we move code out of the incubator into libraries.<br />
<br />
* The liaison should be active in the project and familiar with the project-specific requirements for having patches accepted, but does not need to be a core reviewer or the PTL.<br />
* The liaison should be prepared to assist with writing and reviewing patches in their project as libraries are adopted, and with discussions of API changes to the libraries to make them easier to use within the project.<br />
* Liaisons should pay attention to [Oslo] tagged messages on the openstack-dev mailing list.<br />
* It is also useful for liaisons to be able to attend the Oslo team meeting ([[Meetings/Oslo]]) to participate in discussions and raise issues for real-time discussion.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Douglas Mendizábal || redrobot<br />
|-<br />
| Ceilometer || Julien Danjou || jd__<br />
|-<br />
| Cinder || Jay Bryant || jungleboyj<br />
|-<br />
| Congress || Tim Hinrichs || thinrichs<br />
|-<br />
| Cue || Min Pae || sputnik13<br />
|-<br />
| Designate || || <br />
|-<br />
| Glance || Flavio Percoco || flaper87<br />
|-<br />
| Heat || Thomas Herve || therve<br />
|-<br />
| Horizon || Kirill Zaitsev || kzaitsev_<br />
|-<br />
| Ironic || Lin Tan || lintan<br />
|-<br />
| Keystone || Brant Knudson || bknudson<br />
|-<br />
| Manila || Thomas Bechtold || toabctl<br />
|-<br />
| Murano || Kirill Zaitsev || kzaitsev_<br />
|-<br />
| Neutron || Ihar Hrachyshka || ihrachyshka<br />
|-<br />
| Nova || - | -<br />
|-<br />
| [[Octavia]] || Michael Johnson || johnsom<br />
|-<br />
| Sahara || Sergey Reshetnyak || sreshetnyak<br />
|-<br />
| Swift || || <br />
|-<br />
| TripleO || Ben Nemec || bnemec<br />
|-<br />
| Trove || Amrith Kumar || amrith<br />
|-<br />
| Zaqar || Flavio Percoco || flaper87<br />
|-<br />
|}<br />
<br />
== Release management ==<br />
<br />
The Release Management Liaison is responsible for communication with the Release Management team, attending the weekly 1:1 syncs in #openstack-relmgr-office, keeping milestone plans up to date, and signing off milestone and release tags. That task has been [[PTL_Guide#Interactions_with_the_Release_team|traditionally filled by the PTL]], but they may now delegate this task if they wish.<br />
<br />
* By default, the liaison will be the PTL.<br />
* The Release Management Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL.<br />
* The liaison may further delegate work to other subject matter experts<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Nova || John Garbutt || johnthetubaguy<br />
|-<br />
| Cinder || Sean McGinnis || smcginnis<br />
|-<br />
| Swift || John Dickinson || notmyname<br />
|-<br />
| Neutron || Kyle Mestery || mestery<br />
|-<br />
| Keystone || Steve Martinelli || stevemar<br />
|-<br />
| Horizon || David Lyle || david-lyle<br />
|-<br />
| Glance || Flavio Percoco || flaper87<br />
|-<br />
| Ceilometer || gordon chung || gordc<br />
|-<br />
| Heat || Sergey Kraynev || skraynev<br />
|-<br />
| Oslo || Davanum Srinivas || dims<br />
|-<br />
| Trove || Craig Vyvial or Nikhil Manchanda || cp16net or SlickNik<br />
|-<br />
| Sahara || Sergey Lukjanov || SergeyLukjanov<br />
|-<br />
| Ironic || Jim Rollenhagen (Dmitry Tantsur for inspector deliverables) || jroll (dtantsur)<br />
|-<br />
| Zaqar || || <br />
|-<br />
| Designate || Graham Hayes || mugsie<br />
|-<br />
| Barbican || Douglas Mendizábal || redrobot<br />
|-<br />
| Manila || Ben Swartzlander || bswartz<br />
|-<br />
| Murano ||Kirill Zaitsev || kzaitsev_<br />
|-<br />
| Congress || Tim Hinrichs || thinrichs<br />
|-<br />
| Mistral || Lingxian Kong || xylan_kong<br />
|}<br />
<br />
== QA ==<br />
<br />
There are now more projects that are being tested by Tempest, and Grenade or a part deployable by Devstack than we have QA contributors. That means we are going to need your help to keep on top of everything. We are asking for one person from each project to serve as a liaison between the project and QA, and to assist with integrating changes as we move forward.<br />
<br />
The liaison should be a core reviewer for the project, but does not need to be the PTL. The liaison should be prepared to assist with writing and reviewing patches that interact with their project, and with discussions of changes to the QA projects to make them easier to use within the project.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Nova || Matt Riedemann || mriedem<br />
|-<br />
| Cinder || || <br />
|-<br />
| Swift || || <br />
|-<br />
| Neutron || Salvatore Orlando || salv-orlando<br />
|-<br />
| Keystone || David Stanek || dstanek<br />
|-<br />
| Horizon || || <br />
|-<br />
| Glance || Nikhil Komawar || nikhil_k<br />
|-<br />
| Ceilometer || Chris Dent || cdent<br />
|-<br />
| Heat || Steve Baker || stevebaker<br />
|-<br />
| Oslo || Davanum Srinivas || dims <br />
|-<br />
| Trove || Craig Vyvial and Nirav Shah || cp16net and nshah<br />
|-<br />
| Sahara || Luigi Toscano and Sergey Lukjanov || tosky and SergeyLukjanov<br />
|-<br />
| Ironic || John Villalovos || jlvillal<br />
|-<br />
| Zaqar || || <br />
|-<br />
| Barbican || Steve Heyman || hockeynut <br />
|-<br />
| Manila || Valeriy Ponomaryov || vponomaryov<br />
|}<br />
<br />
== Documentation ==<br />
<br />
The OpenStack Documentation is centralized on docs.openstack.org but often there's a need for specialty information when reviewing patches or triaging doc bugs. A doc liaison should be available to triage doc bugs when the docs team members don't know enough to triage accurately, and be added to doc reviews that affect your project. You'd be notified through email when you're added either to a doc bug or a doc review. We also would appreciate attendance at the [https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting weekly doc team meeting], We meet weekly in #openstack-meeting every Wednesday at alternating times for different timezones:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Nova || Joe Gordon or Michael Still || Jog0 or mikal<br />
|-<br />
| Cinder || Mike Perez || thingee <br />
|-<br />
| Swift || || <br />
|-<br />
| Neutron || Edgar Magana || emagana <br />
|-<br />
| Keystone || Lance Bragstad || lbragstad<br />
|-<br />
| Horizon || Rob Cresswell || robcresswell<br />
|-<br />
| Glance || Brian Rosmaita || rosmaita<br />
|-<br />
| Ceilometer || Ildiko Vancsa || ildikov<br />
|-<br />
| Heat || Randall Burt || randallburt<br />
|-<br />
| Oslo || Doug Hellmann || dhellmann<br />
|-<br />
| Trove || Laurel Michaels || laurelm<br />
|-<br />
| Sahara || Chad Roberts || crobertsrh<br />
|-<br />
| Ironic || Mitsuhiro SHIGEMATSU || pshige<br />
|-<br />
| Zaqar || || <br />
|-<br />
| Barbican || Constanze Kratel || constanze <br />
|-<br />
| Murano || Ekaterina Chernova || katyafervent <br />
|-<br />
| Manila || || <br />
|}<br />
<br />
== Stable Branch ==<br />
<br />
The Stable Branch Liaison is responsible for making sure backports are proposed for critical issues in their project, and make sure proposed backports<br />
are reviewed. They are also the contact point for stable branch release managers around point release times.<br />
<br />
* By default, the liaison will be the PTL.<br />
* The Stable Branch Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL.<br />
* The liaison may further delegate work to other subject matter experts<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Ceilometer || Eoghan Glynn || eglynn<br />
|-<br />
| Cinder || Jay Bryant || jungleboyj<br />
|-<br />
| Glance || Erno Kuvaja || jokke_<br />
|-<br />
| Heat || Zane Bitter || zaneb<br />
|-<br />
| Horizon || Matthias Runge || mrunge <br />
|-<br />
| Ironic || Adam Gandelman || adam_g<br />
|-<br />
| Keystone || Dolph Mathews || dolphm<br />
|-<br />
| Murano || Kirill Zaitsev || kzaitsev_<br />
|-<br />
| Neutron || Ihar Hrachyshka || ihrachys<br />
|-<br />
| Nova || Matt Riedemann || mriedem <br />
|-<br />
| Sahara || Sergey Lukjanov || SergeyLukjanov<br />
|-<br />
| Swift || || <br />
|-<br />
| Trove || Amrith Kumar || amrith<br />
|-<br />
|}<br />
<br />
== Vulnerability management ==<br />
<br />
The [[Vulnerability Management]] Team needs domain specialists to help assessing the impact of reported issues, coordinate the development of patches, review proposed patches and propose backports. The liaison should be familiar with the [[Vulnerability Management]] process and embargo rules, and have a good grasp of security issues in software design.<br />
<br />
* The liaison should be a core reviewer for the project, but does not need to be the PTL.<br />
* By default, the liaison will be the PTL.<br />
* The liaison is the first line of contact for the Vulnerability Management team members<br />
* The liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL<br />
* The liaison may further delegate work to other subject matter experts<br />
* The liaison maintains the members of the $PROJECT-coresec team in Launchpad (which can be given access to embargoed vulnerabilities)<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Douglas Mendizábal or Charles Neill || redrobot / ccneill<br />
|-<br />
| Ceilometer || Lianhao Lu or Gordon Chung || llu/gordc <br />
|-<br />
| Cinder || || <br />
|-<br />
| Glance || Stuart McLaren or Nikhil Komawar || mclaren or nikhil_k <br />
|-<br />
| Heat || Steve Hardy || shardy<br />
|-<br />
| Horizon || Lin Hua Cheng || lhcheng <br />
|-<br />
| Ironic || Jim Rollenhagen || jroll<br />
|-<br />
| Keystone || Dolph Mathews || dolphm<br />
|-<br />
| Neutron || Salvatore Orlando || salv-orlando<br />
|-<br />
| Nova || Michael Still || mikal<br />
|-<br />
| Sahara || Michael McCune or Sergey Lukjanov || elmiko or SergeyLukjanov<br />
|-<br />
| Swift || || <br />
|-<br />
| Trove || Craig Vyvial or Nikhil Manchanda || cp16net or SlickNik <br />
|-<br />
|}<br />
<br />
== API Working Group ==<br />
<br />
The [[API_Working_Group|API Working Group]] seeks API subject matter experts for each project to communicate plans for API updates, review API guidelines with their project's view in mind, and review the API Working Group guidelines as they are drafted. The liaison should be familiar with the project's REST API design and future planning for changes to it.<br />
<br />
The members of the [http://specs.openstack.org/openstack/api-wg/liaisons.html API Working Group Cross-Project Liaisons] are maintained in our repo. If you want to read the entire list of CPLs or add/remove yourself from the list, you'll need to update the [http://git.openstack.org/cgit/openstack/api-wg/tree/doc/source/liaisons.json liaisons.json] file. If you don't want to make the update yourself, please ask in #openstack-sdks on IRC and someone can make the change for you.<br />
<br />
== Logging Working Group ==<br />
<br />
The [[LogWorkingGroup|Log Working Group]] seeks experts for each project to assist with making the logging in projects match the new [http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html Logging Guidelines]<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Glance || Erno Kuvaja || jokke_<br />
|-<br />
| Oslo || Doug Hellmann || dhellmann<br />
|-<br />
| Nova || John Garbutt || johnthetubaguy<br />
|-<br />
| Murano || Nikolay Starodubtsev || Nikolay_St<br />
|}<br />
<br />
== Infra ==<br />
<br />
These are the project specific groups of people that Infra will look to ACK changes to that project's test configuration. Changes to project-config and devstack-gate should be +1'd by these groups when they are related to their project. Note that in an emergency this may not always be possible and Infra will ask for forgiveness but generally we should look for these +1s.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Glance || Flavio Percoco, Nikhil Komawar|| flaper87, nikhil_k<br />
<br />
|-<br />
| Neutron || Kyle Mestery, Armando Migliaccio, Doug Wiegley|| mestery, armax, dougwig<br />
|-<br />
| Documentation || Andreas Jaeger|| AJaeger<br />
<br />
|-<br />
| Trove || Nikhil Manchanda || SlickNik<br />
|}<br />
<br />
== Product Working Group ==<br />
The product working group consists of product managers, technologists, and operators from a diverse set of organizations. The group is working to aggregate user stories from the market-focused teams (Enterprise, Telco, etc.) and cross-project functional teams (e.g. logging, upgrades, etc.), partner with the development community on resourcing, and help gather data to generate a multi-release roadmap. Most of the user stories being tracked by this team consists of items that can span multiple releases and usually have cross-project dependencies. <br />
<br />
More information about the team can be found on the [[ProductTeam|Product WG wiki]].<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Ceilometer ||Krish Ragurham || <br />
|-<br />
| Cinder || Shamail Tahir || shamail<br />
|-<br />
| Glance || Nate Ziemann || nate_zman<br />
|-<br />
| Horizon || Carol Barrett || barrett1<br />
|-<br />
| Keystone || Sheena Gregson || <br />
|-<br />
| Kolla || Carol Barrett || barrett1<br />
|-<br />
| Neutron || Mike Cohen, Duane DeCapite || DuaneDeC7<br />
|-<br />
| Manilla ||Pete Chadwick || <br />
|-<br />
| Nova || Hugh Blemings || hughhalf <br />
|-<br />
|OSClient || Megan Rossetti || <br />
|-<br />
|Tempest || Arkady Kanevsky || arkady_kanevsky<br />
|-<br />
| Swift || Phil Willains || philipw<br />
|-<br />
| Magnum || Steve Gordon || sgordon<br />
|-<br />
|}<br />
<br />
== Inter-project Liaisons ==<br />
<br />
In some cases, it is useful to have liaisons between projects. [http://lists.openstack.org/pipermail/openstack-dev/2015-April/062327.html For example, it is useful for the Nova and Neutron projects to have liaisons, because the projects have complex interactions and dependencies.] Ideally, a cross-project effort should have two members, one from each project, to facilitate communication and knowledge transfer.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Projects !! Name !! IRC Handle !! Role<br />
|-<br />
| Nova / Neutron || || ||<br />
|-<br />
| || Sean M. Collins || sc68cal || Neutron liaison for Nova<br />
|-<br />
| || Brent Eagles || beagles || Nova liaison for Neutron<br />
|-<br />
| Nova / Glance || || ||<br />
|-<br />
| || Flavio Percoco, Mike Fedosin || flaper87, mfedosin || Glance liaison for Nova<br />
|-<br />
| || Jay Pipes || jaypipes || Nova liaison for Glance<br />
|-<br />
| Nova / Cinder || || ||<br />
|-<br />
| || Scott DAngelo || scottda || Cinder liaison for Nova<br />
|-<br />
| || Matt Riedemann || mriedem || Nova liason for Cinder<br />
|-<br />
| Nova / Ironic || John Villalovos || jlvillal || Ironic liaison for Nova<br />
|-<br />
| || Michael Davies || mrda || Ironic liaison for Nova<br />
|-<br />
| Neutron / Ironic || || ||<br />
|-<br />
| || Sukhdev Kapur || sukhdev || Neutron liaison for Ironic<br />
|-<br />
| || Mitsuhiro SHIGEMATSU and Jim Rollenhagen || pshige and jroll || Ironic liaison for Neutron<br />
|-<br />
| Murano / Glance || || ||<br />
|-<br />
| || Alexander Tivelkov || ativelkov || Glance liaison for Murano, Murano liaison for Glance<br />
|-<br />
| Horizon / i18n || || ||<br />
|-<br />
| || Doug Fish || doug-fish || Horizon liaison for i18n<br />
|}<br />
<br />
=== Etherpads ===<br />
<br />
The following is a list of etherpads that are used for inter-project liaisons, and are continuously updated.<br />
<br />
Nova - Neutron: https://etherpad.openstack.org/p/nova-neutron</div>Arkadyhttps://wiki.openstack.org/w/index.php?title=ProductTeam&diff=81388ProductTeam2015-05-17T23:02:51Z<p>Arkady: </p>
<hr />
<div>= OpenStack Product Working Group =<br />
<br />
== Highlights ==<br />
new IRC meetings https://wiki.openstack.org/wiki/Meetings/product-team<br />
past IRC meetings http://eavesdrop.openstack.org/meetings/product_team/2015/<br />
F2F Feb2015 https://etherpad.openstack.org/p/kilo-product-management-midcycle<br />
F2F Sep2014 https://etherpad.openstack.org/p/paris-product-meeting<br />
[http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg Subscribe to the Mailing List]<br />
[http://lists.openstack.org/pipermail/product-wg/ Mailing List Archives]<br />
<br />
== Mission == <br />
<br />
To listen and aggregate feedback on the desired capabilities for the OpenStack platform from key sources including the contributor community (PTLs), customers, operators, and users. The group aims to help PTLs and contributors resolve issues that are either of strategic importance or have broad implications across OpenStack services. Finally, we will also help customers/users be successful with adoption of the platform by leveraging additional development resources across each impacted OpenStack project on areas that are identified as high impact by removing barriers to adoption/operation<br />
<br />
== Who we are ==<br />
<br />
The Product working group is made of managers, people, functions, groups that own "products" based on OpenStack who aim to **improve the quality of the delivery process, the delivered product, and the product experience for operators and end users**. <br />
<br />
Members of the Product working group have a high-level view of the ecosystem and can dig into the details enough to point out where the individual components need development focus.<br />
<br />
== Objectives ==<br />
<br />
The objectives of this working group, based on the mission, are therefore to:<br />
<br />
# Collect Feedback: Gather, and report, feedback in a transparent manner from customers (developers, end users, and vendors) on OpenStack with regards to the state, capabilities, and user experience of the platform.<br />
# Categorize and Increase Contextual Awareness: Provide the data and associated context on themes (and associated use cases, problem statements) to all stakeholders to ensure focus areas can be clearly defined for each release cycle.<br />
# Prioritization Planning: Develop a repeatable, transparent, process for prioritization of requirements for each release. The criteria for the process along with the results should be clearly communicated with the community and our end-customers.<br />
# Increase Uniformity of Epics and User Stories: The team should leverage epics to capture larger stories/requirements, convert them into user stories and actionable enhancement requests.<br />
# Aggregation of Requirements: This group will collect (and aggregate) user, admin, customer, and operator requirements. The group should also interface with and gather data from, the other groups collecting requirements for specific verticals, markets, or user segments (e.g. Operators, Win The Enterprise, Personas, NFV/Telco, End Users/App Developers, etc.)<br />
# Grouping Requirements and Cross Project Communication of Requirements: This group will be analyzing data/requirements received from all of the sources (developers, end users, operators, and vendors) and establish grouping of similar requirements into themes. The themes will also have a recommended break-down of manageable engineering tasks necessary for meeting the theme criteria which will be communicated across all projects.<br />
# Multi-release Roadmap: Generate a multi-release roadmap based on the aggregated data and resulting themes/requirements. The roadmap will be socialized, transparently, to community stakeholders for agreement and approval. After a roadmap has been established/approved, the OpenStack community will be notified of the results, the drivers for the decision, and its impact over multiple releases to consumers (and developers) of the platform.<br />
<br />
== Timeline for Integration of the Product team with other teams; PTLs, TC, and other User Committee working groups ==<br />
# Form a rough draft workflow<br />
# Present rough draft workflow to the TC<br />
# Present data collected so far at the Liberty summit<br />
# Run through some examples with the TC, PTL, and WTE<br />
# At the Tokyo summit, present the multi-release roadmap for M through S releases<br />
<br />
== Outputs of this group ==<br />
<br />
The initial outputs of the team are to define various processes and, most importantly, to listen to the PTLs and document their current roadmaps and thoughts.<br />
<br />
The team is currently focused on three outputs:<br><br />
* '''Socialization''': Gathering feedback from PTLs and documenting the results<br><br />
** The current work is here https://etherpad.openstack.org/p/kilo-product-management-socialization <br />
* '''Roadmap Definition''': Creating the process that can be used to eventually define the roadmap<br><br />
** The current process definition is here https://docs.google.com/document/d/13JPDDiBGGXf5dtP0u8C-1So2Mjb3yEmGhv_ijVqyEf0/edit?usp=sharing<br /><br />
** The in-development roadmap is hereː https://drive.google.com/file/d/0BxtM4AiszlEyQW5NeEJHX1lvTDg/view?usp=sharing<br />
* '''Roadmap Communication''': Creating the process for cross-project communication of the roadmap and making it transparent<br />
** The current work is here https://etherpad.openstack.org/p/kilo-product-management-task-cross-project<br />
<br />
It's good practice to send a brief personal introduction when signing up.<br />
<br />
[[Category: Working_Groups]]</div>Arkady