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 gu ys 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 issues 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 Carter IRC: cloudnull ________________________________________ From: Steven Dake (stdake) <std...@cisco.com> Sent: Wednesday, July 1, 2015 2:21 PM To: OpenStack Development Mailing List (not for usage questions); s...@yaple.net Subject: Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla On 7/1/15, 8:11 AM, "Ian Cordasco" <ian.corda...@rackspace.com> wrote: > > >On 6/30/15, 23:36, "Sam Yaple" <sam...@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.corda...@rackspace.com> wrote: >> >> >> >>On 6/29/15, 23:59, "Steven Dake (stdake)" <std...@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-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 >> >> >> >> >> >> > >__________________________________________________________________________ >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 __________________________________________________________________________ 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
