Re: [Openstack-operators] [openstack-dev] [kolla] Berlin summit resume
Thanks for the write up Eduardo. I thought you and Surya did a good job of presenting and moderating those sessions. Mark On Wed, 21 Nov 2018 at 17:08, Eduardo Gonzalez wrote: > Hi kollagues, > > During the Berlin Summit kolla team had a few talks and forum discussions, > as well as other cross-project related topics [0] > > First session was ``Kolla project onboarding``, the room was full of > people interested in contribute to kolla, many of them already using kolla > in production environments whiling to make upstream some work they've done > downstream. I can say this talk was a total success and we hope to see many > new faces during this release putting features and bug fixes into kolla. > Slides of the session at [1] > > Second session was ``Kolla project update``, was a brief resume of what > work has been done during rocky release and some items will be implemented > in the future. Number of attendees to this session was massive, no more > people could enter the room. Slides at [2] > > > Then forum sessions.. > > First one was ``Kolla user feedback``, many users came over the room. > We've notice a big increase in production deployments and some PoC > migrating to production soon, many of those environments are huge. > Overall the impressions was that kolla is great and don't have any big > issue or requirement, ``it works great`` became a common phrase to listen. > Here's a resume of the user feedback needs [3] > > - Improve operational usage for add, remove, change and stop/start nodes > and services. > - Database backup and recovery > - Lack of documentation is the bigger request, users need to read the code > to know how to configure other than core/default services > - Multi cells_v2 > - New services request, cyborg, masakari and tricircle were the most > requested > - SElinux enabled > - More SDN services such as Contrail and calico > - Possibility to include user's ansible tasks during deploy as well as > support custom config.json > - HTTPS for internal networks > > Second one was about ``kolla for the edge``, we've meet with Edge > computing group and others interested in edge deployments to identify > what's missing in kolla and where we can help. > Things we've identified are: > > - Kolla seems good at how the service split can be done, tweaking > inventory file and config values can deploy independent environments easily. > - Missing keystone federation > - Glance cache support is not a hard requirement but improves efficiency > (already merged) > - Multi cells v2 > - Multi storage per edge/far-edge > - A documentation or architecture reference would be nice to have. > > Last one was ``kolla for NFV``, few people came over to discuss about > NUMA, GPU, SRIOV. > Nothing noticiable from this session, mainly was support DPDK for > CentOS/RHEL,OracleLinux and few service addition covered by previous > discussions. > > [0] https://etherpad.openstack.org/p/kolla-stein-summit > [1] > https://es.slideshare.net/EduardoGonzalezGutie/kolla-project-onboarding-openstack-summit-berlin-2018 > [2] > https://es.slideshare.net/EduardoGonzalezGutie/openstack-kolla-project-update-rocky-release > [3] https://etherpad.openstack.org/p/berlin-2018-kolla-user-feedback > [4] https://etherpad.openstack.org/p/berlin-2018-kolla-edge > [5] https://etherpad.openstack.org/p/berlin-2018-kolla-nfv > __ > 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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [kayobe][kolla] Announcing the release of Kayobe 4.0.0
Hi, Announcing the release of Kayobe 4.0.0. This release includes support for the Queens release of OpenStack, and is the first release of Kayobe built using the OpenStack infrastructure. Release notes: https://kayobe-release-notes.readthedocs.io/en/latest/queens.html#relnotes-4-0-0-stable-queens Documentation: https://kayobe.readthedocs.io Thanks to everyone who contributed to this release! Looking forward, we intend to catch up with the OpenStack release cycle, by making a smaller release with support for OpenStack Rocky, then moving straight onto Stein. Cheers, Mark ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [kolla][ptg] Denver PTG on-site or virtual
Whether there is a physical PTG session or not, I'd certainly like to meet up with other folks who are using and/or contributing to Kolla, let's be sure to make time for that. Mark On 17 August 2018 at 12:54, Adam Harwell wrote: > As one of the other two in the etherpad, I will say that I was looking > forward to getting together face to face with other contributors for the > first time (as I am new to the project), but I guess the majority won't > actually be there, and I understand that we need to do what is best for the > majority as well. > I know that at least one or maybe two other people from my team were also > planning to attend some Kolla sessions, so I'll see if I can get them to > sign up. > The other projects I'll be focused on are Octavia and Barbican, and I know > both have been successful with a hybrid approach in the past (providing > video of the room and allowing folks to dial in and contribute, while also > having a number of people present physically). > Since the room is already reserved, I don't see a huge point in avoiding > its use either. > > --Adam > > > On Fri, Aug 17, 2018, 20:27 Mark Goddard wrote: > >> As one of the lucky three kolleagues able to make the PTG, here's my >> position (inline). >> >> On 17 August 2018 at 11:52, Eduardo Gonzalez wrote: >> >>> Fellow kolleages. >>> >>> In september is Denver PTG, as per the etherpad [0] only 3 contributors >>> confirmed their presence in the PTG, we expected more people to be there as >>> previous PTGs were full of contributors and operators. >>> >>> In the last kolla meeting [1] with discussed if we should make a virtual >>> PTG rather than a on-site one as we will probably reach a bigger number of >>> attendance. >>> >>> This set us in a bad possition as per: >>> >>> If we do an on-site PTG >>> >>> - Small representation for a whole cycle design, being this one larger >>> than usual. >>> - Many people whiling to attend is not able to be there. >>> >> >> I agree that three is too small a number to justify an on-site PTG. I was >> planning to split my time between kolla and ironic, so being able to focus >> on one project would be beneficial to me, assuming the virtual PTG takes >> place at a different time. I could still split my time if the virtual PTG >> occurs at the same time. >> >> >>> >>> If we do a virtual PTG >>> >>> - Some people already spend money to travel for kolla PTG >>> >> >> I would be going anyway. >> >> >>> - PTG rooms are already reserved for kolla session >>> >> >> If the virtual PTG occurs at the same time, we could use the (oversized) >> reserved room to dial into calls. >> >> - No cross project discussion >>> >> >> Happy to attend on behalf of kolla and feed back to the team. >> >>> >>> If there are more people who is going to Denver and haven't signed up at >>> the etherpad, please confirm your presence as it will probably influence on >>> this topic. >>> >>> Here is the though question... >>> >>> What kind of PTG do you prefer for this one, virtual or on-site in >>> Denver? >>> >> >> Virtual makes sense to me. >> >>> >>> CC to Kendall Nelson from the foundation if she could help us on this >>> though decission, given the small time we have until the PTG both ways have >>> some kind of bad consecuencies for both the project and the contributors. >>> >>> [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning >>> [1] http://eavesdrop.openstack.org/meetings/kolla/2018/kolla. >>> 2018-08-15-15.00.log.html#l-13 >>> >>> Regards >>> >>> >>> __ >>> 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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [kolla][ptg] Denver PTG on-site or virtual
As one of the lucky three kolleagues able to make the PTG, here's my position (inline). On 17 August 2018 at 11:52, Eduardo Gonzalez wrote: > Fellow kolleages. > > In september is Denver PTG, as per the etherpad [0] only 3 contributors > confirmed their presence in the PTG, we expected more people to be there as > previous PTGs were full of contributors and operators. > > In the last kolla meeting [1] with discussed if we should make a virtual > PTG rather than a on-site one as we will probably reach a bigger number of > attendance. > > This set us in a bad possition as per: > > If we do an on-site PTG > > - Small representation for a whole cycle design, being this one larger > than usual. > - Many people whiling to attend is not able to be there. > I agree that three is too small a number to justify an on-site PTG. I was planning to split my time between kolla and ironic, so being able to focus on one project would be beneficial to me, assuming the virtual PTG takes place at a different time. I could still split my time if the virtual PTG occurs at the same time. > > If we do a virtual PTG > > - Some people already spend money to travel for kolla PTG > I would be going anyway. > - PTG rooms are already reserved for kolla session > If the virtual PTG occurs at the same time, we could use the (oversized) reserved room to dial into calls. - No cross project discussion > Happy to attend on behalf of kolla and feed back to the team. > > If there are more people who is going to Denver and haven't signed up at > the etherpad, please confirm your presence as it will probably influence on > this topic. > > Here is the though question... > > What kind of PTG do you prefer for this one, virtual or on-site in Denver? > Virtual makes sense to me. > > CC to Kendall Nelson from the foundation if she could help us on this > though decission, given the small time we have until the PTG both ways have > some kind of bad consecuencies for both the project and the contributors. > > [0] https://etherpad.openstack.org/p/kolla-stein-ptg-planning > [1] http://eavesdrop.openstack.org/meetings/kolla/2018/kolla. > 2018-08-15-15.00.log.html#l-13 > > Regards > > __ > 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-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Moving from distro packages to containers (or virtualenvs...)
> Hi there all-ye-operators, > I am investigating how to help move godaddy from rpms to a > container-like solution (virtualenvs, lxc, or docker...) and a set of > questions that comes up is the following (and I would think that some > folks on this mailing list may have some useful insight into the answers): > * Have you done the transition? We are currently in the middle of the transition to a containerized deployment solution for Cray's OpenStack-based System Management platform. > * How did the transition go? So far, so good. > * Was/is kolla used or looked into? or something custom? We evaluated both openstack-ansible and Kolla. Each has its advantages but Kolla won over thanks to its simplicity, speed of deployment and use of immutable containers. We're also using Kolla's ansible deployment tool. > * How long did it take to do the transition from a package based > solution (with say puppet/chef being used to deploy these packages)? For the first iteration we're still using a package-based solution. This is largely because we have considerable infrastructure built up around this. We're using OpenStack's Anvil tool, which I know you are familiar with, Josh :). Kolla supports installing from both packages and source, so we have the option of moving to source in future if it fits. >* Follow-up being how big was the team to do this? There are 4 of us working on this project. The work involved is considerably more than for an operator because we are building a platform based on OpenStack with multiple deployment environments. We estimated about 6 man-months. > > * What was the roll-out strategy to achieve the final container solution? This will be difficult. As others have said, we expect to do this one service at a time, and will add considerable automation around it. Migrating stateful services such as the DB and nova-compute will need care. > > Any other feedback (and/or questions that I missed)? > > Thanks, > Josh Thanks, Mark Cray, UK Ltd. Cray U.K. Limited is a limited company registered in England and Wales. Company Registration No. 03941275. Registered Office: 5 Fleet Place, London, EC4M 7RD, UK ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
