On 7/1/15, 3:50 PM, "Kevin Carter" <kevin.car...@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) <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 __________________________________________________________________________ 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