Re: [openstack-dev] [packaging-rpm][meeting] Proposal for new meeting time

[Thomas Bechtold]

Works for me.

Tom

On 19.04.2018 16:17, Javier Pena wrote:

Hello fellow packagers,

During today's meeting [1], we discussed the schedule conflicts some of us have 
with the current meeting slot. As a result, I would like to propose a new 
meeting time:

- Wednesdays, 1 PM UTC (3 PM CEST)

So far, dirk and jruzicka agreed with the change. If you have an issue, please 
reply now.

Regards,
Javier Peña

__
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

Re: [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Solar" release

[Thomas Bechtold]

Hey,

On 30.03.2018 16:26, Kashyap Chamarthy wrote:
[...]

Taking the DistroSupportMatrix into picture, for the sake of discussion,
how about the following NEXT_MIN versions for "Solar" release:

(a) libvirt: 3.2.0 (released on 23-Feb-2017)


[...]


(b) QEMU: 2.9.0 (released on 20-Apr-2017)


[...]

Works both for openSUSE and SLES.

Best,

Tom

__
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-dev] Queens packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

Queens packages for openSUSE and SLES are now available at:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Queens/

We maintain + test the packages for SLES 12SP3 and openSUSE Leap 42.3.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks and have a lot of fun,

Tom

__
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

Re: [openstack-dev] [ceilometer] Retiring ceilometerclient

[Thomas Bechtold]

Hi,

On 11.01.2018 01:18, gordon chung wrote:



On 2018-01-10 06:44 PM, Doug Hellmann wrote:

It's worth pointing out that openstacksdk has ceilometer REST API
support in it, although it is special-cased since ceilometer was retired
before we even made the service-types-authority:


so ceilometer's REST API does not exist anymore. i don't believe it was
even packaged in Pike (at least i don't have have an rpm for it in my
environment).


It was at lease for openSUSE: 
https://build.opensuse.org/package/show/Cloud:OpenStack:Pike/openstack-ceilometer


Tom

__
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

Re: [openstack-dev] [manila] Nominating Zhong Jun (zhongjun) for Manila core

[Thomas Bechtold]

+1

On 20.11.2017 00:29,  Ravi, Goutham  wrote:

Hello Manila developers,

I would like to nominate Zhong Jun (zhongjun on irc, zhongjun2 on 
gerrit) to be part of the Manila core team. Zhongjun has been an 
important member of our community since the Kilo release, and has, in 
the past few releases made significant contributions to the 
constellation of projects related to openstack/manila [1]. She is also 
our ambassador in the APAC region/timezones. Her opinion is valued 
amongst the core team and I think, as a core reviewer and maintainer, 
she would continue to help grow and maintain our project.


Please respond with a +1/-1.

We will not be having an IRC meeting this Thursday (23^rd November 
2017), so if we have sufficient quorum, PTL extraordinaire, Ben 
Swartzlander will confirm her nomination here.


[1] 
http://stackalytics.com/?user_id=jun-zhongjun=all=person-day


Thanks,

Goutham



__
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

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Thomas Bechtold]

Hi,

On 10.10.2017 13:04, Jesse Pretorius wrote:

On 9/29/17, 7:18 AM, "Thomas Bechtold" <tbecht...@suse.com> wrote:


This will still install the files into usr/etc :



$ python setup.py install --skip-build --root /tmp/sahara-install > 
/dev/null
$ ls /tmp/sahara-install/usr/
bin  etc  lib



It's not nice but packagers can workaround that.


I gave this a try this morning:

$ python setup.py install --skip-build --root /tmp/keystone --install-data /
$ find /tmp/keystone -maxdepth 6 -type d
/tmp/keystone
/tmp/keystone/usr
/tmp/keystone/usr/local
/tmp/keystone/usr/local/bin
/tmp/keystone/usr/local/lib
/tmp/keystone/usr/local/lib/python2.7
/tmp/keystone/usr/local/lib/python2.7/dist-packages
/tmp/keystone/usr/local/lib/python2.7/dist-packages/keystone-12.0.0.0rc2.dev101.egg-info
/tmp/keystone/usr/local/lib/python2.7/dist-packages/keystone
/tmp/keystone/etc
/tmp/keystone/etc/keystone

Is this perhaps useful?


Now the python files are in usr/local which is wrong for distros. It 
should be usr/


Tom

__
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

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Thomas Bechtold]

Hi,

On 09.10.2017 12:36, Jesse Pretorius wrote:
[...]
We have agreement from packagers for Ubuntu [1] and RDO [2] to include 
the files in the relative path /share. This seems to be the least 
offensive. OpenStack-Ansible supports the inclusion of the files, 
regardless of path [3].


There was acceptance of the /etc relative path from a SuSE packager [4]. 
Thomas Bechtold – could you comment on whether the relative path of 
/share is also good for SuSE packaging?


Works for me.


Tom

__
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

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Thomas Bechtold]

hi,

On 29.09.2017 12:56, Jesse Pretorius wrote:

On 9/29/17, 7:18 AM, "Thomas Bechtold" <tbecht...@suse.com> wrote:

 This will still install the files into usr/etc :
 It's not nice but packagers can workaround that.

Yes, that is true. Is there a ‘better’ location to have them? I noticed that 
Sahara was placing the files into share, resulting in them being installed into 
/usr/share – is that better?


There is /etc [1]

Best,

Tom

[1] 
http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcHostspecificSystemConfiguration


__
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

Re: [openstack-dev] [packaging][all] Sample Config Files in setup.cfg

[Thomas Bechtold]

Hi,

On 28.09.2017 16:50, Jesse Pretorius wrote:
[...]
Do any packagers or deployment projects have issues with this 
implementation? If there are any issues, what’re your suggestions to 
resolve them?


This will still install the files into usr/etc :

$ python setup.py install --skip-build --root /tmp/sahara-install > 
/dev/null

$ ls /tmp/sahara-install/usr/
bin  etc  lib

It's not nice but packagers can workaround that.

Best,

Tom

__
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

Re: [openstack-dev] [neutron] mod_wsgi support (pike bug?)

[Thomas Bechtold]

Hi Victor,

On 13.09.2017 17:37,  Morales, Victor  wrote:

As far as I remember the reason to have everything on a single file is because 
we’re trying to make Apache to load the configuration values during the startup.


Hm. I don't understand. With config-dirs, the service automatically 
reads also the extra files from the directories.

Am I missing something?

Best,

Tom



On 9/6/17, 9:19 PM, "Thomas Bechtold" <tbecht...@suse.com> wrote:

 Hi Kevin,
 
 On 04.09.2017 15:01, Kevin Benton wrote:

 > Yes, unfortunately I didn't make it back to the patch in time to adjust
 > devstack to dump all of the configuration into one file (instead of
 > /etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc).
 
 You don't have to put everything into one file. oslo.config supports per

 service config files and conf.d dirs[1].
 So eg. dhcp_agent.ini could be put into
 /etc/neutron/neutron-dhcp-agent.conf.d/foo.conf (it must end with .conf).
 Maybe that's more readable than a single huge config file?
 
 Best,
 
 Tom
 
 [1] https://docs.openstack.org/releasenotes/oslo.config/ocata.html#id2
 
 
 __

 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

Re: [openstack-dev] [neutron] mod_wsgi support (pike bug?)

[Thomas Bechtold]

Hi Kevin,

On 04.09.2017 15:01, Kevin Benton wrote:
Yes, unfortunately I didn't make it back to the patch in time to adjust 
devstack to dump all of the configuration into one file (instead of 
/etc/neutron/neutron.conf /etc/neutron/plugins/ml2.conf etc).


You don't have to put everything into one file. oslo.config supports per 
service config files and conf.d dirs[1].
So eg. dhcp_agent.ini could be put into 
/etc/neutron/neutron-dhcp-agent.conf.d/foo.conf (it must end with .conf).

Maybe that's more readable than a single huge config file?

Best,

Tom

[1] https://docs.openstack.org/releasenotes/oslo.config/ocata.html#id2


__
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-dev] Pike packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

Pike packages for openSUSE and SLES are now available at:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Pike/

We maintain + test the packages for SLES 12SP3 and openSUSE Leap 42.3.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks and have a lot of fun,

Tom

__
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

Re: [openstack-dev] Minimum version of shred in our supported distros?

[Thomas Bechtold]

Hey,

On 21.08.2017 02:59, Tony Breeds wrote:

On Mon, Aug 21, 2017 at 10:40:31AM +1000, Michael Still wrote:

If there's really only one distro which hasn't updated, I'd also be
inclined to try and push them to update before they move to Queens. Surely
that's a thing we can ask them nicely to do?


It might also be that SLES-11 isn't a thing we need to care about[1] and
SLES-12 is fine.  I guess give it a few days to give the SLES folks a
chance to chime in.


We do not need to care about SLE11. And SLE12 and openSUSE-Leap-42 all 
have coreutils > 8.22 .


Cheers,

Tom

__
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-dev] [rpm-packaging] ptl for queens

[Thomas Bechtold]

Hi,

I announce my candidacy for the PTL of the Packaging RPM project.

I have been a contributor to various OpenStack projects since Havana and I'm
one of the initial cores of the packaging RPM project. The project goal is
to produce a production-ready set of OpenStack packages for RPM-based systems
(like SLES, RHEL, openSUSE, Fedora, etc.).

As a PTL, I would focus on:

- python3 support. The currently available packages are python2 only.
  Distros are moving to python3 as default so providing python3 packages
  (starting with the libs and clients) should be done now.

- getting more services packaged. We currently have most of the libs
  and clients available but there are a lot of services still missing.

- Improve tooling. There are still things that can be automated when
  new packages are created or available ones updated.


Thanks,
Tom

__
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-dev] Ocata packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

Ocata packages for openSUSE and SLES are now available at:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Ocata/

We currently maintain + test the packages for SLE 12SP2 and openSUSE
Leap 42.2.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks and have a lot of fun,

Tom

__
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

Re: [openstack-dev] [Packaging-RPM] Nominating Alberto Planas Dominguez for Packaging-RPM core

[Thomas Bechtold]

+1

Welcome Alberto!


On Thu, 2017-02-16 at 17:43 +0300, Igor Yozhikov wrote:
> Hello team.
> I want to announce the following changes to Packaging-RPM core team:
> I’d like to nominate Alberto Planas Dominguez known as aplanas on irc
> for Packaging-RPM core.
> Alberto done a lot of reviews for as for project modules [1],[2] as
> for rest of OpenStack components [3]. His experience within OpenStack
> components and packaging are very appreciated.
> 
> 
> [1] http://stackalytics.com/?metric=marks_type=all=pac
> kaging-rpm-group_id=aplanas
> [2] http://stackalytics.com/?metric=marks_type=all=pac
> kaging-rpm-group
> [3] http://stackalytics.com/?user_id=aplanas=marks
> 
> Packaging-RPM team please respond with +1/-1 to the proposed changes.
> 
> Thanks,
> Igor Yozhikov
> Senior Deployment Engineer
> at Mirantis
> skype: igor.yozhikov
> cellular: +7 901 5331200
> slack: iyozhikov
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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

Re: [openstack-dev] [nova] Next minimum libvirt version

[Thomas Bechtold]

On Fri, 2017-02-10 at 12:35 -0600, Matt Riedemann wrote:
> On 2/10/2017 11:18 AM, Thomas Bechtold wrote:
> > 
> > For SUSE the wiki is updated and 1.2.9 should be fine.
> > 
> > 
> > Cheers,
> > 
> > Tom
> > 
> 
> Thanks Tom.
> 
> Would 1.3.1 as the next minimum in Queens be acceptable for SUSE?

Yes.

Cheers,

Tom

__
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

Re: [openstack-dev] [nova] Next minimum libvirt version

[Thomas Bechtold]

Hi,

On Thu, 2017-02-09 at 17:29 -0600, Matt Riedemann wrote:
> Since danpb hasn't been around I've sort of forgotten about this, but
> we 
> should talk about bumping the minimum required libvirt version in
> nova.
> 
> Currently it's 1.2.1 and the next was set to 1.2.9.
> 
> On master we're gating on ubuntu 14.04 which has libvirt 1.3.1
> (14.04 
> had 1.2.2).
> 
> If we move to require 1.2.9 that effectively kills 14.04 support for 
> devstack + libvirt on master, which is probably OK.
> 
> There is also the distro support wiki [1] which hasn't been updated
> in 
> awhile.

For SUSE the wiki is updated and 1.2.9 should be fine.


Cheers,

Tom

__
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

Re: [openstack-dev] [L2-Gateway] RPM packaging and Agent configuration

[Thomas Bechtold]

Hi,

On Thu, Dec 22, 2016 at 04:16:28PM +0100, Ricardo Noriega De Soto wrote:
> Thanks a lot Ofer!!
> 
> Just one more question, the command to start the agent is fine, but, do we
> need to include the l2gateway_plugin.ini to Neutron server???

with a recent oslo.config, you can just drop a config snippet into
/etc/neutron/neutron-server.conf.d/ . But that only works if
neutron-server does not override the default config dirs while starting
(so *no* --config-dir must be given).

Also it would be nice if you could propose your spec file to the
rpm-packaging project (https://wiki.openstack.org/wiki/Rpm-packaging ).

Best,

Tom

> 
> Something like:
> 
> /usr/bin/neutron-server --config-file /usr/share/neutron/neutron-dist.conf
> --config-dir /usr/share/neutron/server --config-file
> /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini
> --config-dir /etc/neutron/conf.d/common --config-dir
> /etc/neutron/conf.d/neutron-server --log-file
> /var/log/neutron/server.log *--config-file
> /etc/neutron/l2gateway_plugin.ini *???
> 
> Thanks!!
> 
> On Sun, Dec 18, 2016 at 8:33 AM, Ofer Ben-Yacov 
> wrote:
> 
> > The command that you've wrote for the agent is correct.
> > No need to add anything.
> >
> > Ofer.
> >
> > On 16 December 2016 at 16:12, Ricardo Noriega De Soto  > > wrote:
> >
> >> Hello L2GW devs!
> >>
> >> I'm currently working on the RPM packaging of networking-l2gw project.
> >>
> >> My undestanding is that depending on the config, I could use whether
> >> OpenDaylight or the neutron-l2gw-agent as backend.
> >>
> >> For the latter case, I'm writing a systemd unit file, but I'd love to get
> >> the command of how you launch the agent itself. I would say it's something
> >> like:
> >>
> >> https://paste.fedoraproject.org/507402/89715214/
> >>
> >> /usr/bin/neutron-l2gw-agent --config-file /etc/neutron/neutron.conf
> >> --config-file /etc/neutron/l2gateway_agent.ini  --log-file
> >> /var/log/neutron/l2gw-agent.log
> >>
> >> Anything to add??
> >>
> >> Thanks!
> >>
> >> --
> >> Ricardo Noriega
> >>
> >> Senior Software Engineer - NFV Partner Engineer | Office of Technology
> >>  | Red Hat
> >> irc: rnoriega @freenode
> >>
> >>
> >> 
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
> >> e
> >> 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
> >
> >
> 
> 
> -- 
> Ricardo Noriega
> 
> Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
> Red Hat
> irc: rnoriega @freenode

> __
> 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

Re: [openstack-dev] [manila] propose adding gouthamr to manila core

[Thomas Bechtold]

Great idea! +1!

Tom
On Wed, Nov 02, 2016 at 08:09:27AM -0400, Tom Barron wrote:
> I hereby propose that we add Goutham Pacha Ravi (gouthamr on IRC) to the
> manila core team.  This is a clear case where he's already been doing
> the review work, excelling both qualitatively and quantitatively, as
> well as being a valuable committer to the project.  Goutham deserves to
> be core and we need the additional bandwidth for the project.  He's
> treated as a de facto core by the community already.  Let's make it
> official!
> 
> -- Tom Barron
> 
> __
> 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

Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services

[Thomas Bechtold]

On Tue, Oct 11, 2016 at 12:32:40PM -0600, Alex Schultz wrote:
> On Tue, Oct 11, 2016 at 1:39 AM, Thomas Bechtold <tbecht...@suse.com> wrote:
> > Hi,
> >
> > On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote:
> >> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold <tbecht...@suse.com> 
> >> wrote:
> >> > Hi,
> >> >
> >> > in the rpm-packaging project we started to package the services and are
> >> > currently discussing a possible schema for configuration files and
> >> > snippets used by the systemd .service files (but this would also affect
> >> > OCF resource agents).
> >> > This affects packagers, endusers and config management systems (Chef,
> >> > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
> >> > the list.
> >>
> >> This also affects deployment tools so you may want to include tripleo,
> >> kolla, fuel as they are downstream consumers and may have their own
> >> assumptions about how services are launched.
> >
> > Done.
> >
> >> > Most services (at least for SUSE and RDO) are using a single config
> >> > (e.g. /etc/nova/nova.conf) when starting the service. Some services
> >> > (e.g. neutron services like neutron-l3-agent) use multiple config files.
> >> >
> >> > There are multiple problems with that approach:
> >> > - when using a config-mgmt-system, users may want to override a config
> >> > option (for a feature that is not yet supported) but the
> >> > config-mgmt-system will override the config later again.
> >>
> >> Just to chime in here from a puppet standpoint, this is not a problem
> >> because we provide a way for a user to add any extra options they wish
> >> using the provider so it always ends up in the correct configuration
> >> file.
> >
> > Does that also work if you need extra configuration files for 3rd party
> > plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd
> > party config file content to the needed neutron config but that's ugly imo.
> >
> 
> Plugins also have their own .ini files and are handled differently.
> They get weird but we put the service configs in
> /etc/neutron/neutron.conf and agent configs get put in .ini files.

So you put the config sections from the plugins into the neutron conf
and mix things, right?

> >> > - when users adjust /etc/$service/$service.conf and a release update is
> >> > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
> >> > overridden. That's good because the user changed something but otoh the
> >> > file (with all it's config options and comments) is no longer correct.
> >>
> >> Depending on the configuration management tool, the 'default' options
> >> and comments may not even be there so I'm not sure this is actually
> >> that much of a concern.  Also when you upgrade there is usually some
> >> sort of upgrade process that has to go along with your configuration
> >> management tool which should take care of this for you. So i'm not
> >> sure this needs to be a packaging concern.
> >>
> >> > - when config-mgmt-systems use templates for the $service.conf file,
> >> > updating theses templates is a lot of work.
> >>
> >> Yes which is why tools that don't use templates in the configuration
> >> management tool makes this a non-issue.  I'm not sure this needs to be
> >> a concern of packagers as it's an issue with the configuration
> >> management tool of choice and many of these tools have switched away
> >> from templates or are currently handling this.  If the configuration
> >> management tool doesn't support this or is suffering from this, simply
> >> adding conf.d support might help but then you also run into issues
> >> about ensuring things are removed and cleaned up.
> >
> > There *are* config-mgmt-tools still using templates. And having the
> > possibility to add config snippets simplifies the process here without
> > any downside for available solutions. Just don't use it if you don't
> > need it.
> >
> 
> Yes there are but that's not a packaging concern other than providing
> a simple way to not have to deal with constantly managing
> $service.conf.  I'm ok with a conf.d folder, but I guess that's more
> of a question for folks who have to manage those templates today as to
> what their prefered method is. Speaking from experience with a tool
> that we try not to use templates, my preferenc

Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services

[Thomas Bechtold]

Hi,

On Tue, Oct 11, 2016 at 06:22:25PM +, Andrew Woodward wrote:
[snipped]
> > > So I agree this is more likely a real problem, but i'm not sure this
> >
> > > should be solved by packaging as this probably needs to be addressed
> >
> > > in upstream.  Unless this is already a thing and it's just never been
> >
> > > properly implemented when deployed via packages. The issue I have with
> >
> > > only solving this via rpm packaging is that for tools that support
> >
> > > both rpms and debs this would lead to 2 different configuration
> >
> > > mechanisms.  So I would vote not to do anything different then what
> >
> > > debs also do unless both packaging methods are updated at the same
> >
> > > time.
> >
> >
> >
> > Don't you have already a lot of different implementations for rpm
> >
> > vs. deb, different apache config dir styles, different package name, ...
> >
> > Improving the rpm side only if the deb side also changes is not going to
> >
> > work I think.
> >
> >
> That isn't the issue here, both sides need to agree that this is a good
> path forward and agree on some general structure here, and to a large
> extent this is an upstream openstack issue to break the service configs
> apart. As a config-mgmt-system collaborator, I can tell you that we have to
> cover what ever deviation either side comes up with, and roughly gauging
> what you are proposing to do here will have a massive impact to how we
> configure services on RHEL derivatives which could easily take an entire
> cycle for the Puppet team to implement support.

Hm. Maybe you missunderstand the proposal. You would need to change
absolutly *nothing*. Your config-mgmt-system would just work.
And in addition, people/config-mgmt-systems which want to use snippets
can simply do it.

> If both sides aren't
> supporting a similar structure, then things really start to become messy
> for us, as we'd have multiple code paths to configure the two styles (and
> all the issues that come from that). We can account for minor nuances in
> the distros like package names, or config file locations quite easily, but
> you are asking for us to put different config elements into entirely
> different structures.

I'm not asking you todo anything. The proposal is compatible with the
solutions that are already available.

Maybe as a small reminder - this proposal is from the rpm-packaging team
which *unifies* the packaging for SUSE, RDO and Miranis. So it will be
*simpler* for you because all theses distro will have the same package
structure.

> > > Do we have any examples or instances where an end user would
> >
> > > specifically want to configure two of the services in a conflicting
> >
> > > fashion?  Or are there configuration options that fall into this
> >
> > > pattern? I thought the service specific items where in their own
> >
> > > configuration namespace to allow for such things. I would assume that
> >
> > > the bigger issue would be wanting to run two of the same service on
> >
> > > the same host with different configurations I would think that's where
> >
> > > something like containers would handle this case better than trying to
> >
> > > have multiple configuration files.
> >
> >
> >
> > In HA case you may want to set the hostname for all cinder-volumes to
> >
> > the same name but to something different for cinder-api (if both
> >
> > services run on the same host). I'm sure there are other examples.
> >
> >
> >
> > > > So here's the proposal to fix theses problems. The proposal is based on
> >
> > > > what RDO is already doing with neutron and extends it a bit. Let's do
> > it
> >
> > > > for Nova as an example:
> >
> > > >
> >
> > > > - /usr/share/nova/nova-dist.conf
> >
> > > > This is the configuration file a distribution (openSUSE, RDO, ...) can
> >
> > > > modify. It must not be modified by endusers and will be overridden with
> >
> > > > package updates
> >
> Seems to be a normal process, I'm not against it. I like to have the full,
> and commented out config in /etc/nova/nova.conf to reference as it's the
> expected location (ie nova-dist.conf with everything commented out) but
> that is my preference
> 
> > > - /etc/nova/nova.conf
> >
> > > > This is an empty file . Users/config-mgmt-systems can modify it and it
> >
> > > > will not be overridden (if changed) with a package update.
> >
> 
> The mandatory user needs to edit these values or the service can't start
> type (mostly credentials, uri for keystone, etc) should be set here and not
> be hidden in the -dist.conf files.

Sure. That's the intention.

> 
> > >
> >
> > > > - /etc/nova/conf.d/common/
> >
> > > > In this directory, config snippets can be added. By convention,
> >
> > > > config-mgmt-systems would install files starting with 100-XXX.conf,
> >
> > > > endusers would install files starting with 500-XXX.conf . Also this
> >
> > > > directory is used by all services (nova-api, nova-compute, ...).
> >
> 
> I'm against this, It makes no sense to config-mgmt-systems 

Re: [openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA][tripleo][kolla][fuel] Schema proposal for config file handling for services

[Thomas Bechtold]

Hi,

On Mon, Oct 10, 2016 at 10:07:05AM -0600, Alex Schultz wrote:
> On Mon, Oct 10, 2016 at 5:03 AM, Thomas Bechtold <tbecht...@suse.com> wrote:
> > Hi,
> >
> > in the rpm-packaging project we started to package the services and are
> > currently discussing a possible schema for configuration files and
> > snippets used by the systemd .service files (but this would also affect
> > OCF resource agents).
> > This affects packagers, endusers and config management systems (Chef,
> > Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
> > the list.
> 
> This also affects deployment tools so you may want to include tripleo,
> kolla, fuel as they are downstream consumers and may have their own
> assumptions about how services are launched.

Done.

> > Most services (at least for SUSE and RDO) are using a single config
> > (e.g. /etc/nova/nova.conf) when starting the service. Some services
> > (e.g. neutron services like neutron-l3-agent) use multiple config files.
> >
> > There are multiple problems with that approach:
> > - when using a config-mgmt-system, users may want to override a config
> > option (for a feature that is not yet supported) but the
> > config-mgmt-system will override the config later again.
> 
> Just to chime in here from a puppet standpoint, this is not a problem
> because we provide a way for a user to add any extra options they wish
> using the provider so it always ends up in the correct configuration
> file.

Does that also work if you need extra configuration files for 3rd party
plugins (e.g. neutron plugins) ? I guess you could just copy the 3rd
party config file content to the needed neutron config but that's ugly imo.

> > - when users adjust /etc/$service/$service.conf and a release update is
> > done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
> > overridden. That's good because the user changed something but otoh the
> > file (with all it's config options and comments) is no longer correct.
> 
> Depending on the configuration management tool, the 'default' options
> and comments may not even be there so I'm not sure this is actually
> that much of a concern.  Also when you upgrade there is usually some
> sort of upgrade process that has to go along with your configuration
> management tool which should take care of this for you. So i'm not
> sure this needs to be a packaging concern.
> 
> > - when config-mgmt-systems use templates for the $service.conf file,
> > updating theses templates is a lot of work.
> 
> Yes which is why tools that don't use templates in the configuration
> management tool makes this a non-issue.  I'm not sure this needs to be
> a concern of packagers as it's an issue with the configuration
> management tool of choice and many of these tools have switched away
> from templates or are currently handling this.  If the configuration
> management tool doesn't support this or is suffering from this, simply
> adding conf.d support might help but then you also run into issues
> about ensuring things are removed and cleaned up.

There *are* config-mgmt-tools still using templates. And having the
possibility to add config snippets simplifies the process here without
any downside for available solutions. Just don't use it if you don't
need it.

> > - setting configuration options per service (let's say cinder-volume
> > needs other config options than cinder-api) is not possible.
> 
> So I agree this is more likely a real problem, but i'm not sure this
> should be solved by packaging as this probably needs to be addressed
> in upstream.  Unless this is already a thing and it's just never been
> properly implemented when deployed via packages. The issue I have with
> only solving this via rpm packaging is that for tools that support
> both rpms and debs this would lead to 2 different configuration
> mechanisms.  So I would vote not to do anything different then what
> debs also do unless both packaging methods are updated at the same
> time.

Don't you have already a lot of different implementations for rpm
vs. deb, different apache config dir styles, different package name, ...
Improving the rpm side only if the deb side also changes is not going to
work I think.

> Do we have any examples or instances where an end user would
> specifically want to configure two of the services in a conflicting
> fashion?  Or are there configuration options that fall into this
> pattern? I thought the service specific items where in their own
> configuration namespace to allow for such things. I would assume that
> the bigger issue would be wanting to run two of the same service on
> the same host with different configurations I would think that's w

[openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA] Schema proposal for config file handling for services

[Thomas Bechtold]

Hi,

in the rpm-packaging project we started to package the services and are
currently discussing a possible schema for configuration files and
snippets used by the systemd .service files (but this would also affect
OCF resource agents).
This affects packagers, endusers and config management systems (Chef,
Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
the list.

Most services (at least for SUSE and RDO) are using a single config
(e.g. /etc/nova/nova.conf) when starting the service. Some services
(e.g. neutron services like neutron-l3-agent) use multiple config files.

There are multiple problems with that approach:
- when using a config-mgmt-system, users may want to override a config
option (for a feature that is not yet supported) but the
config-mgmt-system will override the config later again.
- when users adjust /etc/$service/$service.conf and a release update is
done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
overridden. That's good because the user changed something but otoh the
file (with all it's config options and comments) is no longer correct.
- when config-mgmt-systems use templates for the $service.conf file,
updating theses templates is a lot of work.
- setting configuration options per service (let's say cinder-volume
needs other config options than cinder-api) is not possible.

So here's the proposal to fix theses problems. The proposal is based on
what RDO is already doing with neutron and extends it a bit. Let's do it
for Nova as an example:

- /usr/share/nova/nova-dist.conf
This is the configuration file a distribution (openSUSE, RDO, ...) can
modify. It must not be modified by endusers and will be overridden with
package updates

- /etc/nova/nova.conf
This is an empty file . Users/config-mgmt-systems can modify it and it
will not be overridden (if changed) with a package update.

- /etc/nova/conf.d/common/
In this directory, config snippets can be added. By convention,
config-mgmt-systems would install files starting with 100-XXX.conf,
endusers would install files starting with 500-XXX.conf . Also this
directory is used by all services (nova-api, nova-compute, ...).

- /etc/nova/conf.d/$service/ (e.g. /etc/nova/conf.d/nova-compute/)
Also a dir for config snippets (with same rules as for
/etc/nova/conf.d/common/ ) but this dir is only used by $service (in
this case nova-compute)

- /usr/share/doc/packages/openstack-nova/nova.conf.sample
The unmodified sample config from upstream

- /etc/nova/README
Explaining the configuration structure and where to find the whole
sample config.


So starting nova-api would be:
nova-api --config-file /usr/share/nova/nova-dist.conf
 --config-file /etc/nova/nova.conf
 --config-dir /etc/nova/conf.d/common/
 --config-dir /etc/nova/conf.d/nova-api/


The order of command line switches (--config-file/--config-dir) is
important here. Also --config-dir is ordering the files. So adding a
config snippet to /etc/nova/conf.d/nova-api/ with
e.g. [DEFAULT]bind_port would override the option from the previous
configs (last found option wins).


Feedback very welcome!

Cheers,

Tom

__
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-dev] Newton packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

Newton packages for openSUSE and SLES are now available at:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Newton/

We currently maintain + test the packages for SLE 12SP2 and openSUSE
Leap 42.2.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks!

Have a lot of fun,

Tom

__
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

Re: [openstack-dev] [packaging-rpm] Javier Peña as additonal core reviewer for packaging-rpm core group

[Thomas Bechtold]

On Fri, Sep 02, 2016 at 12:45:33PM +0200, Dirk Müller wrote:
> Hi,
> 
> I would like to suggest Javier Peña as an additional core reviewer for
> the packaging-rpm core group. He's been an extremely valueable
> contributor recently both doing regular reviews on the PRs as well as
> contributing more to the packaging effort overall.
> 
> See http://stackalytics.com/?user_id=jpena-c=rpm-packaging

+1 !

Best,

Tom

__
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

Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer team

[Thomas Bechtold]

+1  Tom will be a great addition!

On Thu, Aug 04, 2016 at 01:02:06PM +0300, Valeriy Ponomaryov wrote:
> Yeah, Tom consists of experience. +1
> 
> On Thu, Aug 4, 2016 at 12:35 PM, Ramana Raja  wrote:
> 
> > +1. Tom's reviews and guidance are helpful
> > and spot-on.
> >
> > -Ramana
> >
> > On Thursday, August 4, 2016 7:52 AM, Zhongjun (A) 
> > wrote:
> > > Subject: Re: [openstack-dev] [Manila] Nominate Tom Barron for core
> > reviewer team
> > >
> > >
> > >
> > > +1 Tom will be a great addition to the core team.
> > >
> > >
> > >
> > >
> > >
> > >
> > > 发件人 : Dustin Schoenbrun [mailto:dscho...@redhat.com]
> > > 发送时间 : 2016 年 8 月 4 日 4:55
> > > 收件人 : OpenStack Development Mailing List (not for usage questions)
> > > 主题 : Re: [openstack-dev] [Manila] Nominate Tom Barron for core reviewer
> > team
> > >
> > >
> > >
> > >
> > >
> > > +1
> > >
> > >
> > >
> > >
> > >
> > > Tom will be a marvelous resource for us to learn from!
> > >
> > >
> > >
> > >
> > >
> > > Dustin Schoenbrun
> > > OpenStack Quality Engineer
> > > Red Hat, Inc.
> > > dscho...@redhat.com
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Aug 3, 2016 at 4:19 PM, Knight, Clinton <
> > clinton.kni...@netapp.com >
> > > wrote:
> > >
> > >
> > > +1
> > >
> > >
> > >
> > >
> > >
> > > Tom will be a great asset for Manila.
> > >
> > >
> > > Clinton
> > >
> > >
> > >
> > >
> > >
> > > _
> > > From: Ravi, Goutham < goutham.r...@netapp.com >
> > > Sent: Wednesday, August 3, 2016 3:01 PM
> > > Subject: Re: [openstack-dev] [Manila] Nominate Tom Barron for core
> > reviewer
> > > team
> > > To: OpenStack Development Mailing List (not for usage questions) <
> > > openstack-dev@lists.openstack.org >
> > >
> > >
> > >
> > > (Not a core member, so plus 0.02)
> > >
> > >
> > >
> > > I’ve learned a ton of things from Tom and continue to do so!
> > >
> > >
> > >
> > >
> > > From: Rodrigo Barbieri < rodrigo.barbieri2...@gmail.com >
> > > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> > <
> > > openstack-dev@lists.openstack.org >
> > > Date: Wednesday, August 3, 2016 at 2:48 PM
> > > To: "OpenStack Development Mailing List (not for usage questions)" <
> > > openstack-dev@lists.openstack.org >
> > > Subject: Re: [openstack-dev] [Manila] Nominate Tom Barron for core
> > reviewer
> > > team
> > >
> > >
> > >
> > >
> > >
> > > +1
> > >
> > > Tom contributes a lot to the Manila project.
> > >
> > > --
> > > Rodrigo Barbieri
> > > Computer Scientist
> > > OpenStack Manila Core Contributor
> > > Federal University of São Carlos
> > >
> > >
> > >
> > >
> > >
> > > On Aug 3, 2016 15:42, "Ben Swartzlander" < b...@swartzlander.org > wrote:
> > >
> > >
> > >
> > > Tom (tbarron on IRC) has been working on OpenStack (both cinder and
> > manila)
> > > for more than 2 years and has spent a great deal of time on Manila
> > reviews
> > > in the last release. Tom brings another package/distro point of view to
> > the
> > > community as well as former storage vendor experience.
> > >
> > > -Ben Swartzlander
> > > Manila PTL
> > >
> > >
> > __
> > > 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
> >
> 
> 
> 
> -- 
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com
> vponomar...@mirantis.com

> __
> 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

Re: [openstack-dev] [nova] next min libvirt?

[Thomas Bechtold]

On Tue, May 03, 2016 at 10:08:06AM +0100, Daniel P. Berrange wrote:
> On Sat, Apr 30, 2016 at 10:28:23AM -0500, Thomas Bechtold wrote:
> > Hi,
> > 
> > On Fri, Apr 29, 2016 at 10:13:42AM -0500, Sean Dague wrote:
> > > We've just landed the libvirt min to bump us up to 1.2.1 required. It's
> > > probably a good time consider the appropriate bump for Otaca.
> > > 
> > > By that time our Ubuntu LTS will be 16.04 (libvirt 1.3.1), RHEL 7.1
> > > (1.2.8). Additionally Debian Jessie has 1.2.9. RHEL 7.2 is at 1.2.17.
> > >
> > > My suggestion is we set MIN_LIBVIRT_VERSION to 1.2.8. This will mean
> > > that NUMA support in libvirt (excepting the blacklists) and huge page
> > > support is assumed on x86_64.
> > 
> > Works also for SUSE which has 1.2.18 already in SLE 12 SP1.
> 
> Is there any public site where I can find details of what RPM versions
> are present in SLES releases ? I was trying to find details last week
> but was not able to find any info.

There is https://www.suse.com/products/server/technical-information/#Package
There's a link to the package list. For whatever reason this is not
there for SP1 yet.

> If there's no public reference, could
> you update the wiki with RPM details for libvirt, kvm and libguestfs:
> 
> https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix#Distro_minimum_versions

Done for both, SLES and openSUSE.

Cheers,

Tom

__
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

Re: [openstack-dev] [nova] next min libvirt?

[Thomas Bechtold]

Hi,

On Fri, Apr 29, 2016 at 10:13:42AM -0500, Sean Dague wrote:
> We've just landed the libvirt min to bump us up to 1.2.1 required. It's
> probably a good time consider the appropriate bump for Otaca.
> 
> By that time our Ubuntu LTS will be 16.04 (libvirt 1.3.1), RHEL 7.1
> (1.2.8). Additionally Debian Jessie has 1.2.9. RHEL 7.2 is at 1.2.17.
>
> My suggestion is we set MIN_LIBVIRT_VERSION to 1.2.8. This will mean
> that NUMA support in libvirt (excepting the blacklists) and huge page
> support is assumed on x86_64.

Works also for SUSE which has 1.2.18 already in SLE 12 SP1.

-- 
Tom

__
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

Re: [openstack-dev] mitaka features

[Thomas Bechtold]

Hi Kenny,

On Fri, Apr 08, 2016 at 01:24:29PM +0800, Kenny Ji-work wrote:
> The newest version called mitaka is released, what's the new features
> of this version. Or is there some documents to describe it? Thank you!

See the release notes for the different projects at:

http://releases.openstack.org/mitaka/index.html

Cheers,

Tom

__
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

Re: [openstack-dev] Mitaka packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

Mitaka packages with the released versions for openSUSE and SLES are now
available at:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Mitaka/

We currently maintain + test the packages for SLE 12SP1 and openSUSE
Leap 42.1.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks!

Have a lot of fun,

Tom

On Wed, Mar 30, 2016 at 04:12:09PM +0200, Thomas Bechtold wrote:
> Hi,
> 
> In the last few weeks we've been working hard on stabilizing the Mitaka
> packages, and the packages currently available in Cloud:OpenStack:Mitaka
> [0] pass early testing.
> 
> Feel free to try them out by adding the repository:
> 
> http://download.opensuse.org/repositories/Cloud:/OpenStack:/Mitaka/$DI
> STRO/
> 
> to your repository list. We currently maintain + test the packages for
> SLE 12SP1 and openSUSE Leap 42.1.
> We also started to automatically  track the stable/mitaka branches for
> the different services so the packages are automatically updated when CI
> passes.
> 
> If you find issues, please do not hesitate to report them to
> opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/
> 
> Thanks !
> 
> Have a lot of fun,
> Tom
> 
> __
> 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

Re: [openstack-dev] [neutron][stable] Distros need stable/mitaka branches for subprojects (WAS: RDO needs stable/mitaka branches for subprojects WAS: Re: [Rdo-list] RDO Mitaka RC1 current status - tes

[Thomas Bechtold]

Hi,

On Fri, Apr 01, 2016 at 04:28:05PM +0200, Ihar Hrachyshka wrote:
> Haïkel  wrote:
> 
> >2016-04-01 16:17 GMT+02:00 Ihar Hrachyshka :
> >>Haïkel  wrote:
> >>
> >>
> >>
> >>Do we want to raise those issues to networking vendors? Do we have a
> >>list of
> >>what’s required from them for RDO?
> >>
> >>Ihar
> >
> >Yes, we need to raise their attention about this issue.
> >
> >As a distribution, it would help if they do proper releases (from
> >higher to lesser priority)
> >* tagged releases
> >* stable branches
> >* tarballs uploaded
> >
> >Bare minimum is tagging releases and documented compatibility against
> >neutron releases, as our CI can't test these backends features.
> >
> >Regards,
> >H.
> 
> Hi all,
> 
> it seems that RDO project needs networking-* subprojects to create
> stable/mitaka branches, tag releases from there, and upload tarballs to
> pypi, to be able to consume the code for those projects.
> 
> I presume it’s not just RDO, but other distributions that are interested in
> it.

Yes. For SUSE we are tracking the stable tarballs from
tarballs.openstack.org . But not all projects have yet a stable branch
which produce a stable tarball.

[snipped]

Cheers,

Tom

__
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-dev] Mitaka RC packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

In the last few weeks we've been working hard on stabilizing the Mitaka
packages, and the packages currently available in Cloud:OpenStack:Mitaka
[0] pass early testing.

Feel free to try them out by adding the repository:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Mitaka/$DI
STRO/

to your repository list. We currently maintain + test the packages for
SLE 12SP1 and openSUSE Leap 42.1.
We also started to automatically  track the stable/mitaka branches for
the different services so the packages are automatically updated when CI
passes.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks !

Have a lot of fun,
Tom

__
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

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

[Thomas Bechtold]

On Wed, Mar 09, 2016 at 12:28:59PM -0600, Matt Riedemann wrote:
[snipped]
> Ha, the irony.
> 
> OK, so I thought awhile back, around YVR summit time, there was a group of
> different packagers from different distros (debian/red hat/fedora/suse) that
> were working together on some common tooling.
> 
> Is that still a thing and if so, do they congregate somewhere? Because
> *that's* where I think people need to go, not the #openstack-stable channel.

For RPM, there is #openstack-rpm-packaging. See
https://wiki.openstack.org/wiki/Rpm-packaging

-- 
Tom

__
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

Re: [openstack-dev] How do I calculate the semantic version prior to a release?

[Thomas Bechtold]

On Sat, Feb 27, 2016 at 08:12:25AM +1300, Robert Collins wrote:
> On 27 February 2016 at 01:34, Thomas Bechtold <tbecht...@suse.com> wrote:
> > On Fri, Feb 26, 2016 at 06:52:03AM -0500, Doug Hellmann wrote:
> >> Excerpts from Neil Jerram's message of 2016-02-26 11:27:05 +:
> >> > On 26/02/16 11:16, Neil Jerram wrote:
> > [snipped]
> >> > v = version.VersionInfo('networking-calico').semantic_version()
> >> > print v.release_string()
> >> > print v.brief_string()
> >> > print v.debian_string()
> >> > print v.rpm_string()
> >>
> >> Those do work. I found that there's also an rpm_version command
> >> available like this:
> >>
> >>   python setup.py rpm_version
> >
> > The output for i.e. for Manila is here "1...b3.dev138"
> >
> > Which is not really correct. The version is "2.0.0.0b3.dev138" .
> > rpm supports the tilde ("~") for pre versions. Converting a PEP440
> > compatible version to a rpm version can be done with code like:
> 
> Does it? Thats great. It didn't as far as anyone here knew when we
> wrote the spec -
> http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/juno/pbr-semver.rst
> - or we'd have avoiding a tonne of complexity. I see from
> http://www.rpm.org/ticket/56 that it only came in in RPM 4.10 - is RPM
> 4.10 available on all the RPM platforms we support? Including I guess
> old RHEL's and stuff?

Good question. For SUSE, SLE12 has rpm 4.11 which is fine. No idea about RHEL.

-- 
Tom

__
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

Re: [openstack-dev] How do I calculate the semantic version prior to a release?

[Thomas Bechtold]

On Fri, Feb 26, 2016 at 06:52:03AM -0500, Doug Hellmann wrote:
> Excerpts from Neil Jerram's message of 2016-02-26 11:27:05 +:
> > On 26/02/16 11:16, Neil Jerram wrote:
[snipped]
> > v = version.VersionInfo('networking-calico').semantic_version()
> > print v.release_string()
> > print v.brief_string()
> > print v.debian_string()
> > print v.rpm_string()
> 
> Those do work. I found that there's also an rpm_version command
> available like this:
> 
>   python setup.py rpm_version

The output for i.e. for Manila is here "1...b3.dev138"

Which is not really correct. The version is "2.0.0.0b3.dev138" .
rpm supports the tilde ("~") for pre versions. Converting a PEP440
compatible version to a rpm version can be done with code like:

https://github.com/openSUSE/obs-service-set_version/blob/master/set_version#L231

Cheers,

-- 
Tom

__
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

Re: [openstack-dev] [Manila] Nominate Rodrigo Barbieri for core reviewer team

[Thomas Bechtold]

On Tue, Feb 02, 2016 at 12:30:44PM -0500, Ben Swartzlander wrote:
> Rodrigo (ganso on IRC) joined the Manila project back in the Kilo release
> and has been working on share migration (an important core feature) for the
> last 2 releases. Since Tokyo he has dedicated himself to reviews and
> community participation. I would like to nominate him to join the Manila
> core reviewer team.

+2 . Keep up the good work Rodrigo!

-- 
Tom

__
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-dev] [ec2api] stable/liberty release?

[Thomas Bechtold]

Hi,

are there plans to release a stable/liberty tarball of the ec2api ?
There is a stable/kilo branch but I can't find one for liberty.

Cheers,

Tom



__
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

Re: [openstack-dev] [rpm-packaging] core reviewers nomination

[Thomas Bechtold]

On Mon, 2015-11-02 at 23:23 +0900, Haïkel wrote:
> I'd like to propose new candidates for RPM packaging core reviewers:
> Alan Pevec
> Jakub Ruzicka
> 
> Both are involved in downstream RDO project and this group creation.
> Alan is part of the stable release team and Jakub has been working on
> our tooling since the beginning.
> Having them onboard as core reviewers would help accelerate the
> bootstrap of the project.
> 
> RPM packaging core, please vote with +/- 1.

+1

Cheers,

Tom


__
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

Re: [openstack-dev] [Nova][Manila] Nova API to attach/detach file volume/share

[Thomas Bechtold]

On Mon, 2015-10-26 at 22:13 -0700, Sage Weil wrote:
[snipped]
> If you're at the summit, I'll be talking a bit about this on
> Wednesday at 
> 4:40 (http://sched.co/4A03).

The link doesn't work for me. Can you resent or post the room?

TIA

Tom

__
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

Re: [openstack-dev] [Nova][Manila] Nova API to attach/detach file volume/share

[Thomas Bechtold]

On Mon, 2015-10-26 at 22:13 -0700, Sage Weil wrote:
[snipped]
> If you're at the summit, I'll be talking a bit about this on
> Wednesday at 
> 4:40 (http://sched.co/4A03).

The link doesn't work for me. Can you resent or post the room?

TIA

Tom

__
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

Re: [openstack-dev] [Nova][Manila] Nova API to attach/detach file volume/share

[Thomas Bechtold]

On Mon, 2015-10-26 at 22:13 -0700, Sage Weil wrote:
[snipped]
> If you're at the summit, I'll be talking a bit about this on
> Wednesday at 
> 4:40 (http://sched.co/4A03).

The link doesn't work for me. Can you resent or post the room?

TIA

Tom

__
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-dev] Liberty packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

I already announced the availability of the RC packages a couple of
weeks ago and I'm pleased to announce the availability of stable
Liberty packages for openSUSE and SLES!
The packages are available on build.opensuse.org in the
Cloud:OpenStack:Liberty project[1].

Updates to the stable/liberty branches for the different service are
automatically tracked and tested via Tempest before the updates move
into the Cloud:OpenStack:Liberty buildservice project.

If you find issues, please do not hesitate to report them to
opensuse-
cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks !

Have a lot of fun,
Tom


__
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-dev] Liberty RC2 packages for openSUSE and SLES available

[Thomas Bechtold]

Hi,

In the last few weeks we've been working hard on stabilizing the Libert
y packages, and the packages currently available in
Cloud:OpenStack:Liberty[0] pass early testing.

Feel free to try them out by adding the repository:

http://download.opensuse.org/repositories/Cloud:/OpenStack:/Liberty/$DI
STRO/

to your repository list. We currently maintain + test the packages for
SLE 12 and openSUSE 13.2. Packages for openSUSE Leap (42.1) and SLE
12SP1 will follow after theses products are released.

If you find issues, please do not hesitate to report them to
opensuse-cloud at opensuse.org or to https://bugzilla.opensuse.org/

Thanks !

Have a lot of fun,
Tom


[0] https://build.opensuse.org/project/show/Cloud:OpenStack:Liberty

__
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

Re: [openstack-dev] [barbican] python-barbicanclient-master.tar.gz outdated on tarballs.openstack.org

[Thomas Bechtold]

On Sun, 2015-08-30 at 12:49 +, Jeremy Stanley wrote:
> On 2015-08-30 10:23:32 +0200 (+0200), Thomas Bechtold wrote:
> [...]
> > Maybe the tarball won't be regenerated if only a new git tag is
> > pushed?
> > In that case the latest commit-id doesn't change but the content of
> > the
> > tarball need to change (from 3.2.1.dev24 to 3.3.0).
> 
> Correct, nobody has implemented a mechanism for our tarball jobs to
> identify which branch tips need regenerating when a tag is pushed,
> so the version numbers embedded within them will lag (potentially
> for long periods if those branches don't see much new activity). 

Can you point me to the code where this needs to be implemented?

> An
> alternative is to generate your own tarballs from the git repo with
> `tox -e venv python setup.py sdist` and consume the result from the
> dist subdirectory.

Yeah. But then the whole tarballs.openstack.org thingy is imo somehow
useless...

Cheers,

Tom

__
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

Re: [openstack-dev] [barbican] python-barbicanclient-master.tar.gz outdated on tarballs.openstack.org

[Thomas Bechtold]

On Sat, 2015-08-29 at 19:05 +, Jeremy Stanley wrote:
 On 2015-08-29 18:44:55 +0200 (+0200), Thomas Bechtold wrote:
  on http://tarballs.openstack.org/python-barbicanclient/ , master
  tarball is not the latest git version. Something seems to be
  broken.
  Any hints how to solve that?
 
 What makes you say that? The master branch tip as seen at
 http://git.openstack.org/cgit/openstack/python-barbicanclient/commit/
 ?h=master
 is a5f7531a0f37542be70d0cfbd0fd7f86a38b0539 and the log from the
 corresponding run of the python-barbicanclient-branch-tarball job at
 http://logs.openstack.org/a5/a5f7531a0f37542be70d0cfbd0fd7f86a38b0539
 /post/python-barbicanclient-branch-tarball/ef9d3c0/console.html.gz
 shows checksums matching the tarball I just downloaded from
 http://tarballs.openstack.org/python-barbicanclient/python-barbicancl
 ient-master.tar.gz
 so it seems correct to me at least. Can you elaborate?

Interessting. I recognized it because global requirements already has
barbicanclient = 3.3.0 but python-barbicanclient-master.tar.gz is
still 3.2.1.dev24 . So I wasn't able to install some packages because
of the missing dependency.
Maybe the tarball won't be regenerated if only a new git tag is pushed?
In that case the latest commit-id doesn't change but the content of the
tarball need to change (from 3.2.1.dev24 to 3.3.0).

Cheers,

Tom


__
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-dev] [barbican] python-barbicanclient-master.tar.gz outdated on tarballs.openstack.org

[Thomas Bechtold]

Hi,

on http://tarballs.openstack.org/python-barbicanclient/ , master
tarball is not the latest git version. Something seems to be broken.
Any hints how to solve that?

TIA,

Tom

__
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

Re: [openstack-dev] [neutron] How to make deb and rpm packages for a networking-* project?

[Thomas Bechtold]

On Mon, 2015-08-24 at 15:13 +, Neil Jerram wrote:
 Can anyone recommend how best to make deb and rpm packages for a
 networking-* project?

You can use the OpenBuildService (https://build.opensuse.org/) to build
packages for different distributions (SUSE, RedHat, CentOS, Debian,
Ubuntu, ...). 

 (Specifically, I mean for networking-calico, but I imagine, if
 there's a
 best current practice, that it would apply to all such projects.)
 
 I'm aware that there were recently some discussions on increased
 unification of OpenStack packaging, but I'm not sure where those
 ended up.

For RPM packaging, it's still under discussion. Mostly SUSE and RedHat
folks are working on that currently. See 
https://etherpad.openstack.org/p/openstack-rpm-packaging 

 I've also observed a few things from some quick searching:
 
 - Some pages talk about automatically creating an RPM or Debian
 package
 from a Python package's setup.py.  It appears that the Debian variant
 might be more experimental / less officially approved of than the RPM
 variant.

For RPMs there is py2pack. See 
https://en.opensuse.org/openSUSE:Packaging_Python .

 - There are official Debian packages (by zigo) for networking-arista
 and
 a few others, but not for all networking-* projects.  These fall
 through
 to Ubuntu/Launchpad as well.
 
 - There are Ubuntu-originated packages for (at least) networking-odl.
 
 So, all advice or pointers appreciated!


Best,

Tom

__
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

Re: [openstack-dev] [Manila] Contract of ShareDriver.deny_access

[Thomas Bechtold]

Hi Björn,

On Thu, 2015-08-20 at 14:30 +0200, Bjorn Schuberg wrote:
 Hello everyone,
 
 this is my first thread on this mailing list, and I would like to
 take the opportunity to say that it was great to see you all at the
 midcycle, even if remote.

Yeah. It was a nice meetup!

 Now, to my question; I've been looking into an issue that arise when
 deleting access to a share, and then momentarily after, deleting the
 same share. The delete fails due to a race in
 `_remove_share_access_rules` in the `ShareManager`, which attempts to
 delete all granted permissions on the share before removing it, but
 one of the access permissions is concurrently deleted due to the
 first API call, see;
 https://github.com/openstack/manila/blob/master/manila/share/manager.
 py#L600

Can you please fill a bug report? https://bugs.launchpad.net/manila . 


TIA

Tom

__
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

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

[Thomas Bechtold]

On Mon, 2015-08-17 at 13:36 +, Jeremy Stanley wrote:
 On 2015-08-17 15:25:07 +0200 (+0200), Thierry Carrez wrote:
 [...]
  I see Doug, Robert, Clark and myself as necessary to the
  discussion
 [...]
 
 It would also be great to get some of the operators and/or package
 maintainers involved since they were the ones arguing against the
 original and much simpler proposal (no longer making stable branch
 point releases at all). 

SUSE packaging is tracking every commit from the stable branches and
generates packages from that. It's fully automated. So it doesn't
matter for SUSE if we create releases or not.


Cheers,

Tom

__
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

Re: [openstack-dev] [Manila] Nominate Clinton Knight for core team

[Thomas Bechtold]

On 02.04.2015 15:16, Ben Swartzlander wrote:
 Clinton Knight (cknight on IRC) has been working on OpenStack for the
 better part of the year, and starting in February, he shifted his focus
 from Cinder to Manila. I think everyone is already aware of his high
 quality contributions and code reviews. I would like to nominate him to
 join the Manila core reviewer team.

+1

__
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

Re: [openstack-dev] [Manila] Nominate Igor Malinovskiy for core team

[Thomas Bechtold]

On 18.03.2015 20:04, Ben Swartzlander wrote:
 Igor (u_glide on IRC) joined the Manila team back in December and has
 done a consistent amount of reviews and contributed significant new core
 features in the last 2-3 months. I would like to nominate him to join
 the Manila core reviewer team.

+1

__
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