Re: [Openstack-operators] [kolla] Inviting Operators to participate in the specification of a new deployment tool
+1 I would much rather see this be a feature of any one of the vast number of deployment tools vs. creating yet another CM repo. On Sun, Jun 7, 2015 at 5:26 PM, James Denton james.den...@rackspace.com wrote: Hi Steven, Can I ask how Kolla would differ from another project on StackForge known as OpenStack Ansible Deployment (OSAD)? It deploys a production-ready multi-node OpenStack cloud using containers and Ansible, and the team recently released v11 based on Kilo. Hate to see duplication of efforts here. Thanks, James Sent from my iPhone On Jun 7, 2015, at 5:17 PM, Steven Dake (stdake) std...@cisco.com wrote: Hey folks, I am the PTL for a project called Kolla. We are currently a stackforge project but our developer community has tripled in size in the last few months. Our community mission was originally to “containerize OpenStack” but the next logical step after OpenStack is containerized is deployment. Our community wants to take a look at that mountain with a focus on simplicity. I’d like to invite Operators to provide their feedback on the fledgling blueprint I have created to mark the Kolla community’s commitment to develop an Ansible deployment tool that deploys OpenStack in containers. Please have a review and provide feedback here: https://review.openstack.org/#/c/189157/ Regards -steve ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Operations project: Packaging
On Sat, Nov 22, 2014 at 5:08 AM, Michael Chapman wop...@gmail.com wrote: On Thu, Nov 20, 2014 at 8:51 AM, Craig Tracey cr...@craigtracey.com wrote: Great input Kris. We also took a look at Anvil, and as you mention it is heavily biased for RH based distros. With regard to your requirements: 1) Under the cover for Giftwrap we use fpm for package creation, so debs and rpms are merely a flag to toggle. During the Paris session someone specifically mentioned they didn't want to use fpm, and wanted plain spec files instead. If that person is on this list, or if there's anyone else in that position, care to elaborate? Is there a specific limitation people are concerned about? 2) Giftwrap is targeted for precisely this workflow. We pull our OpenStack source from a forked git repo, with any patches applied. The giftwrap manifest allows for specification of repo as well as ref. I asked you about this in Paris, but for the benefit of the list, what about native packages? I find I need to package things like libvirt as well. As a community are we expecting to run one packaging tool for Openstack's python packages and one tool for everything else, or do we expect that to be combined into a single tool that can handle both? Giftwrap does not build native third-party packages. It is specifically focused on delivering artifacts for OpenStack. There are a number of cases where we need to build native packages as well, but we are using the standard Ubuntu tooling for doing so. The incidence for us needing this, though, is quite small. I do not think that any tool(s) that we converge around should be dealing with third party/system packaging. This would almost certainly introduce a slew of new items to support as well as incompatibilities/edge cases between distros. my 2c... craig 3) As mentioned earlier, the naming of the package is entirely up to you - also something that may be defined in the manifest. Hope that helps, Craig On Wed, Nov 19, 2014 at 3:38 PM, Kris G. Lindgren klindg...@godaddy.com wrote: I am also interested in the packaging discussion. As many of you guys already know, we use anvil https://github.com/stackforge/anvil for building of our packages. The tool is currently geared towards Redhat, however it will also build all of the required pip deps as packages as well. It also has all the hooks in place that are needed to work with deb's however the main users of it are primarily centos based. It also, recently, has the ability to build venvs for the packages as well, however we currently uses packages vs's venvs. The spec files are based upon rdo's spec files, so generated packages work correctly with upstream puppet modules. While I am not biased towards any tools set – For a tool to replace anvil for us it needs to be able to do the following: 1.) Build rpms 2.) Allows us to carry our own patch sets. Either by building from our own git repo or by supplying patch files that are integrated at either download or package build time on top of the upstream git repo 3.) Control the naming of the package, so that upgrades can easily happen (IE yum update). PBR really sucks at generating package names that can be easily upgraded when working of a git branch. I am not against modifying our workflow to make venvs work for us as well. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. From: Craig Tracey cr...@craigtracey.com Date: Wednesday, November 19, 2014 at 12:59 PM To: Adam Young ayo...@redhat.com Cc: openstack-operators@lists.openstack.org openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] Operations project: Packaging Thanks Michael for continuing this conversation. This is something that we are particularly interested and involved in. A while back (around the first Ops mid-cycle), I along with John Dewey started a project called giftwrap https://github.com/blueboxgroup/giftwrap. The primary objective was to build artifacts (in our first use case, debs) so that we could easily ship reliable OpenStack bits to our various OpenStack fleets, while not being beholden to a distro. I looked around at the available options in stackforge, and each of them didn't really suit my needs. Similarly, at the Ops midcycle it was clear that this was a concern for others as well. Hence, we started the project. The project has progressed quite a bit from there. Now, in addition to packages it can create Docker images with the projects and source that you care about. It can gather hard pip dependencies from what passed acceptance in gate. You can add arbitrary python and system dependencies (ie. you have SAN XYZ and their Cinder driver is not upstreamed yet) to the package or Docker image. And, all of the code is built within virtualenvs so that we can prevent cross-project dependency conflicts. Pathing is completely
Re: [Openstack-operators] Operations project: Packaging
Thanks Michael for continuing this conversation. This is something that we are particularly interested and involved in. A while back (around the first Ops mid-cycle), I along with John Dewey started a project called giftwrap https://github.com/blueboxgroup/giftwrap. The primary objective was to build artifacts (in our first use case, debs) so that we could easily ship reliable OpenStack bits to our various OpenStack fleets, while not being beholden to a distro. I looked around at the available options in stackforge, and each of them didn't really suit my needs. Similarly, at the Ops midcycle it was clear that this was a concern for others as well. Hence, we started the project. The project has progressed quite a bit from there. Now, in addition to packages it can create Docker images with the projects and source that you care about. It can gather hard pip dependencies from what passed acceptance in gate. You can add arbitrary python and system dependencies (ie. you have SAN XYZ and their Cinder driver is not upstreamed yet) to the package or Docker image. And, all of the code is built within virtualenvs so that we can prevent cross-project dependency conflicts. Pathing is completely customizable with Jinja templating syntax. What is nice about this is that you can lay services side-by-side in order to facilitate in-place upgrades (ie. /opt/openstack-icehouse and /opt/openstack-juno). All of these settings are defined in a yaml manifest file. The code today is certainly biased towards Ubuntu, but there is nothing preventing the support of other distros. All of the hooks are there...it's just a matter of time before we tackle those. We would be happy to have contributions from others interested in this or other features. This code, along with the accompanying configuration management is working in test and should land in both Giftwrap and our Ansible playbooks dubbed Ursula https://github.com/blueboxgroup/ursula shortly. Long story short, we are very interested in continuing to build community around packaging. Thanks again, Craig On Tue, Nov 18, 2014 at 7:37 AM, Adam Young ayo...@redhat.com wrote: On 11/18/2014 01:16 AM, Michael Chapman wrote: Hi all, Packaging was one of the biggest points of interest in the Friday Paris meeting, and I'd like to use this thread to have a centralised discussion and/or argument regarding whether there is a packaging system that is flexible enough that we can adopt it as a community and reduce the fragmentation. This conversation began in Paris, but will likely continue for some time. The Friday session indicates that as operators we have common requirements: A system that takes the sources from upstream projects and produces artifacts (packages or images). There are numerous projects that have attempted to solve this problem. Some are on stackforge, some live outside. If you are an author or a user of one of these systems, please give your opinion. RDO is the single largest packager of RPMs for OpenStack. Once it becomes clear who is interested in this topic, we can create a working group that will move towards standardising on a single system that meets the needs of the community. Once the key individuals for this project are clear, we can schedule an appropriate meeting time on irc for further discussion that will probably be needed. - Michael ___ OpenStack-operators mailing listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Proposal for an 'Operations' project
+1000 to what Matt said. Another point worth considering is that operations-type projects are often in a fast-follow mode. All of areas of interest (logging, packaging, monitoring, etc.) are effectively out of band from anything OpenStack proper. We should be able to release these at our own cadence, and in response to changes made in OpenStack projects as well as those in third-party projects (Nagios, Sensu, ELK, etc). This type of work is already happening in the Puppet and Chef projects under Stackforge. And, I am all for extending this work with additional operations-focused Stackforge repos. While it would be nice if this work was recognized with things like ATC status, I really do not think that is the goal here. On Sat, Nov 8, 2014 at 10:08 AM, Fischer, Matt matthew.fisc...@twcable.com wrote: On 11/8/14, 9:10 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-11-07 22:25:49 +0100 (+0100), Jonathan Proulx wrote: [...] An Ops Project feels weird to me. [...] To me as well. Perhaps this is the operator community coming to the realization that they don't need to be separate from the developer community. I've never really quite understood the distinction myself... I spent pretty much all my career before now as a sysadmin and network administrator, and I help write software to automate systems/network administration tasks. I don't get why some people feel it's necessary to grasp for a distinction between those, and furthering that identity crisis merely underscores the artificial dichotomy imposed by corporate management organization charts. I come from a software development background, so in my mind, the idea of a this project has nothing to do with organizational, role, or job title distinctions, nor is it about having a PTL and ATCs. This is mainly about the fact that operators share the same set of challenges and tasks. We have realized that we¹re all spending a large part of our time repeating the same things and solving the same problems. Most of us are forced to be generalists trying to burn down our OpenStack deployment tech debt, when many would love to have some time to solve more interesting problems. If someone can share a package building solution, a set of Icinga scripts, and etc, it allows me to move on to something else with more focus and more value to my org. As of now, I don¹t really see a place for what we¹ve discussed on Friday in existing projects. Perhaps some of the code fits in some places as previously mentioned on the list, but the issue is that none of those projects really focus on operations. The projects are inevitably developer focused, despite the best attempts to get operator feedback. I also don¹t consider this a rush to incubation, just the start of a discussion. So let¹s keep it going. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [Octavia] PTL and core team members
I'd like to nominate Brandon Logan and Doug Wiegley as core members. On Thu, Jun 19, 2014 at 6:18 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: Howdy y'all! Among other things that happened at the Neutron LBaaS mid-cycle hackathon, we have now put together process around, and established Octavia as a stackforge project. For those just joining us, Octavia is going to become an open-source operator-grade load balancer implementation. It will consume the Neutron LBaaS driver API, and be a consumer of Neutron, Nova, and other OpenStack APIs to deliver load balancing services. (It is not meant to supplant Neutron LBaaS, or be a general solution which can work with any vendor back-end. Think of it as another load balancer vendor.) Anyway, since we want to run this project with the intent of eventually being incubated, we'd like to get it off the ground using standard OpenStack methodologies, processes, and best practices. This also means that we need a PTL and team of core developers who will have +2 voting status on code and spec reviews for the project. I'd like to throw my hat into the ring for PTL. I'm not sure how elections on this should work (other than being open). But in any case, I also think that core developers for this project should probably come from the companies who have been active in the discussion of LBaaS in the last few months who are also interested in contributing to the Octavia project. Who would you like to see as PTL and core developers in this project? Thanks, Stephen -- Stephen Balukoff Blue Box Group, Inc. (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] LBaaS Mid Cycle Sprint
WebEx is here: https://a10networks.webex.com/a10networks/e.php?MTID=m3351a8eb388c2ade866bac44cc272c5b On Tue, Jun 17, 2014 at 12:13 PM, Susanne Balle sleipnir...@gmail.com wrote: We are now on: #openstack-lbaas The #neutron-lbaas is now deprecated. On Tue, Jun 17, 2014 at 11:10 AM, Dustin Lundquist dus...@null-ptr.net wrote: Actually the channel name is #neutron-lbaas. On Tue, Jun 17, 2014 at 8:03 AM, Kyle Mestery mest...@noironetworks.com wrote: Also, pop into #openstack-lbaas on Freenode, we have people there monitoring the channel. On Tue, Jun 17, 2014 at 9:19 AM, Dustin Lundquist dus...@null-ptr.net wrote: We have an Etherpad going here: https://etherpad.openstack.org/p/juno-lbaas-mid-cycle-hackathon Dustin On Tue, Jun 17, 2014 at 4:05 AM, Avishay Balderman avish...@radware.com wrote: Hi As the lbass mid cycle sprint starts today, is there any way to track and understand the progress (without flying to Texas... ) Thanks Avishay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Updated Object Model?
Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Updated Object Model?
Thanks Stephen, One nit and one question - For each of the tables with status fields we will want to have status_description fields as well. This is already a part of the V2 models. - How does this model handle things like implementation-specific options and/or things like additional headers? I'm thinking of some of those very common cases with http/https...X-Forwarded-For, httpclose, etc. Best, Craig On Wed, May 14, 2014 at 1:32 PM, Stephen Balukoff sbaluk...@bluebox.netwrote: Aah-- and here's a small error correction. :) Please also note: * We're not yet in consensus on the L7 or SSL related objects, but the Loadbalancer, Listener, Pool, and Member should probably not change at this point (unless there are major objections voiced in the very near term). * I've tried to use color coordination to indicate different logical parts that can probably be implemented in different blueprints / by different engineering teams. * The LBtoListener object is grayed out because it will need to exist in the database (to allow Listeners to be re-used, solving the IPv4 + IPv6 common use case), but should not be directly addressable via the user API. (This is also the reason it's got no tenant_id.) * The vip group and vip anti group stuff is meant to solve the vip colocation / apolocation problem. These are optional objects that don't need to be created unless a user has colocation / apolocation needs. (I'd be happy to run anyone through the logic on how these work, as it's probably not immediately intuitive.) Stephen On Wed, May 14, 2014 at 10:22 AM, Stephen Balukoff sbaluk...@bluebox.netwrote: Also, apologies for the crappy formatting. I like gv files as they're easily tracked in a text-based revision control system (like git) that depends on useful diffs to do code reviews. But sometimes the layout it chooses is a little dumb. Stephen On Wed, May 14, 2014 at 10:18 AM, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi Craig, I'm attaching the latest object model diagram as discussed with the RAX team last night, Samuel and Eugene. Note that we don't necessarily have HP's blessing on this model yet, nor do we have Neutron core developer buy in. But in any case, here it is. Also, I think the #openstack-lbaas channel is a great idea! Stephen On Wed, May 14, 2014 at 9:05 AM, Craig Tracey cr...@craigtracey.comwrote: Hi all, From what I heard last night, it sounds like there has been some consensus achieved around the LBaaS object model. Unfortunately, I missed this ad-hoc conversation. Is someone capturing this information and/or perhaps posting to the list? someplace else? On a related note, does it make sense to create an lbaas IRC topic channel? #openstack-lbaas? Just thinking that a dedicated channel might help to make the weekly meetings more productive with less crosstalk. Thoughts? Best, Craig ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request for Barbican
++ As someone who has required patches to Barbican (and not affiliated with Rackspace) I can attest to the fact that my, albeit simple, changes have been reviewed and merged in a timely and constructive manner. Even if the project were to bring on a flood of new developers it wouldn't move this commit diversity metric for quite some time. There is already a need for a keystore and I think this need will only grow. So why not support it as its own composable service? Thanks for all the work on Barbican! On Dec 17, 2013 6:17 PM, Bhandaru, Malini K malini.k.bhand...@intel.com wrote: Barbican, key manager is essential to openstack, paves the way to greater security. Instead of rejecting the project because of its current existence owed so heavily to Rackspace and to John Wood, why not we adopt it, code review, contribute code etc. We can have cores from multiple companies. Swift was a project that was born similarly. During development John Wood and the whole Rackspace team has been open to feature design discussions and providing good code review. Intel plans to create a plugin for Barbican, along the lines of a low cost HSM, essentially using the Intel TXT and the Trusted Platform Module to save a master secret used to encrypt all the other secrets. Our Intel team is small and some of us had other distractions in October and November, but we are back and may even grow in strength. John, Jarret, and team, thank you for all the hard work. Malini -Original Message- From: Jarret Raim [mailto:jarret.r...@rackspace.com] Sent: Tuesday, December 17, 2013 11:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Incubation Request for Barbican On 12/13/13, 4:50 AM, Thierry Carrez thie...@openstack.org wrote: If you remove Jenkins and attach Paul Kehrer, jqxin2006 (Michael Xin), Arash Ghoreyshi, Chad Lung and Steven Gonzales to Rackspace, then the picture is: 67% of commits come from a single person (John Wood) 96% of commits come from a single company (Rackspace) I think that's a bit brittle: if John Wood or Rackspace were to decide to place their bets elsewhere, the project would probably die instantly. I would feel more comfortable if a single individual didn't author more than 50% of the changes, and a single company didn't sponsor more than 80% of the changes. I think these numbers somewhat miss the point. It is true that Rackspace is the primary sponsor of Barbican and that John Wood is the developer that has been on the project the longest. However, % of commits is not the only measure of contributions to the project. That number doesn¹t include the work on our chef-automation scripts or design work to figure out the HSM interfaces or work on the testing suite or writing our documentation or the million other tasks for the project. Rackspace is committed to this project. If John Wood leaves, we¹ll hire additional developers to replace him. There is no risk of the project lacking resources because a single person decides to work on something else. We¹ve seen other folks from HP, RedHat, Nebula, etc. say that they are interested in contributing and we are getting outside contributions today. That will only continue, but I think the risk of the project somehow collapsing is being overstated. There are problems that aren¹t necessarily the sexiest things to work on, but need to be done. It may be hard to get a large number of people interested in such a project in a short period of time. I think it would be a mistake to reject projects that solve important problems just because the team is a bit one sided at the time. Jarret ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
