[openstack-dev] [Freezer] PTL candidacy for Queens

2017-08-05 Thread Saad Zaher 
Hi All,

I'm happy to announce my candidacy to be the Freezer PTL for the Queens
release
cycle.

The Freezer developers did a very good job over the past releases and I am
sure
they will continue doing an amazing job over the next release as well.

In the Pike release, we have implemented more than one engine for OpenStack
like (nova, cinder, cinder_OSbrick, rsync...)
In the Queens release we need to set more focus on enhancing these engines
and make it work better and add more features to these engines.
Also for the Queens cycle we need to add more features to freezer-dr to
support more use cases of the disaster recovery scenarios,
In Pike we have change a little bit to allow the addition of more features
in the new relases.

In the Queens cycle, I think we are going to focus on the following items:


* Enhancing core freezer-agent features and continue refactoring the
missing parts
  to allow pluggable architecture to support more engines and applications
in freezer.
  Some refactoring has already been done, also some new engines and storage
driver
  has been added, so we need to keep those engines/drivers well maintained,
enhanced and up to date!

* Completed the move from Elasticsearch to Oslo.db

* Relate the backups, jobs, sessions, resources to tenants not to users.


* Integration tests. We need to increase the work done on testing. This will
  help to stabilize Freezer.

* Documentation. We should target for a split, refactoring and global
  improvement of our docs, which is a required step to increase the size of
our
  community.

* Implement remote backups. Allow the users to use any instance of
freezer-agent
  to backup remote resources to any storage driver

* Deprecate CLI. Freezer-agent will accept jobs only through configuration
  files not through CLI.

* Allow the engines/storage drivers to register their own OPTS

I would be honoured to have your support.

Thanks,
Saad Zaher (szaher)
__
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] [oslo][oslo.config] Pluggable drivers and protect plaintext secrets

2017-08-05 Thread Doug Hellmann 
Excerpts from Fox, Kevin M's message of 2017-08-04 21:46:05 +:
> Yeah, but you still run into stuff like db contact and driver information 
> being mixed up with secret used for contacting that service. Those should be 
> separate fields I think so they can be split/merged with that mechanism.

That is also supported, through value interpolation.

https://docs.openstack.org/oslo.config/latest/reference/cfg.html#option-value-interpolation

Doug

> 
> Thanks,
> Kevin
> 
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: Friday, August 04, 2017 1:49 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [oslo][oslo.config] Pluggable drivers and  
> protect plaintext secrets
> 
> Excerpts from Fox, Kevin M's message of 2017-08-04 20:21:19 +:
> > I would really like to see secrets separated from config. Always have... 
> > They are two separate things.
> >
> > If nothing else, a separate config file so it can be permissioned 
> > differently.
> >
> > This could be combined with k8s secrets/configmaps better too.
> > Or make it much easier to version config in git and have secrets somewhere 
> > else.
> 
> Sure. It's already possible today to use multiple configuration
> files with oslo.config, using either the --config-dir option or by
> passing multiple --config-file options.
> 
> Doug
> 
> >
> > Thanks,
> > Kevin
> >
> > 
> > From: Raildo Mascena de Sousa Filho [rmasc...@redhat.com]
> > Sent: Friday, August 04, 2017 12:34 PM
> > To: openstack-dev@lists.openstack.org
> > Subject: [openstack-dev] [oslo][oslo.config] Pluggable drivers and protect 
> > plaintext secrets
> >
> > Hi all,
> >
> > We had a couple of discussions with the Oslo team related to implement 
> > Pluggable drivers for oslo.config[0] and use those feature to implement 
> > support to protect plaintext secret on configuration files[1].
> >
> > In another hand, due the containerized support on OpenStack services, we 
> > have a community effort to implement a k8s ConfigMap support[2][3], which 
> > might make us step back and consider how secret management will work, since 
> > the config data will need to go into the configmap *before* the container 
> > is launched.
> >
> > So, I would like to see what the community think. Should we continue 
> > working on that pluggable drivers and protect plain text secrets support 
> > for oslo.config? Makes sense having a PTG session[4] on Oslo to discuss 
> > that feature?
> >
> > Thanks for the feedback in advance.
> >
> > Cheers,
> >
> > [0] https://review.openstack.org/#/c/454897/
> > [1] https://review.openstack.org/#/c/474304/
> > [2] 
> > https://github.com/flaper87/keystone-k8s-ansible/blob/6524b768d75a28adf44c74aca77ccf13dd66b1a9/provision-keystone-apb/tasks/main.yaml#L71-L108
> > [3] 
> > https://kubernetes.io/docs/tasks/configure-pod-container/configmap/
> > [4] https://etherpad.openstack.org/p/oslo-ptg-queens
> 

__
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] [keystone][api] Backwards incompatible changes based on config

2017-08-05 Thread Doug Hellmann 
Excerpts from Morgan Fainberg's message of 2017-08-04 14:52:18 -0700:
> On Fri, Aug 4, 2017 at 2:43 PM, Kevin L. Mitchell  wrote:
> > On Fri, 2017-08-04 at 16:45 -0400, Kristi Nikolla wrote:
> >> Is this the case even if we haven’t made any final release with the change
> >> that introduced this issue? [0]
> >>
> >> It was only included in the Pike milestones and betas so far, and was not
> >> part of the Ocata release.
> >
> > Maybe not, but please do recall that there are many deployers out there
> > that track master, not fixed releases, so we need to take that level of
> > compatibility into account.
> >
> 
> I am going to go out on a limb and say that we should not assume that
> if code merges ever it is a contract because someone might be
> following master. The contract should be for releases. We should do
> everything we can to avoid breaking people, but in the case of an API
> contract (behavior) that was never part of a final release, it should
> be understood this may change if needed until it is released.
> 
> This is just my $0.002 as this leads rapidly to "why bother having
> real releases" if everything is a contract, let someone take a
> snapshot where they're happy with the code to run. You're devaluing
> the actual releases.

I'm out here on this limb with you.

Doug

> 
> >> Therefore the call which now returns a 403 in master, returned a 2xx in
> >> Ocata. So we would be fixing something which is broken on master rather
> >> than changing a ‘contract’.
> >>
> >> 0. 
> >> https://github.com/openstack/keystone/commit/51d5597df729158d15b71e2ba80ab103df5d55f8
> >
> > I would be inclined to accept this specific change as a bug fix not
> > requiring a version bump, because it is a corner case that I believe a
> > deployer would view as a bug, if they encountered it, and because it
> > was introduced prior to a named final release.
> > --
> > Kevin L. Mitchell 
> > __
> > 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-dev] [gnocchi][ceilometer] gnocchi-metricd error using redis as coordination

2017-08-05 Thread Yaguang Tang 
Hi gnocchi devs,

I have an issue when using gnocchi 4.0, the storage backend is ceph, and
tooz coordination is redis. currently  gnocchi api in apache wsgi mode,
only one controller node running gnocchi-metricd & gnocchi-statsd daemon.
the error log of gnocchi-metricd is as follow.



2017-08-05 18:14:18.643 1329257 INFO gnocchi.storage.common.ceph [-] Ceph
storage backend use 'cradox' python library
2017-08-05 18:14:18.654 1329257 INFO gnocchi.storage.common.ceph [-] Ceph
storage backend use 'cradox' python library
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils [-] Unhandled
exception
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils Traceback (most
recent call last):
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/cotyledon/_utils.py", line 84, in
exit_on_exception
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils yield
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/cotyledon/_service.py", line 139, in _run
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils self.run()
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/gnocchi/cli.py", line 120, in run
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils self._configure()
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 87, in
wrapped_f
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return r.call(f,
*args, **kw)
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 177, in call
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
fut.result()
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/concurrent/futures/_base.py", line 396,
in result
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
self.__get_result()
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 159, in call
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils result =
fn(*args, **kwargs)
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/gnocchi/cli.py", line 193, in _configure
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils self.GROUP_ID,
partitions=200)
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/tooz/coordination.py", line 284, in
join_partitioned_group
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils return
partitioner.Partitioner(self, group_id)
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/tooz/partitioner.py", line 45, in __init__
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
partitions=self.partitions)
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/tooz/hashring.py", line 47, in __init__
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils
self.add_nodes(set(nodes))
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils   File
"/usr/lib/python2.7/site-packages/tooz/hashring.py", line 71, in add_nodes
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils key =
str(node).encode('utf-8')
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils UnicodeDecodeError:
'ascii' codec can't decode byte 0xde in position 4: ordinal not in
range(128)
2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils

Is this a config issue or bug ? any tips or help is much appreciated :-)


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