{"id":5007,"date":"2013-08-23T15:04:02","date_gmt":"2013-08-23T20:04:02","guid":{"rendered":"http:\/\/www.openstack.org\/blog\/?p=5007"},"modified":"2013-08-23T15:04:02","modified_gmt":"2013-08-23T20:04:02","slug":"addressing-the-topic-of-core-through-spider","status":"publish","type":"post","link":"https:\/\/www.openstack.org\/blog\/addressing-the-topic-of-core-through-spider\/","title":{"rendered":"Addressing the topic of \u2018Core\u2019 through Spider"},"content":{"rendered":"
\n

The word \u201ccore\u201d carries with it a wide range of meaning and\u00a0implication for those involved within the OpenStack community. What we\u2019ve\u00a0discovered\u00a0through ongoing discussions is that the goals of one audience simply\u00a0aren\u2019t necessarily the goals of the other audiences – in fact, in some cases,\u00a0they\u2019re\u00a0opposed!<\/p>\n

We first began the journey to refine the definition of core\u00a0through a work effort called IncUp.\u00a0\u00a0IncUp was a combined effort of TC and board members that\u00a0resulted with\u00a0improvements to the Incubation process. That effort also helped draw out the\u00a0complex nature of defining core.\u00a0\u00a0The\u00a0complexity is due to the\u00a0varied impact core has upon OpenStack users and\u00a0contributors, as well as the ecosystem as a whole.<\/p>\n

Addressing The Problem
\nOn assignment from the Board, Rob Hirschfeld and I began\u00a0meeting to further the progress of defining core. The first step in this\u00a0process was to examine\u00a0and define the goals of each audience, which Rob\u00a0detailed in a series of blogs[1] outlining the thought processes we went through.<\/p>\n

Shortly after we began this process, we quickly realized that\u00a0the goals amongst these various audiences would either be aligned or in\u00a0tension. Using\u00a0different colors to map the goals and tensions on a whiteboard,\u00a0we created a massive multi-colored \u201cspider\u201d graph, which became more of a mind\u00a0map.\u00a0Thus, we refer to the current effort as the \u201cspider discussions\u201d or simply\u00a0spider.<\/p>\n<\/div>\n

Problem Statement\/Goal
\nAt the highest level, this spider effort is about advancing the\u00a0OpenStack mission of producing the ubiquitous Open Source cloud computing\u00a0platform. The\u00a0key efforts within this process include defining the set of\u00a0components, processes and criteria needed to protect the brand, provide users a\u00a0good\u00a0experience, and reinforce a collaborative community.OpenStack marks are the tools that the Foundation has to define\u00a0and defend those keys.<\/div>\n
<\/div>\n
In order for OpenStack implementers to use the OpenStack mark,\u00a0the Board was chartered to provide specific and verifiable criteria. However,\u00a0these do\u00a0not currently exist in a usable form.\u00a0\u00a0Thus, our “what is core” discussions and efforts seek to\u00a0determine those criteria.
\nStatements of Position<\/div>\n
<\/div>\n
Spider focuses on breaking down those criteria of core into\u00a0referenceable position statements.\u00a0\u00a0Those\u00a0statements will form a basis to draw upon so that we\u00a0may keep the decision\u00a0making – and eventual implementation – on a progressive track.There are currently 10 evolving position statements:1.\u00a0 \u00a0 \u00a0Implementations\u00a0that are core can utilize the OpenStack trademark (OpenStack\u2122)<\/div>\n
<\/div>\n
1. \u00a0 \u00a0 This is the legal definition of core, as well as\u00a0why it matters to\u00a0\u00a0the community.<\/p>\n
    \n
  1. \u00a0We want to make sure that the OpenStack\u2122 mark\u00a0means something.<\/li>\n
  2. The OpenStack\u2122 mark is\u00a0not\u00a0the same as the OpenStack brand; rather, the Board uses its\u00a0control of the mark as a proxy to help manage\u00a0the brand.<\/li>\n<\/ol>\n

    2.\u00a0 \u00a0 \u00a0Core\u00a0is a subset of the whole project<\/p>\n

      \n
    1. The\u00a0OpenStack project is intended to be a broad and diverse community with new\u00a0projects entering incubation, with new implementations\u00a0frequently added. This\u00a0innovation is vital to\u00a0OpenStack but separate from the definition of core.<\/li>\n
    2. There may be other marks that are managed\u00a0separately by the foundation and available for the platform ecosystem at the\u00a0Board\u2019s discretion.<\/li>\n
    3. The \u201cOpenStack API Compatible\u201d mark is not part\u00a0of this discussion and should be not be assumed.<\/li>\n<\/ol>\n<\/div>\n
      3.\u00a0 \u00a0 \u00a0Core\u00a0definition can be applied equally to all usage models<\/p>\n
        \n
      1. \u00a0There should not be multiple definitions of\u00a0OpenStack, regardless of the operator (public, private, community, etc.).<\/li>\n
      2. While expected that each deployment is\u00a0identical, the differences must be quantifiable.<\/li>\n<\/ol>\n

        4.\u00a0 \u00a0 \u00a0Claiming\u00a0OpenStack requires use of designated code frameworks<\/p>\n

          \n
        1. Implementations claiming the OpenStack\u2122 mark\u00a0must use the approved API framework code.\\<\/li>\n
        2. Entities which only\u00a0pass all the tests but do not use the API framework will not be considered or\u00a0be approved as part of OpenStack.This\u00a0prevents entities from using the API\u00a0without joining the community, as well as surfaces bit-rot in alternate\u00a0implementations to the larger\u00a0community.<\/li>\n
        3. By implementing this\u00a0requirement,\u00a0\u00a0interoperability is greatly\u00a0improved, as there is more shared code between implementation<\/li>\n<\/ol>\n

          5.\u00a0 \u00a0 \u00a0Projects\u00a0must have an open reference implementation<\/p>\n

            \n
          1. OpenStack will\u00a0require an open source reference base plug-in implementation for all projects\u00a0(if not part of OpenStack, license model for\u00a0reference plug-in must be\u00a0compatible).<\/li>\n
          2. We define a plug-in\u00a0as alternate backend implementations with a common API framework that use\u00a0common _code_ to implement the API.<\/li>\n
          3. This establishes the\u00a0expectation that projects (where technically feasible) will implement plug-in\u00a0or extension architecture.<\/li>\n
          4. This is already in\u00a0place for several projects and addresses ecosystem support, further enabling\u00a0innovation.<\/li>\n
          5. Reference plug-ins\u00a0are, by definition, the complete capability set. It is not acceptable to have\u00a0core features that are not functional in the\u00a0reference plug-in.<\/li>\n
          6. This will enable\u00a0alternate implementations to offer innovative or differentiated features\u00a0without forcing changes to the reference plug-in\u00a0implementation.<\/li>\n
          7. This will also\u00a0enable the reference to expand without forcing other alternate implementations\u00a0to match all features and recertify.<\/li>\n<\/ol>\n

            6.\u00a0 \u00a0 \u00a0Vendors\u00a0may substitute alternate implementations<\/p>\n

              \n
            1. If a vendor plug-in\u00a0passes all relevant tests then it can be considered a full substitute for the\u00a0reference plug-in.<\/li>\n
            2. If a vendor plug-in\u00a0does not pass all relevant tests then the vendor is required to include the\u00a0open source reference in the implementation.<\/li>\n
            3. Alternate\u00a0implementations may pass any tests that make sense and should add tests to\u00a0validate new functionality.<\/li>\n
            4. They are also\u00a0required to have all the must-pass tests (see #10) to claim the OpenStack mark.<\/li>\n<\/ol>\n

              7.\u00a0 \u00a0 \u00a0OpenStack\u00a0implementations are verified by open community tests<\/p>\n

                \n
              1. OpenStack\u00a0implementations by vendors must achieve 100% of must-have coverage.<\/li>\n
              2. Implemented tests\u00a0can be flagged as must-have required list.<\/li>\n
              3. Certifiers will be\u00a0required to disclose their testing gaps.<\/li>\n
              4. This will put a lot\u00a0of pressure on the Tempest project.<\/li>\n
              5. Maintenance of the\u00a0testing suite will become a core Foundation responsibility, which may require\u00a0additional resources.<\/li>\n
              6. Implementations and\u00a0products are allowed to have variation based on publication of compatibility.<\/li>\n
              7. Consumers must have\u00a0a way to determine how the system is different from reference (posted,\u00a0discovered, etc.).<\/li>\n
              8. Testing must respond\u00a0in an appropriate way in BOTH pass and fail (the wrong return rejects the\u00a0entire suite).<\/li>\n<\/ol>\n

                8.\u00a0 \u00a0 \u00a0Tests\u00a0can be remotely or self-administered<\/p>\n

                  \n
                1. Plug-in\u00a0certification is driven by Tempest self-certification model.<\/li>\n
                2. Self-certifiers are\u00a0required to publish their results.<\/li>\n
                3. Self-certifier are\u00a0also required to publish enough information that a third party could build the\u00a0reference implementation to pass the tests.<\/li>\n
                4. Self-certifiers must\u00a0include the operating systems that have been certified.<\/li>\n
                5. It is preferred for\u00a0self-certified implementations to refer back to an OpenStack reference\u00a0architecture \u201cflavor\u201d instead of defining their own\u00a0reference (a way to publish\u00a0and agree on flavors is needed).<\/li>\n
                6. The Foundation needs\u00a0to define a mechanism of dispute resolution (i.e. a trust but verify model).<\/li>\n
                7. All ecosystem\u00a0partners need to make a \u201cworks against OpenStack\u201d statement that is\u00a0supportable.<\/li>\n
                8. An API consumer can\u00a0claim working against the OpenStack API if it works against any implementation\u00a0passing all the \u201cmust have\u201d tests.<\/li>\n
                9. API consumers can\u00a0state they are working against the OpenStack API with some \u201cmay have\u201d items as\u00a0requirements.<\/li>\n
                10. API consumers are expected to write tests that validate\u00a0their required behaviors (submitted as \u201cmay have\u201d tests)<\/li>\n<\/ol>\n

                  9.\u00a0 \u00a0 \u00a0A\u00a0subset of tests are chosen by the Foundation as \u201cmust-pass\u201d<\/p>\n

                    \n
                  1. An OpenStack body\u00a0will recommend which tests are elevated from \u201cmay-have\u201d to \u201cmust-have.\u201d<\/li>\n
                  2. The selection of\u00a0\u201cmust-pass\u201d tests should be based on quantifiable information when possible.<\/li>\n
                  3. Must-pass tests\u00a0should be selected from the existing body of may-pass tests.\u00a0\u00a0This encourages people to write tests for\u00a0cases they want\u00a0supported.<\/li>\n
                  4. We will have a process\u00a0by which tests are elevated from \u201cmay\u201d to \u201cmust\u201d lists.<\/li>\n
                  5. Essentially, the\u00a0hope is that the User Committee will nominate tests that elevate to the Board.<\/li>\n<\/ol>\n

                    10.\u00a0\u00a0OpenStack\u00a0core means passing all \u201cmust-pass\u201d tests<\/p>\n

                      \n
                    1. The OpenStack Board\u00a0owns the responsibility to define core (to approve \u2018musts\u2019).<\/li>\n
                    2. We are NOT defining\u00a0which items are on the list in the Spider effort; rather, just making the\u00a0position that this is how we will define core.<\/li>\n
                    3. May-have tests\u00a0include items in the integrated release, but which are not core.<\/li>\n
                    4. Must-haves must\u00a0comply with the core criteria defined from the IncUp committee results.<\/li>\n
                    5. Projects in\u00a0Incubation or pre-Incubation are not to be included in the \u201cmay\u201d list.<\/li>\n<\/ol>\n

                      For a quick visual way to understand how these position\u00a0statements interconnect Rob posted, in his blog series, an \u2018OpenStack Core\u00a0flowchart\u2019. [2]<\/p>\n

                      Help Us Finalize the 10<\/p>\n

                      These position statements are an ongoing work in process. It is\u00a0our goal to finalize them for the November Board meeting and Hong Kong Summit.\u00a0Yet in\u00a0order to meet that goal, we want your help and, as such, would love to\u00a0hear from you. I encourage you all to strike up a conversation on IRC with Rob,\u00a0myself or any board member, or simply post your feedback to the Foundation\u00a0mailing list. We\u2019re looking to you to help us reach the goal of the\u00a0Foundation\u2019s\u00a0mission!<\/p>\n

                      Alan Clark
                      \nOpenStack Board Chair<\/p>\n

                      [1]\u00a0http:\/\/robhirschfeld.com\/2013\/07\/23\/introducing-the-openstack-spider-graph-untangling-our-web-of-interdependencies\/
                      \n[2]\u00a0http:\/\/robhirschfeld.com\/2013\/08\/07\/visualizing-the-openstack-core\/<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

                      The word \u201ccore\u201d carries with it a wide range of meaning and\u00a0implication for those involved within the OpenStack community. What we\u2019ve\u00a0discovered\u00a0through ongoing discussions is that the goals of one audience simply\u00a0aren\u2019t necessarily the goals of the other audiences – in fact, in some cases,\u00a0they\u2019re\u00a0opposed! We first began the journey to refine the definition of core\u00a0through… Read more »<\/a><\/p>\n","protected":false},"author":48,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[28,435,1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/5007"}],"collection":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/users\/48"}],"replies":[{"embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/comments?post=5007"}],"version-history":[{"count":11,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/5007\/revisions"}],"predecessor-version":[{"id":5018,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/posts\/5007\/revisions\/5018"}],"wp:attachment":[{"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/media?parent=5007"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/categories?post=5007"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.openstack.org\/blog\/wp-json\/wp\/v2\/tags?post=5007"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}