On 19/05/17 15:06, Kevin Benton wrote:
Don't even get me started on Neutron.[2]

It seems to me the conclusion to that thread was that the majority of
your issues stemmed from the fact that we had poor documentation at the
time.  A major component of the complaints resulted from you
misunderstanding the difference between networks/subnets in Neutron.

It's true that I was completely off base as to what the various primitives in Neutron actually do. (Thanks for educating me!) The implications for orchestration are largely unchanged though. It's a giant pain that we have to infer implicit dependencies between stuff to get them to create/delete in the right order, pretty much independently of what that stuff does.

So knowing now that a Network is a layer-2 network segment and a Subnet is... effectively a glorified DHCP address pool, I understand better why it probably seemed like a good idea to hook stuff up magically. But at the end of the day, I still can't create a Port until a Subnet exists, I still don't know what Subnet a Port will be attached to (unless the user specifies it explicitly using the --fixed-ip option... regardless of whether they actually specify a fixed IP), and I have no way in general of telling which Subnets can be deleted before a given Port is and which will fail to delete until the Port disappears.

There are some legitimate issues in there about the extra routes
extension being replace-only and the routers API not accepting a list of
interfaces in POST.  However, it hardly seems that those are worthy of
"Don't even get me started on Neutron."

https://launchpad.net/bugs/1626607
https://launchpad.net/bugs/1442121
https://launchpad.net/bugs/1626619
https://launchpad.net/bugs/1626630
https://launchpad.net/bugs/1626634

It would be nice if you could write up something about current gaps that
would make Heat's life easier, because a large chunk of that initial
email is incorrect and linking to it as a big list of "issues" is
counter-productive.

Yes, agreed. I wish I had a clean thread to link to. It's a huge amount of work to research it all though.

cheers,
Zane.

On Fri, May 19, 2017 at 7:36 AM, Zane Bitter <zbit...@redhat.com
<mailto:zbit...@redhat.com>> wrote:

    On 18/05/17 20:19, Matt Riedemann wrote:

        I just wanted to blurt this out since it hit me a few times at the
        summit, and see if I'm misreading the rooms.

        For the last few years, Nova has pushed back on adding
        orchestration to
        the compute API, and even define a policy for it since it comes
        up so
        much [1]. The stance is that the compute API should expose
        capabilities
        that a higher-level orchestration service can stitch together
        for a more
        fluid end user experience.


    I think this is a wise policy.

        One simple example that comes up time and again is allowing a
        user to
        pass volume type to the compute API when booting from volume
        such that
        when nova creates the backing volume in Cinder, it passes
        through the
        volume type. If you need a non-default volume type for boot from
        volume,
        the way you do this today is first create the volume with said
        type in
        Cinder and then provide that volume to the compute API when
        creating the
        server. However, people claim that is bad UX or hard for users to
        understand, something like that (at least from a command line, I
        assume
        Horizon hides this, and basic users should probably be using Horizon
        anyway right?).


    As always, there's a trade-off between simplicity and flexibility. I
    can certainly understand the logic in wanting to make the simple
    stuff simple. But users also need to be able to progress from simple
    stuff to more complex stuff without having to give up and start
    over. There's a danger of leading them down the garden path.

        While talking about claims in the scheduler and a top-level
        conductor
        for cells v2 deployments, we've talked about the desire to eliminate
        "up-calls" from the compute service to the top-level controller
        services
        (nova-api, nova-conductor and nova-scheduler). Build retries is
        one such
        up-call. CERN disables build retries, but others rely on them,
        because
        of how racy claims in the computes are (that's another story and why
        we're working on fixing it). While talking about this, we asked,
        "why
        not just do away with build retries in nova altogether? If the
        scheduler
        picks a host and the build fails, it fails, and you have to
        retry/rebuild/delete/recreate from a top-level service."


    (FWIW Heat does this for you already.)

        But during several different Forum sessions, like user API
        improvements
        [2] but also the cells v2 and claims in the scheduler sessions,
        I was
        hearing about how operators only wanted to expose the base IaaS
        services
        and APIs and end API users wanted to only use those, which means any
        improvements in those APIs would have to be in the base APIs (nova,
        cinder, etc). To me, that generally means any orchestration
        would have
        to be baked into the compute API if you're not using Heat or
        something
        similar.


    The problem is that orchestration done inside APIs is very easy to
    do badly in ways that cause lots of downstream pain for users and
    external orchestrators. For example, Nova already does some
    orchestration: it creates a Neutron port for a server if you don't
    specify one. (And then promptly forgets that it has done so.) There
    is literally an entire inner platform, an orchestrator within an
    orchestrator, inside Heat to try to manage the fallout from this.
    And the inner platform shares none of the elegance, such as it is,
    of Heat itself, but is rather a collection of cobbled-together hacks
    to deal with the seemingly infinite explosion of edge cases that we
    kept running into over a period of at least 5 releases.

    The get-me-a-network thing is... better, but there's no provision
    for changes after the server is created, which means we have to
    copy-paste the Nova implementation into Heat to deal with update.[1]
    Which sounds like a maintenance nightmare in the making. That seems
    to be a common mistake: to assume that once users create something
    they'll never need to touch it again, except to delete it when
    they're done.

    Don't even get me started on Neutron.[2]

    Any orchestration that is done behind-the-scenes needs to be done
    superbly well, provide transparency for external orchestration tools
    that need to hook in to the data flow, and should be developed in
    consultation with potential consumers like Shade and Heat.

        Am I missing the point, or is the pendulum really swinging away from
        PaaS layer services which abstract the dirty details of the
        lower-level
        IaaS APIs? Or was this always something people wanted and I've just
        never made the connection until now?


    (Aside: can we stop using the term 'PaaS' to refer to "everything
    that Nova doesn't do"? This habit is not helping us to communicate
    clearly.)

    cheers,
    Zane.

    [1] https://review.openstack.org/#/c/407328/
    <https://review.openstack.org/#/c/407328/>
    [2]
    http://lists.openstack.org/pipermail/openstack-dev/2014-April/032098.html
    <http://lists.openstack.org/pipermail/openstack-dev/2014-April/032098.html>


    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:
    openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
    <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>




__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to