Re: [openstack-dev] [Murano] Nominating Kate Chernova for murano-core

2014-12-25 Thread Timur Sufiev
+1 from me.

On Thu, Dec 25, 2014 at 10:28 AM, Serg Melikyan smelik...@mirantis.com
wrote:

 I'd like to propose that we add Kate Chernova to the murano-core.

 Kate is active member of our community for more than a year, she is
 regular participant in our IRC meeting and maintains a good score as
 contributor:

 http://stackalytics.com/report/users/efedorova

 Please vote by replying to this thread. As a reminder of your options, +1
 votes from 5 cores is sufficient; a -1 is a veto.
 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Timur Sufiev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Murano] Nominating Kate Chernova for murano-core

2014-12-25 Thread Ruslan Kamaldinov
Great addition to core team!

+2



On Thu, Dec 25, 2014 at 11:02 AM, Timur Sufiev tsuf...@mirantis.com wrote:
 +1 from me.

 On Thu, Dec 25, 2014 at 10:28 AM, Serg Melikyan smelik...@mirantis.com
 wrote:

 I'd like to propose that we add Kate Chernova to the murano-core.

 Kate is active member of our community for more than a year, she is
 regular participant in our IRC meeting and maintains a good score as
 contributor:

 http://stackalytics.com/report/users/efedorova

 Please vote by replying to this thread. As a reminder of your options, +1
 votes from 5 cores is sufficient; a -1 is a veto.
 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Timur Sufiev

 ___
 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] [cinder] [driver] DB operations

2014-12-25 Thread Amit Das
Thanks Mike for getting me these useful reviews  design discussions.

So as it stands now, I am trying '*provider_id*' to map OpenStack/Cinder
with the driver's backend storage.

I got some useful review comments from @xing-yang to try out '*provider_id'*
feature enabled by below commit:
https://review.openstack.org/#/c/143205/

Do let me know if '*provider_id'* approach seems reasonable ?


Regards,
Amit
*CloudByte Inc.* http://www.cloudbyte.com/

On Thu, Dec 25, 2014 at 1:46 AM, Mike Perez thin...@gmail.com wrote:

 On 06:05 Sat 20 Dec , Duncan Thomas wrote:
  No, I mean that if drivers are going to access database, then they should
  do it via a defined interface that limits what they can do to a sane set
 of
  operations. I'd still prefer that they didn't need extra access beyond
 the
  model update, but I don't know if that is possible.
 
  Duncan Thomas
  On Dec 19, 2014 6:43 PM, Amit Das amit@cloudbyte.com wrote:
 
   Thanks Duncan.
   Do you mean hepler methods in the specific driver class?
   On 19 Dec 2014 14:51, Duncan Thomas duncan.tho...@gmail.com wrote:
  
   So our general advice has historical been 'drivers should not be
   accessing the db directly'. I haven't had chance to look at your
 driver
   code yet, I've been on vacation, but my suggestion is that if you
   absolutely must store something in the admin metadata rather than
 somewhere
   that is covered by the model update (generally provider location and
   provider auth) then writing some helper methods that wrap the context
 bump
   and db call would be better than accessing it directly from the
 driver.
  
   Duncan Thomas
   On Dec 18, 2014 11:41 PM, Amit Das amit@cloudbyte.com wrote:

 I've expressed in past reviews that we should have an interface that limits
 drivers access to the database [1], but received quite a bit of push
 back in Cinder. I recommend we stick to what has been decided, otherwise,
 Amit
 you should spend some time on reading the history of this issue [2] from
 previous meetings and start a rediscussion on it in the next meeting [3].
 Not
 discouraging it, but this has been something brought up at least a couple
 of
 times now and it ends up with the same answer from the community.

 [1] - https://review.openstack.org/#/c/107693/14
 [2] -
 http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-186
 [3] - https://wiki.openstack.org/wiki/CinderMeetings

 --
 Mike Perez

 ___
 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] [Murano] Nominating Kate Chernova for murano-core

2014-12-25 Thread Stan Lagun
+2

Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

sla...@mirantis.com

On Thu, Dec 25, 2014 at 12:42 PM, Ruslan Kamaldinov 
rkamaldi...@mirantis.com wrote:

 Great addition to core team!

 +2



 On Thu, Dec 25, 2014 at 11:02 AM, Timur Sufiev tsuf...@mirantis.com
 wrote:
  +1 from me.
 
  On Thu, Dec 25, 2014 at 10:28 AM, Serg Melikyan smelik...@mirantis.com
  wrote:
 
  I'd like to propose that we add Kate Chernova to the murano-core.
 
  Kate is active member of our community for more than a year, she is
  regular participant in our IRC meeting and maintains a good score as
  contributor:
 
  http://stackalytics.com/report/users/efedorova
 
  Please vote by replying to this thread. As a reminder of your options,
 +1
  votes from 5 cores is sufficient; a -1 is a veto.
  --
  Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
  http://mirantis.com | smelik...@mirantis.com
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  --
  Timur Sufiev
 
  ___
  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] [heat] Remove deprecation properties

2014-12-25 Thread Sergey Kraynev
Hi all.

In the last time we got on review several patches, which removes old
deprecation properties [1],
and one mine [2].

The aim is to delete deprecated code and redundant tests. It looks simple,
but the main problem, which we met, is backward compatibility.
F.e. user has created resource (FIP) with old property schema, i.e. using
SUBNET_ID instead of SUBNET. On first look nothing bad will not happen,
because:
1. handle_delete use resource_id and any changes in property schema does
not affect other actions.
2. If user want to use old template, he will get adequate error message,
that this property is not presented in schema. After that he just should
switch to new property and update stack using this new property.

In the same time we have one big issues for shadow dependencies, which is
actual for neutron resources. The simplest approach will not be worked [3],
due to old properties was deleted from property_schema.

Why is it bad ?
- we will get again all bugs related with such dependencies.
- how to make sure:
- create stack with old property (my template [4])
- open horizon, and look on topology
- download patch [2] and restart engine
- reload horizon page with topology
- as result it will be different

I have some ideas about how to solve this, but none of them is not enough
good for me:
 - getting such information from self.properties.data is bad, because we
will skip all validations mentioned in properties.__getitem__
 - renaming old key in data to new or creating copy with new key is not
correct for me, because in this case we actually change properties
(resource representation) invisibly from user.
 - as possible we may leave old deprecated property and mark it something
like (removed), which will have similar behavior such as for
implemented=False. I do not like it, because it means, that we never remove
this support code, because wants to be compatible with old resources.
(User may be not very lazy to do simple update or something else ...)
- last way, which I have not tried yet, is using _stored_properties_data
for extraction necessary information.

So now I have the questions:
Should we support such case with backward compatibility?
If yes, how will be better to do it for us and user?
May be we should create some strategy for removing  deprecated properties ?

[1]
https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:rm-depr-props,n,z
[2]  https://review.openstack.org/#/c/139990/7
[3]
https://review.openstack.org/#/c/139990/7/heat/engine/resources/neutron/floatingip.py
[4] http://paste.openstack.org/show/154591/

Regards,
Sergey.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Horizon switching to the normal .ini format

2014-12-25 Thread Thomas Goirand
Hi,

There's been talks about Horizon switching to the normal .ini format
that all other projects have been using so far. It would really be
awesome if this could happen. Though I don't see the light at the end of
the tunnel. Quite the opposite way: the settings.py is every day
becoming more complicated.

Is anyone at least working on the .ini switch idea? Or will we continue
to see the Django style settings.py forever? Is there any blockers?

Cheers,

Thomas Goirand (zigo)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Murano] Nominating Kate Chernova for murano-core

2014-12-25 Thread Alexander Tivelkov
+2!
Need moar good cores!
--
Regards,
Alexander Tivelkov


On Thu, Dec 25, 2014 at 12:50 PM, Stan Lagun sla...@mirantis.com wrote:
 +2

 Sincerely yours,
 Stan Lagun
 Principal Software Engineer @ Mirantis


 On Thu, Dec 25, 2014 at 12:42 PM, Ruslan Kamaldinov
 rkamaldi...@mirantis.com wrote:

 Great addition to core team!

 +2



 On Thu, Dec 25, 2014 at 11:02 AM, Timur Sufiev tsuf...@mirantis.com
 wrote:
  +1 from me.
 
  On Thu, Dec 25, 2014 at 10:28 AM, Serg Melikyan smelik...@mirantis.com
  wrote:
 
  I'd like to propose that we add Kate Chernova to the murano-core.
 
  Kate is active member of our community for more than a year, she is
  regular participant in our IRC meeting and maintains a good score as
  contributor:
 
  http://stackalytics.com/report/users/efedorova
 
  Please vote by replying to this thread. As a reminder of your options,
  +1
  votes from 5 cores is sufficient; a -1 is a veto.
  --
  Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
  http://mirantis.com | smelik...@mirantis.com
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
  --
  Timur Sufiev
 
  ___
  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


Re: [openstack-dev] [Mistral] Converging discussions on WF context and WF/task/action inputs

2014-12-25 Thread Nikolay Makhotkin

 One thing that I strongly suggest is that we clearly define all reserved
 keys like “env”, “__actions” etc. I think it’d be better if they all
 started with the same prefix, for example, double underscore.


I absolutely agree here. We should use specific keywords with __ prefix
like we used __executions.

On Thu, Dec 25, 2014 at 8:51 AM, Renat Akhmerov rakhme...@mirantis.com
wrote:


 On 24 Dec 2014, at 23:37, W Chan m4d.co...@gmail.com wrote:

 * 2) Retuning to first example:
 ** ...
 **  action: std.sql conn_str={$.env.conn_str} query={$.query}
 ** ...
 ** $.env - is it a name of environment or it will be a registered syntax to 
 getting access to values from env ?
 *

 I was actually thinking the environment will use the reserved word env in 
 the WF context.  The value for the env key will be the dict supplied either 
 DB lookup by name, by dict, or by JSON from CLI.

 Ok, probably here’s the place where I didn’t understand you before. I
 thought “env” here is just a arbitrary key that users themselves may want
 to have to just group some variables under a single umbrella. What you’re
 saying is that whatever is under “$.env” is just the exact same environment
 that we passed when we started the workflow? If yes then it definitely
 makes sense to me (it just allows to explicitly access environment, not
 through the implicit variable lookup). Please confirm.

 One thing that I strongly suggest is that we clearly define all reserved
 keys like “env”, “__actions” etc. I think it’d be better if they all
 started with the same prefix, for example, double underscore.

 The nested dict for __actions (and all other keys with double underscore) 
 is special system purpose, in this case declaring defaults for action inputs. 
  Similar to __execution where it's for containing runtime data for the WF 
 execution.

 Yes, that’s clear


 Renat Akhmerov
 @ Mirantis Inc.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best Regards,
Nikolay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Murano] Nominating Kate Chernova for murano-core

2014-12-25 Thread Dmitry Teselkin
+2 :)

On Thu, Dec 25, 2014 at 1:25 PM, Alexander Tivelkov ativel...@mirantis.com
wrote:

 +2!
 Need moar good cores!
 --
 Regards,
 Alexander Tivelkov


 On Thu, Dec 25, 2014 at 12:50 PM, Stan Lagun sla...@mirantis.com wrote:
  +2
 
  Sincerely yours,
  Stan Lagun
  Principal Software Engineer @ Mirantis
 
 
  On Thu, Dec 25, 2014 at 12:42 PM, Ruslan Kamaldinov
  rkamaldi...@mirantis.com wrote:
 
  Great addition to core team!
 
  +2
 
 
 
  On Thu, Dec 25, 2014 at 11:02 AM, Timur Sufiev tsuf...@mirantis.com
  wrote:
   +1 from me.
  
   On Thu, Dec 25, 2014 at 10:28 AM, Serg Melikyan 
 smelik...@mirantis.com
   wrote:
  
   I'd like to propose that we add Kate Chernova to the murano-core.
  
   Kate is active member of our community for more than a year, she is
   regular participant in our IRC meeting and maintains a good score as
   contributor:
  
   http://stackalytics.com/report/users/efedorova
  
   Please vote by replying to this thread. As a reminder of your
 options,
   +1
   votes from 5 cores is sufficient; a -1 is a veto.
   --
   Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
   http://mirantis.com | smelik...@mirantis.com
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
  
   --
   Timur Sufiev
  
   ___
   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




-- 
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Murano] Nominating Kate Chernova for murano-core

2014-12-25 Thread Serg Melikyan
Kate, welcome to murano-core!

Congratulations!

On Thu, Dec 25, 2014 at 3:52 PM, Dmitry Teselkin dtesel...@mirantis.com
wrote:

 +2 :)

 On Thu, Dec 25, 2014 at 1:25 PM, Alexander Tivelkov 
 ativel...@mirantis.com wrote:

 +2!
 Need moar good cores!
 --
 Regards,
 Alexander Tivelkov


 On Thu, Dec 25, 2014 at 12:50 PM, Stan Lagun sla...@mirantis.com wrote:
  +2
 
  Sincerely yours,
  Stan Lagun
  Principal Software Engineer @ Mirantis
 
 
  On Thu, Dec 25, 2014 at 12:42 PM, Ruslan Kamaldinov
  rkamaldi...@mirantis.com wrote:
 
  Great addition to core team!
 
  +2
 
 
 
  On Thu, Dec 25, 2014 at 11:02 AM, Timur Sufiev tsuf...@mirantis.com
  wrote:
   +1 from me.
  
   On Thu, Dec 25, 2014 at 10:28 AM, Serg Melikyan 
 smelik...@mirantis.com
   wrote:
  
   I'd like to propose that we add Kate Chernova to the murano-core.
  
   Kate is active member of our community for more than a year, she is
   regular participant in our IRC meeting and maintains a good score as
   contributor:
  
   http://stackalytics.com/report/users/efedorova
  
   Please vote by replying to this thread. As a reminder of your
 options,
   +1
   votes from 5 cores is sufficient; a -1 is a veto.
   --
   Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
   http://mirantis.com | smelik...@mirantis.com
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
  
   --
   Timur Sufiev
  
   ___
   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




 --
 Thanks,
 Dmitry Teselkin
 Deployment Engineer
 Mirantis
 http://www.mirantis.com

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat][oslo-incubator][oslo-log] Logging Unicode characters

2014-12-25 Thread Qiming Teng
On Wed, Dec 24, 2014 at 10:50:48AM -0600, Ben Nemec wrote:
 On 12/24/2014 03:48 AM, Qiming Teng wrote:
  Hi,
  
  When trying to enable stack names in Heat to use unicode strings, I am
  stuck by a weird behavior of logging.
  
  Suppose I have a stack name assigned some non-ASCII string, then when
  stack tries to log something here:
  
  heat/engine/stack.py:
  
   536 LOG.info(_LI('Stack %(action)s %(status)s (%(name)s): '
   537  '%(reason)s'),
   538  {'action': action,
   539   'status': status,
   540   'name': self.name,   # type(self.name)==unicode here
   541   'reason': reason})
  
  I'm seeing the following errors from h-eng session:
  
  Traceback (most recent call last):
File /usr/lib64/python2.6/logging/__init__.py, line 799, in emit
  stream.write(fs % msg.decode('utf-8'))
File /usr/lib64/python2.6/encodings/utf_8.py, line 16, in decode
  return codecs.utf_8_decode(input, errors, True)
  UnicodeEncodeError: 'ascii' codec can't encode characters in position 
  114-115: 
   ordinal not in range(128)
  
  This means logging cannot handle Unicode correctly?  No.  I did the
  following experiments:
  
  $ cat logtest
  
  #!/usr/bin/env python
  
  import sys
  
  from oslo.utils import encodeutils
  from oslo import i18n
  
  from heat.common.i18n import _LI
  from heat.openstack.common import log as logging
  
  i18n.enable_lazy()
  
  LOG = logging.getLogger('logtest')
  logging.setup('heat')
  
  print('sys.stdin.encoding: %s' % sys.stdin.encoding)
  print('sys.getdefaultencoding: %s' % sys.getdefaultencoding())
  
  s = sys.argv[1]
  print('s is: %s' % type(s))
  
  stack_name = encodeutils.safe_decode(unis)
 
 I think you may have a typo in your sample here because unis isn't
 defined as far as I can tell.

You are right, it was a typo.  It should be s here.

 In any case, I suspect this line is why your example works and Heat
 doesn't.  I can reproduce the same error if I stuff some unicode data
 into a unicode string without decoding it first:
 
  test = u'\xe2\x82\xac'
  test.decode('utf8')
 Traceback (most recent call last):
   File stdin, line 1, in module
   File /usr/lib64/python2.7/encodings/utf_8.py, line 16, in decode
 return codecs.utf_8_decode(input, errors, True)
 UnicodeEncodeError: 'ascii' codec can't encode characters in position
 0-2: ordinal not in range(128)
The above didn't work because test is already declared to be Unicode,
decoding it won't work

  test = '\xe2\x82\xac'
  test.decode('utf8')
 u'\u20ac'

This one works because test is 'str' type.

 Whether that's what is going on here I can't say for sure though.
 Trying to figure out unicode in Python usually gives me a headache. :-)

Right.  Not just unicode conversion, in Heat's case, it also involves
quoting.  The test above needs to be quoted when being part of an URI.
That is further more complicating the whole process.

  print('stack_name is: %s' % type(stack_name))
  
  # stack_name is unicode here
  LOG.error(_LI('stack name: %(name)s') % {'name': stack_name})
  
  $ ./logtest some Chinese here
  
  [tengqm@node1 heat]$ ./logtest 中文
  sys.stdin.encoding: UTF-8
  sys.getdefaultencoding: ascii
  s is: type 'str'
  stack_name is: type 'unicode'
  2014-12-24 17:51:13.799 29194 ERROR logtest [-] stack name: 中文
  
  It worked.  
  
  After spending more than one day on this, I'm seeking help from people
  here.  What's wrong with Unicode stack names here?
  
  Any hints are appreciated.
  
  Regards,
- Qiming
  


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat][devstack] Logging Unicode characters

2014-12-25 Thread Qiming Teng
After some tweaking to screen sessions, finally I can see Unicode
strings logged and shown in screen environment.  It is not a problem of
oslo.log or log module from oslo-incubator.  Sorry for the false alarm.

Maybe devstack should start screen sessions with Unicode support by
default?

Regards,
  - Qiming

On Wed, Dec 24, 2014 at 08:58:13PM +0800, Qiming Teng wrote:
 Seems that the reason is in devstack 'screen' is not started with
 Unicode support.  Still checking ...
 
 Regards,
   Qiming
 
 On Wed, Dec 24, 2014 at 05:48:56PM +0800, Qiming Teng wrote:
  Hi,
  
  When trying to enable stack names in Heat to use unicode strings, I am
  stuck by a weird behavior of logging.
  
  Suppose I have a stack name assigned some non-ASCII string, then when
  stack tries to log something here:
  
  heat/engine/stack.py:
  
   536 LOG.info(_LI('Stack %(action)s %(status)s (%(name)s): '
   537  '%(reason)s'),
   538  {'action': action,
   539   'status': status,
   540   'name': self.name,   # type(self.name)==unicode here
   541   'reason': reason})
  
  I'm seeing the following errors from h-eng session:
  
  Traceback (most recent call last):
File /usr/lib64/python2.6/logging/__init__.py, line 799, in emit
  stream.write(fs % msg.decode('utf-8'))
File /usr/lib64/python2.6/encodings/utf_8.py, line 16, in decode
  return codecs.utf_8_decode(input, errors, True)
  UnicodeEncodeError: 'ascii' codec can't encode characters in position 
  114-115: 
   ordinal not in range(128)
  
  This means logging cannot handle Unicode correctly?  No.  I did the
  following experiments:
  
  $ cat logtest
  
  #!/usr/bin/env python
  
  import sys
  
  from oslo.utils import encodeutils
  from oslo import i18n
  
  from heat.common.i18n import _LI
  from heat.openstack.common import log as logging
  
  i18n.enable_lazy()
  
  LOG = logging.getLogger('logtest')
  logging.setup('heat')
  
  print('sys.stdin.encoding: %s' % sys.stdin.encoding)
  print('sys.getdefaultencoding: %s' % sys.getdefaultencoding())
  
  s = sys.argv[1]
  print('s is: %s' % type(s))
  
  stack_name = encodeutils.safe_decode(unis)
  print('stack_name is: %s' % type(stack_name))
  
  # stack_name is unicode here
  LOG.error(_LI('stack name: %(name)s') % {'name': stack_name})
  
  $ ./logtest some Chinese here
  
  [tengqm@node1 heat]$ ./logtest 中文
  sys.stdin.encoding: UTF-8
  sys.getdefaultencoding: ascii
  s is: type 'str'
  stack_name is: type 'unicode'
  2014-12-24 17:51:13.799 29194 ERROR logtest [-] stack name: 中文
  
  It worked.  
  
  After spending more than one day on this, I'm seeking help from people
  here.  What's wrong with Unicode stack names here?
  
  Any hints are appreciated.
  
  Regards,
- Qiming
  
  
  ___
  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


Re: [openstack-dev] [Heat][devstack] Logging Unicode characters

2014-12-25 Thread Jeremy Stanley
On 2014-12-25 21:57:30 +0800 (+0800), Qiming Teng wrote:
[...]
 Maybe devstack should start screen sessions with Unicode support by
 default?

The easiest way to have that discussion is to add -U to the screen
calls in the screen_rc function definition in openstack-dev/devstack
functions-common and see what the CI jobs and DevStack reviewers
have to say about that change when you submit it to Gerrit.

Or else consider filing a bug at
https://bugs.launchpad.net/devstack/+filebug and hope some other
contributor has time to follow through with it.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Fuel][Docs] Move fuel-web/docs to fuel-docs

2014-12-25 Thread Aleksandra Fedorova
There are different types of dependencies:

docs dependencies like sphinx, plantuml and so on are rarely changed
so we can create environment on a slave during slave deployment phase
and keep it there. But nailgun dependencies for example can be changed
at any time, thus we need to update the environment every time we
checkout fuel-web/ repository. Therefore workflow for building just
docs from rst-files is different from the one where you need to update
everything before you start.

Also autodocs should be updated and tested on changes into fuel-web
code, while changes to fuel-docs don't usually touch them.

Thus I think that autodocs belong to the repository they are generated
from and I'd like to keep them there. That's why I moved objects.rst
and api_doc.rst into nailgun/docs in [1]

One more thing is that fuel-web is not the only repository which
produces autodocs. There are autodocs from fuel-main/fuelweb_test repo
and autodocs from fuel-devops/docs. And I'd like to have the same
general workflow for all of them.


So my idea is that we should keep:

1) repository fuel-docs with all texts and diagrams, including Fuel
Developer Guide,
2) repository fuel-web/nailgun/docs with nailgun reference,
3) repository fuel-main/fuelweb_test/docs with autogenerated system
tests reference,
4) repository fuel-devops/docs with autogenerated fuel-devops reference,
5) repository fuel-specs with specifications.

On CI we will build autodocs for every commit into fuel-web, fuel-main
and fuel-devops. And we will build docs on every commit for fuel-docs
without additional repositories involved.

And finally we will have CI job to publish final documentation in one
place. And this job will build and publish every part into separate
subfolder, so we'll get final docs in one place but built
independently.


https://review.openstack.org/#/c/143679/1/nailgun/docs/api_doc.rst,cm

-- 
Aleksandra Fedorova
Fuel DevOps Engineer
bookwar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Horizon switching to the normal .ini format

2014-12-25 Thread Timur Sufiev
Thomas,

I could only point you to the Radomir's patch
https://review.openstack.org/#/c/100521/

It's still a work in progress, so you may ask him for more details.

On Thu, Dec 25, 2014 at 1:59 AM, Thomas Goirand z...@debian.org wrote:

 Hi,

 There's been talks about Horizon switching to the normal .ini format
 that all other projects have been using so far. It would really be
 awesome if this could happen. Though I don't see the light at the end of
 the tunnel. Quite the opposite way: the settings.py is every day
 becoming more complicated.

 Is anyone at least working on the .ini switch idea? Or will we continue
 to see the Django style settings.py forever? Is there any blockers?

 Cheers,

 Thomas Goirand (zigo)

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Timur Sufiev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Hierarchical Multitenancy

2014-12-25 Thread Raildo Mascena
Hi Deepak,

I think that one of the next steps for HMT is expand the concept for other
services, as Nova folks are doing with Quotas for nested projects. I think
that we can do a brainstorm about the use cases for HMT in each service,
but I think that if a resource can be shared inside the hierarchy, so this
is a good evidence that we can implement HMT in the service, like a
instance or a image and other things.

I'm available for any discussion related to HMT in other services. :)


On Wed Dec 24 2014 at 1:04:15 PM Deepak Shetty dpkshe...@gmail.com wrote:

 Raildo,
Thanks for putting the blog, i really liked it as it helps to
 understand how hmt works. I am interested to know more about how hmt can be
 exploited for other OpenStack projects... Esp cinder, manila
 On Dec 23, 2014 5:55 AM, Morgan Fainberg morgan.fainb...@gmail.com
 wrote:

 Hi Raildo,

 Thanks for putting this post together. I really appreciate all the work
 you guys have done (and continue to do) to get the Hierarchical
 Mulittenancy code into Keystone. It’s great to have the base implementation
 merged into Keystone for the K1 milestone. I look forward to seeing the
 rest of the development land during the rest of this cycle and what the
 other OpenStack projects build around the HMT functionality.

 Cheers,
 Morgan



 On Dec 22, 2014, at 1:49 PM, Raildo Mascena rail...@gmail.com wrote:

 Hello folks, My team and I developed the Hierarchical Multitenancy
 concept for Keystone in Kilo-1 but What is Hierarchical Multitenancy? What
 have we implemented? What are the next steps for kilo?
 To answers these questions, I created a blog post 
 *http://raildo.me/hierarchical-multitenancy-in-openstack/
 http://raildo.me/hierarchical-multitenancy-in-openstack/*

 Any question, I'm available.

 --
 Raildo Mascena
 Software Engineer.
 Bachelor of Computer Science.
 Distributed Systems Laboratory
 Federal University of Campina Grande
 Campina Grande, PB - Brazil

 ___
 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


Re: [openstack-dev] [Fuel][Docs] Move fuel-web/docs to fuel-docs

2014-12-25 Thread Christopher Aedo
Ah I got it, I hadn't really considered how much more likely the
requirements are to change for nailgun and the other components that
should have auto-generated API docs.  Having those build completely
separately matches OpenStack proper too - I'm on board now :)  We can
work out the details over the next few weeks, should be able to wrap
it up no latter than mid January.

I'll get to work next week on updating the blueprint to reflect this approach.

-Christopher

On Thu, Dec 25, 2014 at 6:31 AM, Aleksandra Fedorova
afedor...@mirantis.com wrote:
 There are different types of dependencies:

 docs dependencies like sphinx, plantuml and so on are rarely changed
 so we can create environment on a slave during slave deployment phase
 and keep it there. But nailgun dependencies for example can be changed
 at any time, thus we need to update the environment every time we
 checkout fuel-web/ repository. Therefore workflow for building just
 docs from rst-files is different from the one where you need to update
 everything before you start.

 Also autodocs should be updated and tested on changes into fuel-web
 code, while changes to fuel-docs don't usually touch them.

 Thus I think that autodocs belong to the repository they are generated
 from and I'd like to keep them there. That's why I moved objects.rst
 and api_doc.rst into nailgun/docs in [1]

 One more thing is that fuel-web is not the only repository which
 produces autodocs. There are autodocs from fuel-main/fuelweb_test repo
 and autodocs from fuel-devops/docs. And I'd like to have the same
 general workflow for all of them.


 So my idea is that we should keep:

 1) repository fuel-docs with all texts and diagrams, including Fuel
 Developer Guide,
 2) repository fuel-web/nailgun/docs with nailgun reference,
 3) repository fuel-main/fuelweb_test/docs with autogenerated system
 tests reference,
 4) repository fuel-devops/docs with autogenerated fuel-devops reference,
 5) repository fuel-specs with specifications.

 On CI we will build autodocs for every commit into fuel-web, fuel-main
 and fuel-devops. And we will build docs on every commit for fuel-docs
 without additional repositories involved.

 And finally we will have CI job to publish final documentation in one
 place. And this job will build and publish every part into separate
 subfolder, so we'll get final docs in one place but built
 independently.


 https://review.openstack.org/#/c/143679/1/nailgun/docs/api_doc.rst,cm

 --
 Aleksandra Fedorova
 Fuel DevOps Engineer
 bookwar

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails

2014-12-25 Thread ZhiQiang Fan
check-tripleo-ironic-xxx failed because:

rm -rf /home/jenkins/.cache/image-create/pypi/mirror/
rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/':
Permission denie

see
http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html

search on logstash.openstack.org:
message:rm: cannot remove
`/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied
there are 59 hits in last 48 hours
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Need help in validating CPU Pinning feature

2014-12-25 Thread Srinivasa Rao Ragolu
Hi All,

I have been working on CPU Pinning feature validation.

I could able set vcpu_pin_set config in nova.conf and could able to see
cpupin set in guest xml and working fine while launching.

Please let me know how can I set cputune: vcpupin in guest xml?

Or

Any documents refer to validate cpu pinning use cases.

Thanks,
Srinivas.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Ironic] Ironic pxe_ucs driver BP review approval

2014-12-25 Thread GopiKrishna Saripuri
Hi Ironic-core team,

I've submitted new BP for pxe_ucs driver, supporting Cisco UCS B/C/M-series
hardware. Could you take a look at the review and provide your comments and
approvals. I will submit the code for review once the BP is approved.

Review link: https://review.openstack.org/#/c/139517
https://blueprints.launchpad.net/ironic/+spec/cisco-ucs-pxe-driver

Regards
GopiKrishna S
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails

2014-12-25 Thread James Polley
Thanks for the alert

The earliest failure I can see because of this is
http://logs.openstack.org/43/141043/6/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/36c9771/

I've raised https://bugs.launchpad.net/tripleo/+bug/1405732 and I've put
some preliminary notes on
https://etherpad.openstack.org/p/tripleo-ci-breakages

On Fri, Dec 26, 2014 at 3:42 AM, ZhiQiang Fan aji.zq...@gmail.com wrote:

 check-tripleo-ironic-xxx failed because:

 rm -rf /home/jenkins/.cache/image-create/pypi/mirror/
 rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/':
 Permission denie

 see

 http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html

 search on logstash.openstack.org:
 message:rm: cannot remove
 `/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied
 there are 59 hits in last 48 hours



 ___
 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