<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 01/14/2014 12:23 AM, Prasad Vellanki
      wrote:<br>
    </div>
    <blockquote
cite="mid:CADstcNZjXjGgaYG1=wa=N6cW_XVs3SWEAOjsT+Q92=4Dshb8UQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Thu, Jan 9, 2014 at 6:14 AM,
            Steven Dake <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">that</blockquote>
          </div>
          <br>
          Steve
          <div>Thanks for detailed email. Apologize for the delayed
            response but we have been thinking about how does software
            config fit into configuring network and service function
            devices. I agree with you that in general it is best to get
            appliance vendors to put cloudinit into their images and
            thus get on board with what every cloud is doing. I thought
            I would get some feedback on the direction of Heat for
            configuring network devices and appliances. </div>
          <div><br>
          </div>
          <div>I am thinking there are few things to consider for
            configuring Network and Network Service devices/Virtual
            Appliances. </div>
          <div><br>
          </div>
          <div>Neutron APIs along with the service APIs provide a way to
            configure network devices by abstracting the APIs and have a
            plugin model for individual devices. These APIs include
            Neutron core apis, Service API such as LBaaS, FWaaS, VPNaaS.
            Though these are currently for physical devices, there is a
            movement towards configuring Virtual Appliances too. These
            APIs will be addressed via Heat Neutron resources.</div>
          <div><br>
          </div>
          <div>While *aaS do address configuring the supported service,
            they do not address the bootstrapping of the device.
            Generally for most devices bootstrapping is done via rest
            API and/or SSH. And for unsupported  services that do not
            have these APIs one needs to use custom way to configure
            where Heat can really help.  Bootstrapping includes
            installing licences, configuring admin password, upgrade
            software  and some with more than that. For this our thought
            is it would be great to have  Heat software
            config/deployment do bootstrapping, upgrade etc.</div>
          <div><br>
          </div>
          <div> While I agree long term is to have vendors to implement
            cloudinit framework, we were wondering if there is an
            intermediate solution that will allow configuration <span
              style="font-family:arial,sans-serif;font-size:13px">without
              requiring agent and cloudinit, If there is enough critical
              mass behind such a requirement we can have further
              discussions on the design and implementation options.</span></div>
          <div> </div>
        </div>
      </div>
    </blockquote>
    Prasad,<br>
    <br>
    The crux of the problem is how do you obtain critical mass for
    custom one-off solutions?  Lets assume two possible solutions to
    this problem that these vendors could take.  If there are more,
    please feel free to explain them:<br>
    <br>
    1) Implement a ReST server which the vendor's image talks to ReST
    server to obtain bootstrapping information<br>
    2) SSH into the machine from an external configuration server
    process<br>
    <br>
    In both of these cases, these would be one-off solutions for each
    particular vendor.  Now assume you take this to the natural
    conclusion of hundreds of application images - you end up with
    hundreds of these daemons to handle all the various application
    images.  What is worse, they would have to documented, HA-ified,
    scale-ified, secure-ified, and deployed.  I am doubtful the SSH
    model would work fitting your constraints (not modifying the image)
    since some type of SSH key injection would need to be done.  I
    further doubt service providers are really going to want to deal
    with an extra server in their environment that is not specifically
    required for OpenStack unless the value offered by the cloud
    application is tremendous.  There are enough daemons already to deal
    with :)<br>
    <br>
    I get that a whole bunch of different cloud application vendor
    bootstrapping tools could be merged into "one" daemon and then this
    one master daemon could be documented, HA-ified, scale-ified,
    secureified, and deployed.  Perhaps there is some sort of financial
    incentive to make that happen and maybe someone can make a business
    out of it but my personal feeling is it is the wrong approach.  If
    this is the approach your proposing, it does not fit in with the
    mission of Heat program specifically, and TBH I'm not certain your
    goals fit with an existing program to "solve" this particular
    problem.<br>
    <br>
    Frankly, I don't believe there is a intermediate step application
    vendors can take here.  If they want their images to run in cloud
    environments because they are cloud workload applications, they need
    to commit to cloudinit.  Cloud application vendors need to balance
    the position of "We don't want cloudinit because we want our own
    custom bootstrapping" with "The entire cloud community has made a
    decision to handle bootstrapping with cloudinit".  On balance, the
    cloud application vendors should follow the lead of the cloud
    community in general.  The cloud community has chosen cloudinit for
    a reason - it wasn't some random act.<br>
    <br>
    Any other option IMNSHO harms the application vendor's SAM, the
    OpenStack ecosystem, the architectural clarity of OpenStack and is
    detrimental to other cloud environments as well.<br>
    <br>
    In this thread I have seen no rationale for *why* cloudinit can't be
    added to cloud vendor's images by the cloud vendor.  We just added
    heat-cfntools to the RHEL6.5 cloud image, and it cost money to make
    that happen, but investment in core engineering is a normal activity
    of any technology business.  Are there other rationale beyond the
    investment expense?<br>
    <br>
    There really is no winner to a custom bootstrapping system, other
    then the team who make the custom bootstrapping system and
    sell/support it ;)  Even the application vendor loses because their
    SAM is reduced to the number of customers who purchase this
    special-purpose bootstrapping service.<br>
    <br>
    When we take on new work with OpenStack, we want everyone to have
    the potential to be winners.<br>
    <br>
    Regards<br>
    -steve<br>
      <br>
    <blockquote
cite="mid:CADstcNZjXjGgaYG1=wa=N6cW_XVs3SWEAOjsT+Q92=4Dshb8UQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div>BTW puppet seems to use similar proxy way to network
            device configuration. See link below</div>
          <div><a moz-do-not-send="true"
href="https://puppetlabs.com/blog/managing-f5-big-ip-network-devices-with-puppet">https://puppetlabs.com/blog/managing-f5-big-ip-network-devices-with-puppet</a><br>
          </div>
          <div><br>
          </div>
          <div>thanks</div>
          <div>prasadv</div>
          <div><br>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>