Open Stack

Although there has not been much discussion on this point on the mailing list, I feel we do need to find the right level of granularity for ‘mainstream’ projects:

For CERN, we look for the following before offering a project to our end users:

- Distro packaging (in our case RPMs through RDO)
- Puppet modules
- Openstack client support (which brings Kerberos/X.509 authentication)
- Install, admin and user docs
- Project diversity for long term sustainability

We have many use cases of ‘resellers’ where one project provides a deliverable for others to consume, some degree of community image sharing is arriving and these are the same problems to face for artefacts and application catalogues (such as Heat and Magnum).

For me, which project provides this for images and/or artefacts is a choice for the technical community but consistent semantics would be greatly appreciated for those discussions with our end users such as “I need a Heat template for X but this needs community image Y and the visibility rules means that one needs to be shared in advance, the other I need to subscribe to” are difficult discussion which discourages uptake.

A cloud user should be able to click on community offered ‘R-as-a-Service’ in the application catalog GUI, and that’s all.

Tim

On 10.02.17, 18:39, "Brian Rosmaita" <rosmaita.fossdev at gmail.com> wrote:

    I want to give all interested parties a heads up that I have scheduled a
    session in the Macon room from 9:30-10:30 a.m. on Thursday morning
    (February 23).
    
    Here's what we need to discuss.  This is from my perspective as Glance
    PTL, so it's going to be Glance-centric.  This is a quick narrative
    description; please go to the session etherpad [0] to turn this into a
    specific set of discussion items.
    
    Glance is the OpenStack image cataloging and delivery service.  A few
    cycles ago (Juno?), someone noticed that maybe Glance could be
    generalized so that instead of storing image metadata and image data,
    Glance could store arbitrary digital "stuff" along with metadata
    describing the "stuff".  Some people (like me) thought that this was an
    obvious direction for Glance to take, but others (maybe wiser, cooler
    heads) thought that Glance needed to focus on image cataloging and
    delivery and make sure it did a good job at that.  Anyway, the Glance
    mission statement was changed to include artifacts, but the Glance
    community never embraced them 100%, and in Newton, Glare split off as
    its own project (which made sense to me, there was too much unclarity in
    Glance about how Glare fit in, and we were holding back development, and
    besides we needed to focus on images), and the Glance mission statement
    was re-amended specifically to exclude artifacts and focus on images and
    metadata definitions.
    
    OK, so the current situation is:
    - Glance "does" image cataloging and delivery and metadefs, and that's
    all it does.
    - Glare is an artifacts service (cataloging and delivery) that can also
    handle images.
    
    You can see that there's quite a bit of overlap.  I gave you the history
    earlier because we did try to work as a single project, but it did not
    work out.
    
    So, now we are in 2017.  The OpenStack development situation has been
    fragile since the second half of 2016, with several big OpenStack
    sponsors pulling way back on the amount of development resources being
    contributed to the community.  This has left Glare in the position where
    it cannot qualify as a Bit Tent project, even though there is interest
    in artifacts.
    
    Mike Fedosin, the PTL for Glare, has asked me about Glare becoming part
    of the Glance project again.  I will be completely honest, I am inclined
    to say "no".  I have enough problems just getting Glance stuff done (for
    example, image import missed Ocata).  But in addition to doing what's
    right for Glance, I want to do what's right for OpenStack.  And I look
    at the overlap and think ...
    
    Well, what I think is that I don't want to go through the Juno-Newton
    cycles of argument again.  And we have to do what is right for our users.
    
    The point of this session is to discuss:
    - What does the Glance community see as the future of Glance?
    - What does the wider OpenStack community (TC) see as the future of Glance?
    - Maybe, more importantly, what does the wider community see as the
    obligations of Glance?
    - Does Glare fit into this vision?
    - What kind of community support is there for Glare?
    
    My reading of Glance history is that while some people were on board
    with artifacts as the future of Glance, there was not a sufficient
    critical mass of the Glance community that endorsed this direction and
    that's why things unravelled in Newton.  I don't want to see that happen
    again.  Further, I don't think the Glance community got the word out to
    the broader OpenStack community about the artifacts project, and we got
    a lot of pushback along the lines of "WTF? Glance needs to do images"
    variety.  And probably rightly so -- Glance needs to do images.  My
    point is that I don't want Glance to take Glare back unless it fits in
    with what the community sees as the appropriate direction for Glance.
    And I certainly don't want to take it back if the entire Glance
    community is not on board.
    
    Anyway, that's what we're going to discuss.  I've booked one of the
    fishbowl rooms so we can get input from people beyond just the Glance
    and Glare projects.
    
    cheers,
    brian
    
    [0] https://etherpad.openstack.org/p/pike-glance-glare-discussion
    
    
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev