Hi Shake, Kolla is mainly used for containerzing OpenStack components. But before that, Kolla needs installer to do node discovery as well as OS provisioning. So there should be a installer at the first place which then calls into Kolla or alternative s such as packstack to deploy OpenStack.
I agree with you that sometimes we do need the installer to run in the context of a container, but it mainly because we want to save a dedicated jump server. On May 31, 2016 2:57 PM, "Shake Chen" <shake.c...@gmail.com> wrote: > Hi Zhijiang > > I think you can put Daisy into docker, then use ansible or kolla deploy > Daisy. > > > > On Tue, May 31, 2016 at 9:43 AM, <hu.zhiji...@zte.com.cn> wrote: > >> Hi All, >> >> I would like to introduce to you a new OpenStack installer project >> Daisy(project name: daisycloud-core). Daisy used to be a closed source >> project mainly developed by ZTE, but currently we make it a OpenStack >> related project(http://www.daisycloud.org, >> https://github.com/openstack/daisycloud-core). >> >> Although it is not mature and still under development, Daisy concentrates >> on deploying OpenStack fast and efficiently for large data center which has >> hundreds of nodes. In order to reach that goal, Daisy was born to focus on >> many features that may not be suitable for small clusters, but definitely >> conducive to the deployment of big clusters. Those features include but not >> limited to the following: >> >> 1. Containerized OpenStack Services >> In order to speed up installation and upgrading as a whole, Daisy decides >> to use Kolla as underlying deployment module to support containerized >> OpenStack services. >> >> 2. Multicast >> Daisy utilizes multicast as much as possible to speed up imaging work >> flow during the installation. For example, instead of using centralized >> Docker registry while adopting Kolla, Daisy multicasts all Docker images to >> each node of the cluster, then creates and uses local registries on each >> node during Kolla deployment process. The Same things can be done for OS >> imaging too. >> >> 3. Automatic Deployment >> Instead of letting users decide if a node can be provisioned and deserved >> to join to the cluster, Daisy provide a characteristics matching mechanism >> to recognize if a new node has the same capabilities as a current working >> computer nodes. If it is true, Daisy will start deployment on that node >> right after it is discovered and make it a computer node with the same >> configuration as that current working computer nodes. >> >> 4. Configuration Template >> Using precise configuration file to describe a big dynamic cluster is not >> applicable, and it is not able to be reused when moving to another >> approximate environment either. Daisy’s configuration template only >> describes the common part of the cluster and the representative of the >> controller/compute nodes. It can be seen as a semi-finished configuration >> file which can be used in any approximate environments. During deployment, >> users only have to evaluate few specific parameters to make the >> configuration template a final configuration file. >> >> 5. Your comments on anything else that can brings unique value to the >> large data center deployment? >> >> As the project lead, I would like to get feedback from you about this new >> project. You are more than welcome to join this project! >> >> Thank you >> Zhijiang >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail (and >> any attachment transmitted herewith) is privileged and confidential and is >> intended for the exclusive use of the addressee(s). If you are not an >> intended recipient, any disclosure, reproduction, distribution or other >> dissemination or use of the information contained is strictly prohibited. >> If you have received this mail in error, please delete it and notify us >> immediately. >> >> >> >> >> __________________________________________________________________________ >> 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 >> >> > > > -- > Shake Chen > > > __________________________________________________________________________ > 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
