[openstack-dev] [tc][packaging][deb] retiring Packaging Deb project

Hi all, The Debian OpenStack packagers are gathered at the annual Debian developer event, and discussing the future of OpenStack packaging for Debian. There's general agreement that we'd like to go ahead and package Pike, but also agreement that we'd like to move back to the Debian infrastructure

Re: [openstack-dev] [PKG-Openstack-devel] The end of OpenStack packages in Debian?

On 02/24/2017 06:25 AM, Ritesh Raj Sarraf wrote: > rtslib-fb is a core component for the LIO(-fb) project. We already maintain > configshell-fb and targetcli-fb under pkg-linux-target group. Nod, that makes sense. I'd say you should take on maintenance of the rtslib-fb packages, as long as you're

Re: [openstack-dev] The end of OpenStack packages in Debian?

On 02/21/2017 12:57 PM, Ritesh Raj Sarraf wrote: > Hello Thomas, > > Sad to see this. But with so much free loading trend, these are bound to > happen. > > For the LIO-fb target in Debian, we've been depending on the rtslib-fb > package, > which you've maintained so far. Should we pick it up

Re: [openstack-dev] The end of OpenStack packages in Debian?

On 02/15/2017 07:42 AM, Thomas Goirand wrote: > I will continue to maintain OpenStack Newton during the lifetime of > Debian Stretch though, but I don't plan on doing anything more. This > means that maybe, Newton will be the last release of OpenStack in > Debian. If things continue this way, I

[openstack-dev] [all][survey] open source collaboration practices

Hi all, I’m running a brief (10 question) survey on the collaboration practices common to companies participating in open source today. I’d greatly appreciate a moment of your time to share your experience: https://www.surveymonkey.com/r/os-participation This survey is part of my academic

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

On 04/11/2016 02:51 PM, Fox, Kevin M wrote: > Yeah, I think there are two places where it may make sense. > > 1. Ironic's nova plugin is a lowst common denominator for treating a > physical host like a vm. Ironic's api is much more rich, but sometimes > all you need is the lowest common

Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)

> On Wed, Apr 6, 2016 at 1:11 PM, Davanum Srinivas wrote: >> Reading unofficial notes [1], i found one topic very interesting: >> One Platform – How do we truly support containers and bare metal under >> a common API with VMs? (Ironic, Nova, adjacent communities e.g. >>

Re: [openstack-dev] [all] A proposal to separate the design summit

On 02/22/2016 10:31 AM, Monty Taylor wrote: > On 02/22/2016 07:24 AM, Russell Bryant wrote: >> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > > wrote: >> >> Hi everyone, >> >> TL;DR: Let's split the events, starting after Barcelona.

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/15/2015 01:43 PM, Paul Belanger wrote: While I agree those points are valid, and going to be helpful, moving under OpenStack (even Stackforge) does also offer the chance to get more test integration upstream (not saying this was the original scope). However, this could also be achieved

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/15/2015 11:48 AM, Thomas Goirand wrote: On 06/15/2015 04:55 PM, James Page wrote: The problem of managing delta and allowing a good level of distribution independence is still going to continue to exist and will be more difficult to manage due to the tighter coupling of development

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/03/2015 03:31 PM, Haïkel wrote: 2015-06-03 23:41 GMT+02:00 Allison Randal alli...@lohutok.net: I have to disagree on that point, integration with underlying OS and low-level services is important. If that integration doesn't exists, it's off-loaded to the operators. So downstream

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/03/2015 01:30 PM, Sean Dague wrote: So wouldn't that be more of an arguement to move as much of the installation logic back into the python packages as possible. So that pip install nova was a thing that you could do, and get reasonable results, and then the packaging teams would

Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project

On 06/03/2015 07:22 AM, Thomas Goirand wrote: However, talking with James Page (from Canonical, head of their server team which does the OpenStack packaging), we believe it's best if we had 2 different distinct teams: one for Fedora/SuSe/everything-rpm, and one for Debian based distribution.

[openstack-dev] [all] developer survey on contribution policies

Hi all, I'm gathering input on developer perspectives about CLAs and other contribution policies. While you're clicking through voting for PTLs, I'd appreciate it if you could take an extra 5 minutes and click through the developer survey too: http://survey.lohutok.net/ I'm aiming for a broad

Re: [openstack-dev] [all] developer survey on contribution policies

On 09/28/2014 11:30 AM, Tim Bell wrote: Can you give some more details on the survey with respect to OpenStack ? I have both a developer contribution policy survey and a project contribution policy survey. It would also be good to have more background as to the interest in obtaining the

Re: [openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

On 09/23/2014 02:18 AM, Thierry Carrez wrote: The main goal of incubation, as we did it in the past cycles, is a learning period where the new project aligns enough with the existing ones so that it integrates with them (Horizon shows Sahara dashboard) and won't break them around release time

Re: [openstack-dev] [TripleO] a small experiment with Ansible in TripleO

On 08/04/2014 08:19 AM, Clint Byrum wrote: I've been fiddling on github. This repo is unfortunately named the same but is not the same ancestry as yours. Anyway, the branch 'fiddling' has a working Heat inventory plugin which should give you a hostvar of 'heat_metadata' per host in the given

[openstack-dev] [TripleO] a small experiment with Ansible in TripleO

A few of us have been independently experimenting with Ansible as a backend for TripleO, and have just decided to try experimenting together. I've chatted with Robert, and he says that TripleO was always intended to have pluggable backends (CM layer), and just never had anyone interested in

Re: [openstack-dev] [TripleO] a small experiment with Ansible in TripleO

On 08/01/2014 12:06 PM, Galbraith, Patrick wrote: I have been working on Ansible nova_compute, a new “nova_facts” module as well as the nova dynamic inventory plugin, so please do feel free to collaborate with me on this. Great, are you on #tripleo? I'm 'wendar', and I'm working on this bit.