Open Stack

On 7/1/15, 3:50 PM, "Kevin Carter" <kevin.carter at RACKSPACE.COM> wrote:

>Steve, 
>
>The initial review you guys had done did help a bunch and it was great to
>work with you and everyone else in the channel. As you're aware, code
>base that you had tested was our Juno (stable at that time) release which
>has more than its fair share of Rackspace-isms. One of which is the
>requirement to have access to the upstream repository for the
>installation of its python bits. So within that release it is true that
>if the upstream repository were to go away a redeployment or the
>expansion of the stack would be impossible until service was restored.
>While you could always self host the upstream repos, there is an open
>rsync relay, that wasn't functionality baked into OSAD at that time.
>However, since your eval we've released Kilo which now provides for the
>ability to self-host all of the python bits / container images / and
>anything else you may need or want from within the infrastructure (that's
>the default and what we gate on). While this functionality existed in
>master when you guys had done the test it had not been officially
>released so its likely you had not looked into it at this point.
>Additionally, we've done a huge amount of work to separate Kilo / Master
>from what was done in Icehouse / Juno while also providing an upgrade
>path for our existing deployments which will ensure that deployers are
>able to take advantage of the general improvements throughout the stack
>in Kilo and beyond. We, like you, do still have to reliance on some
>upstream resources however the inclusion of the repo-server containers
>should thwart these issues. Our python bits are built once within that
>repo-server infrastructure and everything within the OSAD points to the
>internal repository for its source of truth. As I said, we still have
>some reliance on upstream and likely always will but once an OSAD
>deployment is online, in Kilo or Master, it should be able to redeploy
>itself indefinitely. Obviously there's still more that we can do to make
>this better, and we're getting there, but I don't believe the same
>theoretical i!
> ssues you had seen before are present now.
>
>All that said, great work on the Libery-1 release and I look forward to
>play with Kolla with these new bits sometime in the near future.

Kevin,

Thanks!

The development team did a fantastic job focusing in Liberty 1 - 14
blueprints - pretty amazing amount of work in a short 5 week cycle.  Plan
to see same level of focus to meet our Liberty-2 milestone goals and
deliver on our complete mission.

Regards
-steve

>
>--
>
>Kevin Carter
>IRC: cloudnull
>
>________________________________________
>From: Steven Dake (stdake) <stdake at cisco.com>
>Sent: Wednesday, July 1, 2015 2:21 PM
>To: OpenStack Development Mailing List (not for usage questions);
>sam at yaple.net
>Subject: Re: [openstack-dev] [kolla][release] Announcing Liberty-1
>release of Kolla
>
>On 7/1/15, 8:11 AM, "Ian Cordasco" <ian.cordasco at RACKSPACE.COM> wrote:
>
>>
>>
>>On 6/30/15, 23:36, "Sam Yaple" <samuel at yaple.net> wrote:
>>
>>>Ian,
>>>
>>>
>>>The most significant difference would be that Kolla uses image based
>>>deployment rather than building from source on each node at runtime
>>>allowing for a more consistent and repeatable deployment.
>>>
>>
>>Do you mean specific docker images? Can you expand on how
>>os-ansible-deployment is not repeatable? They use an lxc-container cached
>>image so all containers are uniform (consistent, repeatable, etc.) and
>>build wheels (once) and use an internal repo mirror so that all
>>installations use the exact same set of wheels (e.g., consistent and
>>repeatable).
>>
>>Are there places where you've found osad to be not consistent or
>>repeatable?
>
>Ian,
>
>We did a 10 day eval of OSAD and liked the tech.  We did find the way the
>deployment pipeline works to be lacking.  A purely theoretical problem
>with the deployment pipeline is key repositories used to build the
>software could be offline.  Since the building of the software occurs
>during deployment, this could result in an inability to alter the
>configuration of the deployment after OpenStack is deployed.  Kolla
>suffers from this same problem during the installation (build pipeline)
>step.  But as long as you have already built images somewhere in your
>system, you are still able to deploy, avoiding complete downtime on
>deployment that OSAD could theoretically suffer.
>
>This theoretical issue makes the deployment non-repeatable.  Hope our 10
>day eval analysis helps improve OSAD.
>
>Regards
>-steve
>
>>
>>>
>>>On Tue, Jun 30, 2015 at 2:28 PM, Ian Cordasco
>>><ian.cordasco at rackspace.com> wrote:
>>>
>>>
>>>
>>>On 6/29/15, 23:59, "Steven Dake (stdake)" <stdake at cisco.com> wrote:
>>>
>>>>The Kolla community
>>>>is pleased to announce the
>>>> release of the
>>>> Kolla Liberty 1 milestone.  This release fixes 56 bugs
>>>> and implements 14 blueprints!
>>>>
>>>>
>>>>Our community developed the following notable features:
>>>>
>>>>
>>>>
>>>>* A start at
>>>>source-basedcontainers
>>>
>>>So how does this now compare to the stackforge/os-ansible-deployment
>>>(soon
>>>to be openstack/openstack-ansible) project?
>>>
>>>________________________________________________________________________
>>>_
>>>_
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe:
>>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>><http://OpenStack-dev-request@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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev