date:20151009


On 10/08/2015 11:47 PM, Jim Rollenhagen wrote:

Hi all,

I've been thinking a lot about Ironic's core reviewer team and how we might
make it better.

I'd like to grow the team more through trust and mentoring. We should be
able to promote someone to core based on a good knowledge of *some* of
the code base, and trust them not to +2 things they don't know about. I'd
also like to build a culture of mentoring non-cores on how to review, in
preparation for adding them to the team. Through these pieces, I'm hoping
we can have a few rounds of core additions this cycle.

With that said...

I'd like to nominate Vladyslav Drok (vdrok) for the core team. His reviews
have been super high quality, and the quantity is ever-increasing. He's
also started helping out with some smaller efforts (full tempest, for
example), and I'd love to see that continue with larger efforts.


+2



I'd also like to nominate John Villalovos (jlvillal). John has been
reviewing a ton of code and making a real effort to learn everything,
and keep track of everything going on in the project.


+2



Ironic cores, please reply with your vote; provided feedback is positive,
I'd like to make this official next week sometime. Thanks!

// jim


__
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] [Fuel] Plugins related functionality in Fuel Client

2015-10-09 Thread Evgeniy L

Hi,

+1, but I think it's better to spawn separate service, instead of adding it
to Nailgun.

Thanks,

On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko  wrote:

> Folks,
>
> it’s time to speak about Fuel Plugins and the way they are managed.
>
> Currently we have some methods in Fuel Client that allow to install,
> remove and do some other things to plugins. Everything looks great except
> that functionality requires Fuel Client to be installed on a master node
> and be running under a root user. It’s time for us to grow up and realize
> that nothing can require Fuel Client to be installed on a specific computer
> and of course we cannot require root permissions for any actions.
>
> I’d like to move all that code to Nailgun, utilizing mules and hide it
> behind Nailgun’s API as soon as possible. For that I filed a bug [1] and
> I’d like to ask Fuel Enhancements subgroup of developers to take a close
> look at it.
>
>
> 1. https://bugs.launchpad.net/fuel/+bug/1504338
>
>
> - romcheg
>
>
> __
> 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] [Fuel] Plugins related functionality in Fuel Client

2015-10-09 Thread Roman Prykhodchenko

I’d say even if it will be a separate service it’s better to proxy requests 
through Nailgun’s API to have a single entry point.

> 9 жовт. 2015 р. о 10:23 Evgeniy L  написав(ла):
> 
> Hi,
> 
> +1, but I think it's better to spawn separate service, instead of adding it 
> to Nailgun.
> 
> Thanks,
> 
> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko  > wrote:
> Folks,
> 
> it’s time to speak about Fuel Plugins and the way they are managed.
> 
> Currently we have some methods in Fuel Client that allow to install, remove 
> and do some other things to plugins. Everything looks great except that 
> functionality requires Fuel Client to be installed on a master node and be 
> running under a root user. It’s time for us to grow up and realize that 
> nothing can require Fuel Client to be installed on a specific computer and of 
> course we cannot require root permissions for any actions.
> 
> I’d like to move all that code to Nailgun, utilizing mules and hide it behind 
> Nailgun’s API as soon as possible. For that I filed a bug [1] and I’d like to 
> ask Fuel Enhancements subgroup of developers to take a close look at it.
> 
> 
> 1. https://bugs.launchpad.net/fuel/+bug/1504338 
> 
> 
> 
> - romcheg
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [Fuel] Plugins related functionality in Fuel Client

2015-10-09 Thread Sergii Golovatiuk

+1 to Roman.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Fri, Oct 9, 2015 at 10:45 AM, Roman Prykhodchenko  wrote:

> I’d say even if it will be a separate service it’s better to proxy
> requests through Nailgun’s API to have a single entry point.
>
> 9 жовт. 2015 р. о 10:23 Evgeniy L  написав(ла):
>
> Hi,
>
> +1, but I think it's better to spawn separate service, instead of adding
> it to Nailgun.
>
> Thanks,
>
> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko  wrote:
>
>> Folks,
>>
>> it’s time to speak about Fuel Plugins and the way they are managed.
>>
>> Currently we have some methods in Fuel Client that allow to install,
>> remove and do some other things to plugins. Everything looks great except
>> that functionality requires Fuel Client to be installed on a master node
>> and be running under a root user. It’s time for us to grow up and realize
>> that nothing can require Fuel Client to be installed on a specific computer
>> and of course we cannot require root permissions for any actions.
>>
>> I’d like to move all that code to Nailgun, utilizing mules and hide it
>> behind Nailgun’s API as soon as possible. For that I filed a bug [1] and
>> I’d like to ask Fuel Enhancements subgroup of developers to take a close
>> look at it.
>>
>>
>> 1. https://bugs.launchpad.net/fuel/+bug/1504338
>>
>>
>> - romcheg
>>
>>
>> __
>> 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

Re: [openstack-dev] [Fuel] Plugins related functionality in Fuel Client

2015-10-09 Thread Andriy Popovych

Actually it's an old issue 
https://blueprints.launchpad.net/fuel/+spec/plugin-manager-as-separate-service


On 10/09/2015 11:53 AM, Sergii Golovatiuk wrote:

+1 to Roman.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Fri, Oct 9, 2015 at 10:45 AM, Roman Prykhodchenko mailto:m...@romcheg.me>> wrote:

I’d say even if it will be a separate service it’s better to proxy
requests through Nailgun’s API to have a single entry point.


9 жовт. 2015 р. о 10:23 Evgeniy L mailto:e...@mirantis.com>> написав(ла):

Hi,

+1, but I think it's better to spawn separate service, instead of
adding it to Nailgun.

Thanks,

On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko mailto:m...@romcheg.me>> wrote:

Folks,

it’s time to speak about Fuel Plugins and the way they are
managed.

Currently we have some methods in Fuel Client that allow to
install, remove and do some other things to plugins.
Everything looks great except that functionality requires Fuel
Client to be installed on a master node and be running under a
root user. It’s time for us to grow up and realize that
nothing can require Fuel Client to be installed on a specific
computer and of course we cannot require root permissions for
any actions.

I’d like to move all that code to Nailgun, utilizing mules and
hide it behind Nailgun’s API as soon as possible. For that I
filed a bug [1] and I’d like to ask Fuel Enhancements subgroup
of developers to take a close look at it.


1. https://bugs.launchpad.net/fuel/+bug/1504338


- romcheg



__
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



__
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] [Fuel] Plugins related functionality in Fuel Client

2015-10-09 Thread Evgeniy L

>> I’d say even if it will be a separate service it’s better to proxy
requests through Nailgun’s API to have a single entry point.

I don't think that application such as Nailgun should be responsible
for proxying
requests, we solved similar problem for OSTF with adding proxy rule in
Nginx.

Thanks,

On Fri, Oct 9, 2015 at 11:45 AM, Roman Prykhodchenko  wrote:

> I’d say even if it will be a separate service it’s better to proxy
> requests through Nailgun’s API to have a single entry point.
>
> 9 жовт. 2015 р. о 10:23 Evgeniy L  написав(ла):
>
> Hi,
>
> +1, but I think it's better to spawn separate service, instead of adding
> it to Nailgun.
>
> Thanks,
>
> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko  wrote:
>
>> Folks,
>>
>> it’s time to speak about Fuel Plugins and the way they are managed.
>>
>> Currently we have some methods in Fuel Client that allow to install,
>> remove and do some other things to plugins. Everything looks great except
>> that functionality requires Fuel Client to be installed on a master node
>> and be running under a root user. It’s time for us to grow up and realize
>> that nothing can require Fuel Client to be installed on a specific computer
>> and of course we cannot require root permissions for any actions.
>>
>> I’d like to move all that code to Nailgun, utilizing mules and hide it
>> behind Nailgun’s API as soon as possible. For that I filed a bug [1] and
>> I’d like to ask Fuel Enhancements subgroup of developers to take a close
>> look at it.
>>
>>
>> 1. https://bugs.launchpad.net/fuel/+bug/1504338
>>
>>
>> - romcheg
>>
>>
>> __
>> 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

Re: [openstack-dev] [Fuel] Plugins related functionality in Fuel Client

2015-10-09 Thread Vitaly Kramskikh

+1, that would allow to install plugins from Fuel UI

2015-10-09 15:53 GMT+07:00 Sergii Golovatiuk :

> +1 to Roman.
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Fri, Oct 9, 2015 at 10:45 AM, Roman Prykhodchenko 
> wrote:
>
>> I’d say even if it will be a separate service it’s better to proxy
>> requests through Nailgun’s API to have a single entry point.
>>
>> 9 жовт. 2015 р. о 10:23 Evgeniy L  написав(ла):
>>
>> Hi,
>>
>> +1, but I think it's better to spawn separate service, instead of adding
>> it to Nailgun.
>>
>> Thanks,
>>
>> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko 
>> wrote:
>>
>>> Folks,
>>>
>>> it’s time to speak about Fuel Plugins and the way they are managed.
>>>
>>> Currently we have some methods in Fuel Client that allow to install,
>>> remove and do some other things to plugins. Everything looks great except
>>> that functionality requires Fuel Client to be installed on a master node
>>> and be running under a root user. It’s time for us to grow up and realize
>>> that nothing can require Fuel Client to be installed on a specific computer
>>> and of course we cannot require root permissions for any actions.
>>>
>>> I’d like to move all that code to Nailgun, utilizing mules and hide it
>>> behind Nailgun’s API as soon as possible. For that I filed a bug [1] and
>>> I’d like to ask Fuel Enhancements subgroup of developers to take a close
>>> look at it.
>>>
>>>
>>> 1. https://bugs.launchpad.net/fuel/+bug/1504338
>>>
>>>
>>> - romcheg
>>>
>>>
>>>
>>> __
>>> 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
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
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] [CI] Try to introduce RFC mechanism to CI.

2015-10-09 Thread Tang Chen


Hi,

CI systems will run tests for each patch once it is submitted or modified.
But most CI systems occupy a lot of resource, and take a long time to
run tests (1 or 2 hours for one patch).

I think, not all the patches submitted need to be tested. Even those 
patches

with an approved BP and spec may be reworked for 20+ versions. So I think
CI should support a RFC (Require For Comments) mechanism for developers
to submit and review the code detail and rework. When the patches are
fully ready, I mean all reviewers have agreed on the implementation detail,
then CI will test the patches. For a 20+ version patch-set, maybe 3 or 4 
rounds

of tests are enough. Just test the last 3 or 4 versions.

This can significantly reduce CI overload.

This workflow appears in many other OSS communities, such as Linux kernel,
qemu and libvirt. Testers won't test patches with a [RFC] tag in the 
commit message.

So I want to enable CI to support a similar mechanism.

I'm not sure if it is a good idea. Please help to review the following BP.

https://blueprints.launchpad.net/openstack-ci/+spec/ci-rfc-mechanism

Thanks.

__
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] [swift] Plan to port Swift to Python 3

2015-10-09 Thread Thierry Carrez

Victor Stinner wrote:
> Good news, we made good progress last weeks on porting Swift to Python
> 3, a few changes were merged and all dependencies now work on Python 3.
> We only need two more simple changes to have a working pyhon34 check job:
> 
> * "py3: Update pbr and dnspython requirements"
>   https://review.openstack.org/#/c/217423/
> * "py3: Add py34 test environment to tox"
>   https://review.openstack.org/#/c/199034/
> 
> With these changes, it will be possible to make the python34 check job
> voting to avoid Python 3 regressions. It's very important to avoid
> regressions, so we cannot go backward again in Python 3 support.
> 
> On IRC, it was said that it's better to merge Python 3 changes at the
> beginning of the Mitaka cycle, because Python 3 requires a lot of small
> changes which can likely introduce (subtle) bugs, and it's better to
> catch them early during the development cycle.
> 
> John Dickinson prefers incremental and small changes, whereas clayg
> looks to like giant patches to fix all Python 3 issues at once to avoid
> conflicts in other (non-Python3) changes. (Sorry, if I didn't summarized
> correctly the discussion we had yesterday.)
> 
> The problem is that it's hard to fix "all" Python 3 issues in a single
> patch, the patch would be super giant and just impossible to review.
> It's also annoying to have to write dozens of small patches: we loose
> time on merge conflicts, rebasing, random gate failures, etc.
> 
> I proposed a first patch serie of 6 changes to fix a lot of simple
> Python 3 issues "at once":
> [...]
> 
> The overall diff is impressive: "61 files changed, 233 insertions(+),
> 189 deletions(-)" ... but each change is quite simple. It's only one
> pattern replaced with a different pattern. For example, replace
> "unicode" with "six.text_type" (and add "import six" if needed). So
> these changes should be easy to review.
> 
> With a working (and voting?) python34 check job and these 6 changes, it
> will be (much) easier to work on porting Swift to Python 3. Following
> patches will be validated by the python34 check job, shorter and
> restricted to a few files.
> 
> Victor

That's great news. Thanks so much for your tireless efforts to get
Python 3 supported everywhere in OpenStack, Victor !

-- 
Thierry Carrez (ttx)

__
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] [Murano] py26 support in python-muranoclient

2015-10-09 Thread Serg Melikyan

Hi Vahid,

unfortunately we don't plan to remove support for py26 from the
python-muranoclient, most of the python-client support py26
in order to work out of the box on different OS including CentOS 6.5
and so on.

>So the options are:
>1. support py26 in tosca-parser

Support for py26 is pretty easy to implement, there are only few
things which are not available in py26 and available in py27. In our
case it was few places where we used {1, 2, 3} instead of set([1, 2,
3]).

On Thu, Oct 8, 2015 at 11:59 PM, Vahid S Hashemian
 wrote:
> Hello,
>
> I am wondering if there is any near-term plan for removing the py26 support
> from the client project (python-muranoclient).
> For the tosca support blueprint python-muranoclient will become dependent on
> tosca-parser project and expect tosca-parser to support py26 (it currently
> does not support py26).
>
> So the options are:
> 1. support py26 in tosca-parser
> 2. wait until py26 support is phased out in python-muranoclient (only if
> it's happening soon)
>
> Thanks.
> -
> Vahid Hashemian, Ph.D.
> Advisory Software Engineer, IBM Cloud
>
>
>
>
> __
> 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
>



-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836

__
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] [Fuel] Plugins related functionality in Fuel Client

2015-10-09 Thread Roman Prykhodchenko

In that case I would suggest to also use Keystone service directory for 
discovering services.

> 9 жовт. 2015 р. о 11:00 Evgeniy L  написав(ла):
> 
> >> I’d say even if it will be a separate service it’s better to proxy 
> >> requests through Nailgun’s API to have a single entry point.
> 
> I don't think that application such as Nailgun should be responsible for 
> proxying
> requests, we solved similar problem for OSTF with adding proxy rule in Nginx.
> 
> Thanks,
> 
> On Fri, Oct 9, 2015 at 11:45 AM, Roman Prykhodchenko  > wrote:
> I’d say even if it will be a separate service it’s better to proxy requests 
> through Nailgun’s API to have a single entry point.
> 
>> 9 жовт. 2015 р. о 10:23 Evgeniy L > > написав(ла):
>> 
>> Hi,
>> 
>> +1, but I think it's better to spawn separate service, instead of adding it 
>> to Nailgun.
>> 
>> Thanks,
>> 
>> On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko > > wrote:
>> Folks,
>> 
>> it’s time to speak about Fuel Plugins and the way they are managed.
>> 
>> Currently we have some methods in Fuel Client that allow to install, remove 
>> and do some other things to plugins. Everything looks great except that 
>> functionality requires Fuel Client to be installed on a master node and be 
>> running under a root user. It’s time for us to grow up and realize that 
>> nothing can require Fuel Client to be installed on a specific computer and 
>> of course we cannot require root permissions for any actions.
>> 
>> I’d like to move all that code to Nailgun, utilizing mules and hide it 
>> behind Nailgun’s API as soon as possible. For that I filed a bug [1] and I’d 
>> like to ask Fuel Enhancements subgroup of developers to take a close look at 
>> it.
>> 
>> 
>> 1. https://bugs.launchpad.net/fuel/+bug/1504338 
>> 
>> 
>> 
>> - romcheg
>> 
>> 
>> __
>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [all] Recording little everyday OpenStack successes

2015-10-09 Thread Thierry Carrez

Hello everyone,

OpenStack has become quite big, and it's easier than ever to feel lost,
to feel like nothing is really happening. It's more difficult than ever
to feel part of a single community, and to celebrate little successes
and progress.

In a (small) effort to help with that, I suggested making it easier to
record little moments of joy and small success bits. Those are usually
not worth the effort of a blog post or a new mailing-list thread, but
they show that our community makes progress *every day*.

So whenever you feel like you made progress, or had a little success in
your OpenStack adventures, or have some joyful moment to share, just
throw the following message on your local IRC channel:

#success [Your message here]

The openstackstatus bot will take that and record it on this wiki page:

https://wiki.openstack.org/wiki/Successes

We'll add a few of those every week to the weekly newsletter (as part of
the developer digest that we reecently added there).

Caveats: Obviously that only works on channels where openstackstatus is
present (the official OpenStack IRC channels), and we may remove entries
that are off-topic or spam.

So... please use #success liberally and record lttle everyday OpenStack
successes. Share the joy and make the OpenStack community a happy place.

-- 
Thierry Carrez (ttx)

__
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] [CI] Try to introduce RFC mechanism to CI.

2015-10-09 Thread Jordan Pittier

Hi,
On Fri, Oct 9, 2015 at 11:00 AM, Tang Chen  wrote:

> Hi,
>
> CI systems will run tests for each patch once it is submitted or modified.
> But most CI systems occupy a lot of resource, and take a long time to
> run tests (1 or 2 hours for one patch).
>
> I think, not all the patches submitted need to be tested. Even those
> patches
> with an approved BP and spec may be reworked for 20+ versions. So I think
> CI should support a RFC (Require For Comments) mechanism for developers
> to submit and review the code detail and rework. When the patches are
> fully ready, I mean all reviewers have agreed on the implementation detail,
> then CI will test the patches.

So have the humans do the hard work to eventually find out that the patch
breaks the world ?


> For a 20+ version patch-set, maybe 3 or 4 rounds
> of tests are enough. Just test the last 3 or 4 versions.
>
 How do know, when a new patchset arrives, that it's part of the last 3 or
4 versions ?

>
> This can significantly reduce CI overload.
>
> This workflow appears in many other OSS communities, such as Linux kernel,
> qemu and libvirt. Testers won't test patches with a [RFC] tag in the
> commit message.
> So I want to enable CI to support a similar mechanism.
>
> I'm not sure if it is a good idea. Please help to review the following BP.
>
> https://blueprints.launchpad.net/openstack-ci/+spec/ci-rfc-mechanism
>
> Thanks.
>
> __
> 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


I am running a 3rd party for Cinder. The amount of time to setup, operate
and watch after the CI results cost way more than the 1 or 2 servers it
take to run the jobs. So, I don"t want to be a party pooper here, but in my
opinion I am not sure it's worth the effort.

Note: I don"t know about nova or neutron.

Jordan
__
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] [Magnum] Testing result of new atomic-6 image

2015-10-09 Thread Qiao,Liyong


Testing result of new atomic-6 image [1] built by Tango
atomic-5 image has issue to start a container instance(docker version is 
1.7.1), Tango built a new atomic-6 image with docker 1.8.1 version.

eghobo and I (eliqiao) did some testing works (eghobo_ did most of them)

Here is the summary:

 * coe=swarm

1.  can not pull swarm:0.2.0, try to use 0.4.0 or latest works
2.  when creating a container with magnum CLI, the image name
   should use full name like "docker.io/cirros"

examples for 2:

   /taget@taget-ThinkStation-P300:~/kubernetes/examples/redis$ magnum
   container-create --name testcontainer --image cirros --bay swarmbay6
   --command "echo hello"//
   //ERROR: Docker internal Error: 404 Client Error: Not Found ("No
   such image: cirros") (HTTP 500)//
   //taget@taget-ThinkStation-P300:~/kubernetes/examples/redis$ magnum
   container-create --name testcontainer --image docker.io/cirros --bay
   swarmbay6 --command "echo hello"

   /

 * coe=k8s (tls_disabled=True)

kube-apiserver.service can not start up , but could use command line[2] 
to start, I tried to use kubctl get pod, but failed as


   /[minion@k8-5qx66ie62f-0-vaucgvagirv4-kube-master-oemtlcotgak6 ~]$
   kubectl get pod/
   /error: couldn't read version from server: Get
   http://localhost:8080/api: dial tcp 127.0.0.1:8080: connection refused/


netstat shows that 8080 is not in listened, not sure why(not familiar 
with k8s)


   /[minion@k8-5qx66ie62f-0-vaucgvagirv4-kube-master-oemtlcotgak6 ~]$
   ps aux | grep kub/
   /kube   805  0.5  1.0  30232 21436 ?Ssl  08:12 0:29
   /usr/bin/kube-controller-manager --logtostderr=true --v=0
   --master=http://127.0.0.1:8080/
   /kube   806  0.1  0.6  17332 13048 ?Ssl  08:12 0:09
   /usr/bin/kube-scheduler --logtostderr=true --v=0
   --master=http://127.0.0.1:8080/
   /root  1246  0.0  1.0  33656 22300 pts/0Sl+  09:33 0:00
   /usr/bin/kube-apiserver --logtostderr=true --v=0
   --etcd_servers=http://127.0.0.1:2379 --insecure-bind-address=0.0.0.0
   --insecure-port=8080 --kubelet_port=10250 --allow_privileged=true
   --service-cluster-ip-range=10.254.0.0/16 --runtime_config=api/all=true/
   /minion1276  0.0  0.0  11140  1632 pts/1S+   09:46 0:00 grep
   --color=auto kub/


[1] https://fedorapeople.org/groups/magnum/fedora-21-atomic-6-d181.qcow2
[2] http://paste.openstack.org/show/475824/

-- BR, Eli(Li Yong)Qiao
<>__
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] [ceilometer] Inconsistent timestamping of polled data

2015-10-09 Thread Wen Zhi WW Yu


Hi all,

As Gordon descriped in https://bugs.launchpad.net/ceilometer/+bug/1491509 ,
many of pollsters define the timestamp individually for each sample that is
generated rather than basing on when the data was polled. I agree with
Gordon on that the timestamping of samples should base on when the data was
polled.

What's your opinion on this?

Best Regards,
Yu WenZhi(余文治）
OpenStack on Power Development, IBM Shanghai
2F, 399 Keyuan Rd, Zhangjiang Chuangxin No. 10 Building, Zhangjiang High
Tech Park Shanghai
__
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] [CI] Try to introduce RFC mechanism to CI.

2015-10-09 Thread Tang Chen



On 10/09/2015 05:48 PM, Jordan Pittier wrote:

Hi,
On Fri, Oct 9, 2015 at 11:00 AM, Tang Chen > wrote:


Hi,

CI systems will run tests for each patch once it is submitted or
modified.
But most CI systems occupy a lot of resource, and take a long time to
run tests (1 or 2 hours for one patch).

I think, not all the patches submitted need to be tested. Even
those patches
with an approved BP and spec may be reworked for 20+ versions. So
I think
CI should support a RFC (Require For Comments) mechanism for
developers
to submit and review the code detail and rework. When the patches are
fully ready, I mean all reviewers have agreed on the
implementation detail,
then CI will test the patches. 

So have the humans do the hard work to eventually find out that the 
patch breaks the world ?


No. Developers of course will run some tests themselves before they 
submit patches.
It is just a waste of resource if reviewers are discussing about where 
this function should be,
or what the function should be named. After all these details are agreed 
on, run the CI.



For a 20+ version patch-set, maybe 3 or 4 rounds
of tests are enough. Just test the last 3 or 4 versions.

 How do know, when a new patchset arrives, that it's part of the last 
3 or 4 versions ?


I think it could work like this:
1. At first, developer submits v1 patch-set with RFC tag. CIs don't run.
2. After several versions reworked, like v5, v6, most reviewers have 
agreed on the implementation

is OK. Then submit v7 without RFC tag. Then CIs run.
3. After 3, 4 rounds of tests, v10 patch-set could be merged.

Thanks.



This can significantly reduce CI overload.

This workflow appears in many other OSS communities, such as Linux
kernel,
qemu and libvirt. Testers won't test patches with a [RFC] tag in
the commit message.
So I want to enable CI to support a similar mechanism.

I'm not sure if it is a good idea. Please help to review the
following BP.

https://blueprints.launchpad.net/openstack-ci/+spec/ci-rfc-mechanism

Thanks.

__
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


I am running a 3rd party for Cinder. The amount of time to setup, 
operate and watch after the CI results cost way more than the 1 or 2 
servers it take to run the jobs. So, I don"t want to be a party pooper 
here, but in my opinion I am not sure it's worth the effort.


Note: I don"t know about nova or neutron.

Jordan



__
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] [swift] Plan to port Swift to Python 3

2015-10-09 Thread vishal yadav

Victor,

I appreciate for your effort.

However I was just checking if you considered using 2to3. I can understand
that translation using this tool might not cover every area in the code
more specifically custom/3rd party libraries (non-standard python
libraries) but IMO it can do fixer translations to much extent. If needed
custom fixers can also be defined for 2to3.

- https://docs.python.org/2/library/2to3.html
- https://docs.python.org/3/howto/pyporting.html

Thanks,
Vishal

On Fri, Oct 9, 2015 at 2:34 PM, Thierry Carrez 
wrote:

> Victor Stinner wrote:
> > Good news, we made good progress last weeks on porting Swift to Python
> > 3, a few changes were merged and all dependencies now work on Python 3.
> > We only need two more simple changes to have a working pyhon34 check job:
> >
> > * "py3: Update pbr and dnspython requirements"
> >   https://review.openstack.org/#/c/217423/
> > * "py3: Add py34 test environment to tox"
> >   https://review.openstack.org/#/c/199034/
> >
> > With these changes, it will be possible to make the python34 check job
> > voting to avoid Python 3 regressions. It's very important to avoid
> > regressions, so we cannot go backward again in Python 3 support.
> >
> > On IRC, it was said that it's better to merge Python 3 changes at the
> > beginning of the Mitaka cycle, because Python 3 requires a lot of small
> > changes which can likely introduce (subtle) bugs, and it's better to
> > catch them early during the development cycle.
> >
> > John Dickinson prefers incremental and small changes, whereas clayg
> > looks to like giant patches to fix all Python 3 issues at once to avoid
> > conflicts in other (non-Python3) changes. (Sorry, if I didn't summarized
> > correctly the discussion we had yesterday.)
> >
> > The problem is that it's hard to fix "all" Python 3 issues in a single
> > patch, the patch would be super giant and just impossible to review.
> > It's also annoying to have to write dozens of small patches: we loose
> > time on merge conflicts, rebasing, random gate failures, etc.
> >
> > I proposed a first patch serie of 6 changes to fix a lot of simple
> > Python 3 issues "at once":
> > [...]
> >
> > The overall diff is impressive: "61 files changed, 233 insertions(+),
> > 189 deletions(-)" ... but each change is quite simple. It's only one
> > pattern replaced with a different pattern. For example, replace
> > "unicode" with "six.text_type" (and add "import six" if needed). So
> > these changes should be easy to review.
> >
> > With a working (and voting?) python34 check job and these 6 changes, it
> > will be (much) easier to work on porting Swift to Python 3. Following
> > patches will be validated by the python34 check job, shorter and
> > restricted to a few files.
> >
> > Victor
>
> That's great news. Thanks so much for your tireless efforts to get
> Python 3 supported everywhere in OpenStack, Victor !
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [ironic] Nominating two new core reviewers

2015-10-09 Thread Yuriy Zveryanskyy


+2 for both, Vladyslav and John.

On 10/09/2015 12:47 AM, Jim Rollenhagen wrote:

Hi all,

I've been thinking a lot about Ironic's core reviewer team and how we might
make it better.

I'd like to grow the team more through trust and mentoring. We should be
able to promote someone to core based on a good knowledge of *some* of
the code base, and trust them not to +2 things they don't know about. I'd
also like to build a culture of mentoring non-cores on how to review, in
preparation for adding them to the team. Through these pieces, I'm hoping
we can have a few rounds of core additions this cycle.

With that said...

I'd like to nominate Vladyslav Drok (vdrok) for the core team. His reviews
have been super high quality, and the quantity is ever-increasing. He's
also started helping out with some smaller efforts (full tempest, for
example), and I'd love to see that continue with larger efforts.

I'd also like to nominate John Villalovos (jlvillal). John has been
reviewing a ton of code and making a real effort to learn everything,
and keep track of everything going on in the project.

Ironic cores, please reply with your vote; provided feedback is positive,
I'd like to make this official next week sometime. Thanks!

// jim


__
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] [all] jobs that make break when we remove Devstack extras.d in 10 weeks

2015-10-09 Thread Sean Dague

>From now until the removal of devstack extras.d support I'm going to
send a weekly email of jobs that may break. A warning was added that we
can track in logstash.

Here are the top 25 jobs (by volume) that are currently tripping the
warning:

gate-murano-devstack-dsvm
gate-cue-integration-dsvm-rabbitmq
gate-murano-congress-devstack-dsvm
gate-solum-devstack-dsvm-centos7
gate-rally-dsvm-murano-task
gate-congress-dsvm-api
gate-tempest-dsvm-ironic-agent_ssh
gate-solum-devstack-dsvm
gate-tempest-dsvm-ironic-pxe_ipa-nv
gate-ironic-inspector-dsvm-nv
gate-tempest-dsvm-ironic-pxe_ssh
gate-tempest-dsvm-ironic-parallel-nv
gate-tempest-dsvm-ironic-pxe_ipa
gate-designate-dsvm-powerdns
gate-python-barbicanclient-devstack-dsvm
gate-tempest-dsvm-ironic-pxe_ssh-postgres
gate-rally-dsvm-designate-designate
gate-tempest-dsvm-ironic-pxe_ssh-dib
gate-tempest-dsvm-ironic-agent_ssh-src
gate-tempest-dsvm-ironic-pxe_ipa-src
gate-muranoclient-dsvm-functional
gate-designate-dsvm-bind9
gate-tempest-dsvm-python-ironicclient-src
gate-python-ironic-inspector-client-dsvm
gate-tempest-dsvm-ironic-lib-src-nv

(You can view this query with http://goo.gl/6p8lvn)

The ironic jobs are surprising, as something is crudding up extras.d
with a file named 23, which isn't currently run. Eventual removal of
that directory is going to potentially make those jobs fail, so someone
more familiar with it should look into it.

This is not guarunteed to be a complete list, but as jobs are removed /
fixed we should end up with other less frequently run jobs popping up in
future weeks.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [stable][horizon] adding stable reviewer

2015-10-09 Thread Matthias Runge

Hello,

who would be the person to talk to, to add a new reviewer to
horizon-stable-maint

I would like Doug Fish aka drfish (on launchpad) added.

Unfortunately, the fields on
https://review.openstack.org/#/admin/groups/537,members
are greyed out for me.

Thanks, Matthias

__
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] [stable][horizon] adding stable reviewer

2015-10-09 Thread Yolanda Robla Mota


Hi Matthias
That group is owned by stable-maint-core
So you should look at members there 
(https://review.openstack.org/#/admin/groups/530,members) and ask some 
of them to add Doug.


Best
Yolanda

El 09/10/15 a las 12:44, Matthias Runge escribió:

Hello,

who would be the person to talk to, to add a new reviewer to
horizon-stable-maint

I would like Doug Fish aka drfish (on launchpad) added.

Unfortunately, the fields on
https://review.openstack.org/#/admin/groups/537,members
are greyed out for me.

Thanks, Matthias

__
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


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hpe.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

Re: [openstack-dev] [all] jobs that make break when we remove Devstack extras.d in 10 weeks


On 10/09/2015 12:35 PM, Sean Dague wrote:

 From now until the removal of devstack extras.d support I'm going to
send a weekly email of jobs that may break. A warning was added that we
can track in logstash.

Here are the top 25 jobs (by volume) that are currently tripping the
warning:

gate-murano-devstack-dsvm
gate-cue-integration-dsvm-rabbitmq
gate-murano-congress-devstack-dsvm
gate-solum-devstack-dsvm-centos7
gate-rally-dsvm-murano-task
gate-congress-dsvm-api
gate-tempest-dsvm-ironic-agent_ssh
gate-solum-devstack-dsvm
gate-tempest-dsvm-ironic-pxe_ipa-nv
gate-ironic-inspector-dsvm-nv
gate-tempest-dsvm-ironic-pxe_ssh
gate-tempest-dsvm-ironic-parallel-nv
gate-tempest-dsvm-ironic-pxe_ipa
gate-designate-dsvm-powerdns
gate-python-barbicanclient-devstack-dsvm
gate-tempest-dsvm-ironic-pxe_ssh-postgres
gate-rally-dsvm-designate-designate
gate-tempest-dsvm-ironic-pxe_ssh-dib
gate-tempest-dsvm-ironic-agent_ssh-src
gate-tempest-dsvm-ironic-pxe_ipa-src
gate-muranoclient-dsvm-functional
gate-designate-dsvm-bind9
gate-tempest-dsvm-python-ironicclient-src
gate-python-ironic-inspector-client-dsvm
gate-tempest-dsvm-ironic-lib-src-nv

(You can view this query with http://goo.gl/6p8lvn)

The ironic jobs are surprising, as something is crudding up extras.d
with a file named 23, which isn't currently run. Eventual removal of
that directory is going to potentially make those jobs fail, so someone
more familiar with it should look into it.


Thanks for noticing, looking now.



This is not guarunteed to be a complete list, but as jobs are removed /
fixed we should end up with other less frequently run jobs popping up in
future weeks.

-Sean




__
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] [stable][horizon] adding stable reviewer

> On 09 Oct 2015, at 12:44, Matthias Runge  wrote:
> 
> Hello,
> 
> who would be the person to talk to, to add a new reviewer to
> horizon-stable-maint
> 
> I would like Doug Fish aka drfish (on launchpad) added.
> 
> Unfortunately, the fields on
> https://review.openstack.org/#/admin/groups/537,members
> are greyed out for me.
> 
> Thanks, Matthias

Added the new member to the group.

Welcome Doug!

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [Fuel] py.test vs testrepository

2015-10-09 Thread Roman Prykhodchenko

Thank you guys for all your help! Special thanks to Robert who helped to find a 
workaround for an issue [1] that didn’t let us use testr for Fuel Client. The 
patch [2] was merged and both unit and functional tests are launched by subunit 
and the data is maintained by testrepository.

Please also note that in order to facilitate debugging two additional tox 
environments —  dbgunit or dbgfunc,  were introduced for either unit or 
functional tests.


1. https://bugs.launchpad.net/testrepository/+bug/1504310 

2. https://review.openstack.org/#/c/227895/


- romcheg


> 9 жовт. 2015 р. о 01:51 Roman Prykhodchenko  написав(ла):
> 
> Folks,
> 
> Since we’ve reached the consensus here I’d like to invite you to review the 
> patch [1] that replaces py.test with testr without making debuging or running 
> specific tests harder. Please also note that it has a dependency which needs 
> to be reviewed and merged first one.
> 
> 1. https://review.openstack.org/#/c/227895
> 
> 
> - romcheg
> 
> 
>> 7 жовт. 2015 р. о 14:41 Roman Prykhodchenko  написав(ла):
>> 
>> Michał,
>> 
>> some comments in-line
>> 
 - testrepository and related components are used in OpenStack Infra
 environment for much more tasks than just running tests
>>> 
>>> If by "more tasks" you mean parallel testing, py.test also has a
>>> possibility to do that by pytest-xdist.
>> 
>> As Monthy mentioned, it’s not only about testing, it’s more about deeper 
>> integration with OpenStack Infra.
>> 
>> 
 - py.test won’t be added to global-requirements so there always be a chance
 of another dependency hell
>>> 
>>> As Igor Kalnitsky said, py.test doesn't have much requirements.
>>> https://github.com/pytest-dev/pytest/blob/master/setup.py#L58
>>> It's only argparse, which already is in global requirements without
>>> any version pinned.
>> 
>> It’s not only about py.test, there is an up-to-date objective of sticking 
>> all requirements to global-requirements because we have big problems because 
>> of that every release.
>> 
>>> 
>>> Cheers,
>>> Michal
>>> 
>>> __
>>> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [swift] Plan to port Swift to Python 3

2015-10-09 Thread Victor Stinner


Hi,

Le 09/10/2015 12:12, vishal yadav a écrit :

However I was just checking if you considered using 2to3. I can
understand that translation using this tool might not cover every area
in the code more specifically custom/3rd party libraries (non-standard
python libraries) but IMO it can do fixer translations to much extent.


I tried 2to3, modernize and 2to6 tools in the past, but they produce a 
single giant patch with unwanted changes. These tools are written to add 
compatibility for all Python versions including Python 2.6 and Python 
3.0. In OpenStack, we only care of Python 2.7 and 3.4, so the code can 
be simpler. For example, we can simply write u"unicode" instead of 
six.b("unicode").


I wrote the sixer tool for OpenStack. Basically, it's the same than 
2to6, except that:


- sixer respects OpenStack Coding Style on imports: it groups and sorts 
imports. It avoids to have to manually fix individual modified import 
which takes a lot of time


- sixer can produce a patch for a single pattern. For example, replace 
all unicode with six.text_type but nothing else. Since all changes are 
reviewed carefully in OpenStack, it's important to produce "reviewable" 
(small) changes.


See also my blog article which explains the full rationale:
http://haypo.github.io/python3-sixer.html

My patch serie of 6 changes to fix most Python 3 issues was almost fully 
generated by sixer. Sometimes, I had to manually fix a few lines because 
no tool is perfect ;-) The patch serie:


* "py3: Replace unicode with six.text_type"
  https://review.openstack.org/#/c/232476/

* "py3: Replace urllib imports with six.moves.urllib"
  https://review.openstack.org/#/c/232536/

* "py3: Use six.reraise() to reraise an exception"
  https://review.openstack.org/#/c/232537/

* "py3: Replace gen.next() with next(gen)"
  https://review.openstack.org/#/c/232538/

* "Replace itertools.ifilter with six.moves.filter"
  https://review.openstack.org/#/c/232539/

* "py3: Replace basestring with six.string_types"
  https://review.openstack.org/#/c/232540/

Then I will then use sixer on individual files to fix all Python 3 at once.

Victor

__
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] [stable][horizon] adding stable reviewer

2015-10-09 Thread Thierry Carrez

Ihar Hrachyshka wrote:
> Welcome Doug!

Please (re)read and apply the policy at:
https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

-- 
Thierry Carrez (ttx)



signature.asc
Description: OpenPGP digital signature
__
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] [all] Recording little everyday OpenStack successes

> On 09 Oct 2015, at 11:42, Thierry Carrez  wrote:
> 
> Hello everyone,
> 
> OpenStack has become quite big, and it's easier than ever to feel lost,
> to feel like nothing is really happening. It's more difficult than ever
> to feel part of a single community, and to celebrate little successes
> and progress.
> 
> In a (small) effort to help with that, I suggested making it easier to
> record little moments of joy and small success bits. Those are usually
> not worth the effort of a blog post or a new mailing-list thread, but
> they show that our community makes progress *every day*.
> 
> So whenever you feel like you made progress, or had a little success in
> your OpenStack adventures, or have some joyful moment to share, just
> throw the following message on your local IRC channel:
> 
> #success [Your message here]
> 
> The openstackstatus bot will take that and record it on this wiki page:
> 
> https://wiki.openstack.org/wiki/Successes
> 
> We'll add a few of those every week to the weekly newsletter (as part of
> the developer digest that we reecently added there).
> 
> Caveats: Obviously that only works on channels where openstackstatus is
> present (the official OpenStack IRC channels), and we may remove entries
> that are off-topic or spam.
> 
> So... please use #success liberally and record lttle everyday OpenStack
> successes. Share the joy and make the OpenStack community a happy place.

That is oh so cool! :)

Another IRC service that I find useful to encourage collaboration in teams is a 
karma bot. Something that would calculate ++ messages in tracked 
channels. Having such a lightweight and visible way to tell ‘thank you’ to a 
contributor would be great. Do we have plans to implement it in infra?

Ihar



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Metadata via dhcp namespace not working for icehouse release

> On 09 Oct 2015, at 09:00, Pradeep kumar  wrote:
> 
> 
> Hii Guys,
> I am trying to run Metadata via the DHCP namespace by following blog post 
> mentioned below:
> 
> http://techbackground.blogspot.in/2013/06/metadata-via-dhcp-namespace.html
> 
> Commands mentioned on above link for debugging o/p is exactly same for my 
> setup. Also i am able to ping 169.254.169.254 metadata server ip. But while 
> running below command from VM i get
> 
> curl http://169.254.169.254
> 
> curl: (7) Failed to connect to 169.254.169.254 port 80: Connection timed out
> 
> and
> 
> curl http://169.254.169.254:53
> gives empty response
> &
> from controller node if i run curl http://169.254.169.254 i get
> curl http://169.254.169.254:8775
> 1.0
> 2007-01-19
> 2007-03-01
> 2007-08-29
> 2007-10-10
> 2007-12-15
> 2008-02-01
> 2008-09-01
> 2009-04-04
> On controller node:
> netstat -nap | grep 8775 gives
> tcp0  0 0.0.0.0:87750.0.0.0:*   LISTEN
>   13619/python
> 
> Please suggest some pointers i am stuck at the same point from last 10 days.
> 
> Regards
> Pradeep Kumar

Icehouse is no longer supported. Please retry on a supported version Juno+.

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Inconsistent timestamping of polled data

2015-10-09 Thread Igor Degtiarov

Hi!

Looks good to me, especially for cases when after some incident we gather a
great amount of notifications in queue and stated to work with it so some
data will have incorrect timestamp if it set only when sample is created.

Cheers,

Igor Degtiarov
Software Engineer
Mirantis Inc.
www.mirantis.com

On Fri, Oct 9, 2015 at 1:00 PM, Wen Zhi WW Yu  wrote:

> Hi all,
>
> As Gordon descriped in https://bugs.launchpad.net/ceilometer/+bug/1491509
> , many of pollsters define the timestamp individually for each sample that
> is generated rather than basing on when the data was polled. I agree with
> Gordon on that the timestamping of samples should base on when the data was
> polled.
>
> What's your opinion on this?
>
> Best Regards,
> Yu WenZhi(余文治）
> OpenStack on Power Development, IBM Shanghai
> 2F, 399 Keyuan Rd, Zhangjiang Chuangxin No. 10 Building, Zhangjiang High
> Tech Park Shanghai
>
> __
> 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] [CI] Try to introduce RFC mechanism to CI.


On 10/09/2015 12:06 PM, Tang Chen wrote:


On 10/09/2015 05:48 PM, Jordan Pittier wrote:

Hi,
On Fri, Oct 9, 2015 at 11:00 AM, Tang Chen mailto:tangc...@cn.fujitsu.com>> wrote:

Hi,

CI systems will run tests for each patch once it is submitted or
modified.
But most CI systems occupy a lot of resource, and take a long time to
run tests (1 or 2 hours for one patch).

I think, not all the patches submitted need to be tested. Even
those patches
with an approved BP and spec may be reworked for 20+ versions. So
I think
CI should support a RFC (Require For Comments) mechanism for
developers
to submit and review the code detail and rework. When the patches are
fully ready, I mean all reviewers have agreed on the
implementation detail,
then CI will test the patches.

So have the humans do the hard work to eventually find out that the
patch breaks the world ?


No. Developers of course will run some tests themselves before they
submit patches.


Tests, but not all possible CI's. E.g. in ironic we 6 devstack-based 
jobs, I don't really expect a submitter to go through them manually. 
Actually, it's an awesome feature of our CI system that I would not give 
away :)


Also as a reviewer, I'm not sure I would like to argue on function 
names, while I'm not even sure that this change does not break the world.



It is just a waste of resource if reviewers are discussing about where
this function should be,
or what the function should be named. After all these details are agreed
on, run the CI.


For a 20+ version patch-set, maybe 3 or 4 rounds
of tests are enough. Just test the last 3 or 4 versions.

 How do know, when a new patchset arrives, that it's part of the last
3 or 4 versions ?


I think it could work like this:
1. At first, developer submits v1 patch-set with RFC tag. CIs don't run.
2. After several versions reworked, like v5, v6, most reviewers have
agreed on the implementation
 is OK. Then submit v7 without RFC tag. Then CIs run.
3. After 3, 4 rounds of tests, v10 patch-set could be merged.

Thanks.



This can significantly reduce CI overload.

This workflow appears in many other OSS communities, such as Linux
kernel,
qemu and libvirt. Testers won't test patches with a [RFC] tag in
the commit message.
So I want to enable CI to support a similar mechanism.

I'm not sure if it is a good idea. Please help to review the
following BP.

https://blueprints.launchpad.net/openstack-ci/+spec/ci-rfc-mechanism

Thanks.

__
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


I am running a 3rd party for Cinder. The amount of time to setup,
operate and watch after the CI results cost way more than the 1 or 2
servers it take to run the jobs. So, I don"t want to be a party pooper
here, but in my opinion I am not sure it's worth the effort.

Note: I don"t know about nova or neutron.

Jordan



__
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-dev] [All][Elections] Vote Vote Vote in the TC election!

2015-10-09 Thread Tristan Cacqueray

We are coming down the the last hours for voting in the TC election.

Search your gerrit preferred email address[0] for the following subject:
  Poll: OpenStack Technical Committee (TC) Election - October 2015

That is your ballot and links you to the voting application. Please
vote. If you have voted, please encourage your colleagues to vote.

Candidate statements are linked to the names of all confirmed candidates:
https://wiki.openstack.org/wiki/TC_Elections_September/October_2015#Confirmed_Candidates

What to do if you don't see the email and have a commit in at least one
of the official programs projects[1]:
  * check the trash of your gerrit Preferred Email address[0],
in case it went into trash or spam
  * wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project
repos[1] and email me and Tony[2]. If we can confirm that you are
entitled to vote, we will add you to the voters list and you will
be emailed a ballot.

Please vote!

Thank you,
Tristan

[0] Sign into review.openstack.org: Go to Settings > Contact
Information. Look at the email listed as your Preferred Email.
That is where the ballot has been sent.
[1]
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2015-elections
[2] Tony (tonyb): tony at bakeyournoodle dot com
Tristan (tristanC): tdecacqu at redhat dot com



signature.asc
Description: OpenPGP digital signature
__
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] [infra] Try to introduce RFC mechanism to CI.

On 2015-10-09 18:06:55 +0800 (+0800), Tang Chen wrote:
[...]
> It is just a waste of resource if reviewers are discussing about
> where this function should be, or what the function should be
> named. After all these details are agreed on, run the CI.
[...]

As one of the people maintaining the upstream CI and helping
coordinate our resources/quotas, I don't see that providing early
test feedback is a waste. We're steadily increasing the instance
quotas available to us, so check pipeline utilization should
continue to become less and less of a concern anyway.

For a change which is still under debate, feel free to simply ignore
test results until you get it to a point where you see them start to
become relevant.
-- 
Jeremy Stanley

__
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] [CI] Try to introduce RFC mechanism to CI.

On 2015-10-09 17:00:27 +0800 (+0800), Tang Chen wrote:
[...]
> I'm not sure if it is a good idea. Please help to review the
> following BP.
> 
> https://blueprints.launchpad.net/openstack-ci/+spec/ci-rfc-mechanism

The Infra team doesn't rely on blueprints, and instead uses
http://specs.openstack.org/openstack-infra/infra-specs/ to plan
complex implementation work. I only just discovered that you can
disable blueprints on a project in Launchpad, so I've now done that
for the "openstack-ci" project.

That said, I don't expect the proposed feature would get very far.
We're committed to providing test results for all patchsets when
possible; that doesn't mean you are required to pay attention to the
results or even wait for them to be posted on your change while it's
still in a state of initial flux.
-- 
Jeremy Stanley

__
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] [mistral] [heat] Mistral Workflow resource type - resource signal handling

2015-10-09 Thread Renat Akhmerov


> On 08 Oct 2015, at 23:27, ELISHA, Moshe (Moshe) 
>  wrote:
> 
> Hi,
>  
> I would like to propose a change in the behavior of the OS::Mistral::Workflow 
> resource signal.
>  
> CURRENT:
> The OS::Mistral::Workflow resource type is expecting the following request 
> body on resource signal request:
>  
> {
>   "input": {
> ...
>   },
>   "params": {
> ...
>   }
> }
>  
> The input section is optional and if exists it will be passed to the workflow 
> execution as inputs
> The params section is also optional and if exists it will be passed to the 
> workflow execution as parameters.
>  
> The problem this approach creates is that external systems many times send a 
> predefined body that you cannot control and it is obviously not in the format 
> the resource is expecting.
> So you basically have no way to pass the information from the request body to 
> the workflow execution.

That makes sense to me, I’m just wondering if it’s possible to have a 
transformer somewhere that would convert data to a needed form. I’m not that 
good at Heat though.


> SUGGESTION:
> OS::Mistral::Workflow will treat the root of the JSON request body as input 
> parameters.
> That way you will be able to use external systems by making sure your WF 
> inputs are aligned with what the external system sends.
>  
> For example, if you try to put the WF alarm_url as a Ceilometer alarm action 
> - Ceilometer will send a request similar to:
>  
> {
>  "severity": "low",
>  "alarm_name": "my-alarm",
>  "current": "insufficient data",
>  "alarm_id": "895fe8c8-3a6e-48bf-b557-eede3e7f4bbd",
>  "reason": "1 datapoints are unknown",
>  "reason_data": {
>"count": 1,
>"most_recent": null,
>"type": "threshold",
>"disposition": "unknown"
>  },
>  "previous": "ok"
> }
>  
> The WF could get this info as input if it will be defined like so:
>  
>   my_workflow:
> type: OS::Mistral::Workflow
> properties:
>   input:
> current: !!null
> alarm_id: !!null
> reason: !!null
> previous: !!null
> severity: !!null
> alarm_name: !!null
> reason_data: !!null
>  
>  
> The (least used) “params” section can be passed in an custom HTTP header and 
> the OS::Mistral::Workflow will read those from the header and pass it to the 
> WF execution.
> Remember, we are trying to solve the problem where you can’t influence the 
> request format – so in any case the signal will not get the params in the 
> request body.
> If the WF of the user must receive params, the user will always be able to 
> create a wrapper WF with only inputs that starts the orig WF with inputs and 
> params.

I’m generally ok with this suggestion. My only concern is that we won’t be able 
to trigger the same WF with different type of triggers. For instance, I want to 
have a WF that does healing but I want to have Ceilometer alarm and some other 
type of trigger (e.g. some monitoring system like Zabbix) to trigger this WF. 
Most likely it would not be straightforward because I’d have to design my WF 
for a certain triggering systems: its input values should match request body 
structure sent by a trigger.

At the same time, this is probably going to be a rare situation when we need 
two types of triggers. And like you said we can always create a wrapper 
workflow, if needed for other types of triggers. General approach here actually 
may be: we create a WF with input structure that’s most convenient from WF 
standpoint itself and for every type of trigger we create a wrapper WF, if 
needed.


> In order to make this non-backward compatible change, I suggest to add a 
> property “params_alarm_http_header_name” to the OS::Mistral::Workflow. If 
> null the params are expected to be in the body as today.
> If not null – the request should have a header with that name and the value 
> will be a string representing a JSON dict.

Sounds ok to me.

Renat Akhmerov
@ Mirantis Inc.

__
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] [stable][horizon] adding stable reviewer

2015-10-09 Thread Matthias Runge

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/15 13:44, Thierry Carrez wrote:
> Ihar Hrachyshka wrote:
>> Welcome Doug!
> 
> Please (re)read and apply the policy at: 
> https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy

Thank you Ihar!

Best,
Matthias

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWF7afAAoJEBdpskgc9eOLn04QAMVQhUCArh3rvpTBqHIS0mCB
SHdj1Go5LMU6+t8p42codEn0q+dihtO5sZaOKx+7LR6YZn5AhEmnf8ihn7dB4iHA
I+xgEdBNDXoalQhvS9fuoMtOqVesf+aUaH1bEnsktQpycYwXCXz5bSDhHqYEMkvn
Yq1rJfzA3JpHSeLR0yTaT3eFNfOJYyIx2vo9+bl77U7kZ8NnWpKsH3HRRXfW90fy
8Z6udKo3+bqtf03xHJAyHGxlD7TtkL5mGeNY9P+WKlHHKXSW3kkKpUj2RotzVoD3
d3Zz9A8g350vbXrfFhVwsbjdWBW6UMgtOpAheqZ+Nz/w/ZqClPGT6NAxjJfyLLWL
EsKcy4oHJ1VZPk7ql+MEjK6WNLe5c6PPTQT1QSOv49YfFfDPRYCBYx32Gs3hAMRH
zSRm24DJBoGq6aVBQQFUhun4YuisglWYTaSvwQbqe5arS/lNOyWzEC2sbI5ffJLR
fjtFXmJQDgJRIxkAC0VKlXEMizAfMstZJoG/ID05VZPe6KWGwlkrkAkT5p0XR2Oz
5EqJ9myy+Y9ZKwNC32R5fEt8JCG3z/FLMmA64OYtZ3ylY3VTrBzGVg4TtsP28gkV
AcKMMuSyIaKMpAavR7SWxJq1HvSr9bDQqCX+4AHApxvr0Z8YN355AudlTbylLUGz
wumYrnthpMwF6UpCA09K
=4S4k
-END PGP SIGNATURE-

__
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] [Heat] mox to mock migration

2015-10-09 Thread Jay Dobies

I forget where we left things at the last meeting with regard to whether 
or not there should be a blueprint on this. I was going to work on some 
during some downtime but I wanted to make sure I wasn't overlapping with 
what others may be converting (it's more time consuming than I anticipated).


Any thoughts on how to track it?

Thanks :)

__
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] [Neutron] Returning of HEAD files?

2015-10-09 Thread Anna Kamyshnikova

Some time ago we merged change [1] that removes HEADS file. Validation of
migration revisions using HEADS file was replaced with pep8. This allows us
to avoid merge conflicts that appeared every time a new migration was
merged.

The problem was pointed by Kevin Benton as the original idea of HEAD file
[2] was not only to validate revisions, so as not to allow outdated changes
go into merge queue, that could be very important for the end of the cycle
when a lot of patches get approved.

I introduced change [3] that returns HEAD files, but this time they are
created per branch, so that will reduce merge conflicts a bit.

I understand that it was better to ask at the first time when [1] was on
review, should we have HEAD files and merge conflicts or not, but I want to
ask it now: Should I continue work on [3] or we are not expecting to have
problems with big merge queues?


[1] - https://review.openstack.org/#/c/227319/
[2] -
https://github.com/openstack/neutron/commit/36d85f831ae8eb21383806261bfc4c3d53dd1929
[3] - https://review.openstack.org/#/c/232607/

-- 
Regards,
Ann Kamyshnikova
Mirantis, Inc
__
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] [Heat] mox to mock migration

2015-10-09 Thread Sergey Kraynev

Jay,

I think, that only one person who partially do the same job is Qiming.
Please ask him about it.
Also I think, that will be good to create BP for it, which you may
mention in commit messages.
In this Bp you may specify list of directories for parallel work.
There is nothing else from my side. :)
Thank you for volunteering!

On 9 October 2015 at 16:06, Jay Dobies  wrote:
> I forget where we left things at the last meeting with regard to whether or
> not there should be a blueprint on this. I was going to work on some during
> some downtime but I wanted to make sure I wasn't overlapping with what
> others may be converting (it's more time consuming than I anticipated).
>
> Any thoughts on how to track it?
>
> Thanks :)
>
> __
> 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



-- 
Regards,
Sergey.

__
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] Requests + urllib3 + distro packages

2015-10-09 Thread William M Edmonds

Robert Collins  writes:
>  - Linux vendors often unbundle urllib3 from requests and then apply
> what patches were needed to their urllib3; while not updating their
> requests package dependencies to reflect this.

I opened a bug on Fedora for them to update their requests package
dependencies. See https://bugzilla.redhat.com/show_bug.cgi?id=1253823. Of
course that may continue to be an issue on older versions and other
distros.

>  - if for any reason we have a distro-altered requests + a
> pip-installed urllib3, requests will [usually] break... see the 'not
> always released yet' key thing above.
>
> Now, there are lots of places this last thing can happen; they all
> depend on us having a dependency on requests that is compatible with
> the version installed by the distro, but a urllib3 dependency that
> triggers an upgrade of just urllib3. When constraints are in use, the
> requests version has to match the distro requests version exactly, but
> that will happen from time to time.

When you're using a distro, you're always going to have to worry about
someone pip installing something that conflicts with the rpm, no? That
could be for any reason, could be completely unrelated to OpenStack
dependencies. Unless the distros have a way to put in protection against
this, preventing pip install of something that is already installed by RPM?

>  - make sure none of our testing environments include distro
> requests packages.

It's not like requests is an unusual package for someone to have installed
from their distro in a base OS image. So when they take that base OS and go
to setup OpenStack, they'll be hitting this case, whether we tested it or
not. So while not testing this case seems nice from a development
perspective, it doesn't seem to fit real-world usage. I don't think it
would make operators very happy.
__
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] [Murano] py26 support in python-muranoclient

On 2015-10-09 12:22:12 +0300 (+0300), Serg Melikyan wrote:
> unfortunately we don't plan to remove support for py26 from the
> python-muranoclient, most of the python-client support py26
> in order to work out of the box on different OS including CentOS 6.5
> and so on.
[...]

Bear in mind that we were only keeping 2.6 testing around to support
the stable/juno branch, and intend to begin removing support for
running Python 2.6 tests from our CI when that branch reaches EOL in
a few weeks. The end-of-2.6 discussions we had now many summits ago
involved representatives from several Enterprise/LTS Linux
distributions who agreed that supporting it in Kilo and beyond would
not be necessary.
-- 
Jeremy Stanley

__
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] Requests + urllib3 + distro packages

2015-10-09 Thread William M Edmonds

Cory Benfield  writes:
> > The problem that occurs is the result of a few interacting things:
> >  - requests has very very specific versions of urllib3 it works with.
> > So specific they aren't always released yet.
>
> This should no longer be true. Our downstream redistributors pointedout
to us
> that this  was making their lives harder than they needed to be, so it's
now
> our policy to only  update to actual release versions of urllib3.

That's great... except that I'm confused as to why requests would continue
to repackage urllib3 if that's the case. Why not just prereq the version of
urllib3 that it needs? I thought the one and only answer to that question
had been so that requests could package non-standard versions.
__
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] [Sender Auth Failure] [neutron] New cycle started. What are you up to, folks?

2015-10-09 Thread Howard, Victor

I¹d like to help out in some fashion with FwaaS and the IPV6 needs
mentioned.  Current working on the DSCP Spec and patches to implement
ontop of QOS.

I liked Seans comments about devstack, we have been doing tons of testing
for DSCP there without really understanding how things are going to be
updated or knowing if its current with production on master. Would like to
help out in discussing the best way to move forward to keep devstack in
synch or help to update it.

On 10/1/15, 9:45 AM, "Ihar Hrachyshka"  wrote:

>Hi all,
>
>I talked recently with several contributors about what each of us plans
>for the next cycle, and found it¹s quite useful to share thoughts with
>others, because you have immediate yay/nay feedback, and maybe find
>companions for next adventures, and what not. So I¹ve decided to ask
>everyone what you see the team and you personally doing the next cycle,
>for fun or profit.
>
>That¹s like a PTL nomination letter, but open to everyone! :) No
>commitments, no deadlines, just list random ideas you have in mind or in
>your todo lists, and we¹ll all appreciate the huge pile of awesomeness no
>one will ever have time to implement even if scheduled for Xixao release.
>
>To start the fun, I will share my silly ideas in the next email.
>
>Ihar

__
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] [all] Recording little everyday OpenStack successes

On 2015-10-09 13:51:39 +0200 (+0200), Ihar Hrachyshka wrote:
[...]
> Another IRC service that I find useful to encourage collaboration
> in teams is a karma bot. Something that would calculate
> ++ messages in tracked channels. Having such a
> lightweight and visible way to tell ‘thank you’ to a contributor
> would be great. Do we have plans to implement it in infra?

If you write it! An easy compromise would be to just add similar
support like "#thanks ttx for your awesome successbot
implementation!" and interleave those into the same Successes
article or direct them to a separate Karma article. If you want an
interface to tabulate/summarize #thanks calls though, that would
likely need some additional service.
-- 
Jeremy Stanley

__
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] Returning of HEAD files?

> On 09 Oct 2015, at 15:28, Anna Kamyshnikova  
> wrote:
> 
> Some time ago we merged change [1] that removes HEADS file. Validation of 
> migration revisions using HEADS file was replaced with pep8. This allows us 
> to avoid merge conflicts that appeared every time a new migration was merged.
> 
> The problem was pointed by Kevin Benton as the original idea of HEAD file [2] 
> was not only to validate revisions, so as not to allow outdated changes go 
> into merge queue, that could be very important for the end of the cycle when 
> a lot of patches get approved.
> 
> I introduced change [3] that returns HEAD files, but this time they are 
> created per branch, so that will reduce merge conflicts a bit.
> 
> I understand that it was better to ask at the first time when [1] was on 
> review, should we have HEAD files and merge conflicts or not, but I want to 
> ask it now: Should I continue work on [3] or we are not expecting to have 
> problems with big merge queues?
> 
> 
> [1] - https://review.openstack.org/#/c/227319/
> [2] - 
> https://github.com/openstack/neutron/commit/36d85f831ae8eb21383806261bfc4c3d53dd1929
> [3] - https://review.openstack.org/#/c/232607/

I think it’s worth describing merge scenarios with and without HEAD files.

1. both patches in merge queue

Currently (no HEAD files), if two patches that touch the same alembic branch 
head are pushed into the gate:

- first patch passes the gate;
- second patch fails on pep8, and moved out of the merge queue; other jobs 
continue to run to report the failure back to Gerrit;
- if a patch above the first patch reset the queue, then both patches are 
re-added into merge queue; again, the second patch fails on pep8 quickly and is 
moved out of the queue;
- the second patch author is notified about the failure once the first patch is 
merged and all jobs for the second patch are complete (at least pep8 is failed).

With HEAD files,
- first patch passes the gate;
- second patch does not get into the queue until first patch merges, or fails 
(because there are now git conflicts);
- if a patch above the first patch reset the queue, only first patch is 
re-added into the merge queue; the second patch waits until the first patch 
merges or fails to merge; in the former case, zuul reports git conflict back to 
the author of the second patch; in the latter case, the second patch is added 
into the merge queue and merges if all goes well;
- meaning, the second patch author is notified about the failure once the first 
patch is merged.

I see the following speed-ups with HEAD files:
- there is no need to wait for jobs of the second patch to complete before we 
notify the author about the problem;
- queue is not reset by second patch failures after each gate reset; since pep8 
job fails quick, it’s ~5 mins per reset (which should not occur frequently);

I see the following speed-up without HEAD files:
- if first patch fails to merge, the second patch gets into the merge queue at 
the point were it was pushed into the gate, not at the end of the list at the 
moment the first patch failed.

2. one patch in merge queue

Currently, when a patch is merged in the gate, all other patches are tested on 
git conflicts, but since there are no conflicts due to HEAD files (there are no 
such things now), authors are not notified about the issue. Still, the patch 
can proceed with review (there is no -1 vote from CI which scares a lot of 
people), and if pushed into gate, will immediately fail. Then author will need 
to rebase, and reviewers repeat the push into the gate.

With HEAD files, we would immediately detect git conflict and report to the 
author about the issue, setting -1 vote for CI. Then the author updates the 
patch, gets fresh vote and hopes that other reviewers get back to his patch.

In that scenario, it’s not clear what’s better for review velocity. My 
experience shows that git conflicts and -1 CI votes slow down reviews, and if a 
patch was in the gate before, it should be easy to respin it for a small change 
in head and push. On the contrary, git conflicts are very reviewer time 
consuming, and scare reviewers away.

3. Another tiny benefit not to have git conflicts on HEAD files is that 
reviewers can distinguish legitimate git conflicts from branching failures, and 
apply appropriate review attention based on the nature of the failure. We also 
get fresh CI run for the patch (except for pep8 job that is doomed to fail 
until rebase).

There are pros and cons for both approaches, but overall, I don’t see how the 
former justify having HEAD files and the complexity to handle them in code and 
in file system.

Ihar

signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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/openst

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

2015-10-09 Thread Russell Bryant

On 10/09/2015 05:42 AM, Thierry Carrez wrote:
> Hello everyone,
> 
> OpenStack has become quite big, and it's easier than ever to feel lost,
> to feel like nothing is really happening. It's more difficult than ever
> to feel part of a single community, and to celebrate little successes
> and progress.
> 
> In a (small) effort to help with that, I suggested making it easier to
> record little moments of joy and small success bits. Those are usually
> not worth the effort of a blog post or a new mailing-list thread, but
> they show that our community makes progress *every day*.
> 
> So whenever you feel like you made progress, or had a little success in
> your OpenStack adventures, or have some joyful moment to share, just
> throw the following message on your local IRC channel:
> 
> #success [Your message here]
> 
> The openstackstatus bot will take that and record it on this wiki page:
> 
> https://wiki.openstack.org/wiki/Successes
> 
> We'll add a few of those every week to the weekly newsletter (as part of
> the developer digest that we reecently added there).
> 
> Caveats: Obviously that only works on channels where openstackstatus is
> present (the official OpenStack IRC channels), and we may remove entries
> that are off-topic or spam.
> 
> So... please use #success liberally and record lttle everyday OpenStack
> successes. Share the joy and make the OpenStack community a happy place.
> 

This is *really* cool.  I'm excited to use this and see all the things
others record.  Thanks!!

-- 
Russell Bryant

__
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] [all] Recording little everyday OpenStack successes

> On 09 Oct 2015, at 15:46, Jeremy Stanley  wrote:
> 
> On 2015-10-09 13:51:39 +0200 (+0200), Ihar Hrachyshka wrote:
> [...]
>> Another IRC service that I find useful to encourage collaboration
>> in teams is a karma bot. Something that would calculate
>> ++ messages in tracked channels. Having such a
>> lightweight and visible way to tell ‘thank you’ to a contributor
>> would be great. Do we have plans to implement it in infra?
> 
> If you write it! An easy compromise would be to just add similar
> support like "#thanks ttx for your awesome successbot
> implementation!" and interleave those into the same Successes
> article or direct them to a separate Karma article. If you want an
> interface to tabulate/summarize #thanks calls though, that would
> likely need some additional service.


There are already multiple karmabot implementations that could be reused, like 
https://github.com/chromakode/karmabot

Can we just adopt one of those?

Ihar


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] Requests + urllib3 + distro packages

2015-10-09 Thread Cory Benfield

> On 9 Oct 2015, at 14:40, William M Edmonds  wrote:
> 
> Cory Benfield  writes:
> > > The problem that occurs is the result of a few interacting things:
> > >  - requests has very very specific versions of urllib3 it works with.
> > > So specific they aren't always released yet.
> >
> > This should no longer be true. Our downstream redistributors pointedout to 
> > us
> > that this  was making their lives harder than they needed to be, so it's now
> > our policy to only  update to actual release versions of urllib3.
> 
> That's great... except that I'm confused as to why requests would continue to 
> repackage urllib3 if that's the case. Why not just prereq the version of 
> urllib3 that it needs? I thought the one and only answer to that question had 
> been so that requests could package non-standard versions.
> 

That is not and was never the only reason for vendoring urllib3. However, and I 
cannot stress this enough, the decision to vendor urllib3 is *not going to be 
changed on this thread*. If and when it changes, it will be by consensus 
decision from the requests maintenance team, which we do not have at this time.

Further, as I pointed out to Donald Stufft on IRC, if requests unbundled 
urllib3 *today* that would not fix the problem. The reason is that we’d specify 
our urllib3 dependency as: urllib3>=1.12,<1.13. This dependency note would 
still cause exactly the problem observed in this thread.

As you correctly identify in your subsequent email, William, the core problem 
is mixing of packages from distributions and PyPI. This happens with any tool 
with external dependencies: if you subsequently install a different version of 
a dependency using a packaging tool that is not aware of some of the dependency 
tree, it is entirely plausible that an incompatible version will be installed. 
It’s not hard to trigger this kind of thing on Ubuntu. IMO, what OpenStack 
needs is a decision about where it’s getting its packages from, and then to 
refuse to mix the two.

Cory

signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [all] Recording little everyday OpenStack successes

On 2015-10-09 15:53:17 +0200 (+0200), Ihar Hrachyshka wrote:
[...]
> There are already multiple karmabot implementations that could be
> reused, like https://github.com/chromakode/karmabot
> 
> Can we just adopt one of those?

Perhaps, though we're trying to reduce rather than increase the
number of individual IRC bots we're managing. Ultimately I'm
interested in seeing us collapse our current family (gerritbot,
statusbot, meetbot) into one codebase/framework to further reduce
the maintenance burden, but haven't found interested parties yet to
contribute the coding effort.
-- 
Jeremy Stanley

__
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] [kolla] Backport policy for Liberty

2015-10-09 Thread Sam Yaple

On Thu, Oct 8, 2015 at 2:47 PM, Steven Dake (stdake) 
wrote:

> Kolla operators and developers,
>
> The general consensus of the Core Reviewer team for Kolla is that we
> should embrace a liberal backport policy for the Liberty release.  An
> example of liberal -> We add a new server service to Ansible, we would
> backport the feature to liberty.  This is in breaking with the typical
> OpenStack backports policy.  It also creates a whole bunch more work and
> has potential to introduce regressions in the Liberty release.
>
> Given these realities I want to put on hold any liberal backporting until
> after Summit.  I will schedule a fishbowl session for a backport policy
> discussion where we will decide as a community what type of backport policy
> we want.  The delivery required before we introduce any liberal backporting
> policy then should be a description of that backport policy discussion at
> Summit distilled into a RST file in our git repository.
>
> If you have any questions, comments, or concerns, please chime in on the
> thread.
>
> Regards
> -steve
>
> __
> 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
>
>
I am in favor of a very liberal backport policy. We have the potential to
have very little code difference between N, N-1, and N-2 releases while
still deploying the different versions of OpenStack. However, I recognize
is a big undertaking to backport all things, not to mention the testing
involved.

I would like to see two things before we truly embrace a liberal policy.
The first is better testing. A true gate that does upgrades and potentially
multinode (at least from a network perspective). The second thing is a bot
or automation of some kind to automatically propose non-conflicting patches
to the stable branches if they include the 'backport: xyz' tag in the
commit message. Cores would still need to confirm these changes with the
normal review process and could easily abandon them, but that would remove
alot of overhead of performing the actual backport.

Since Kolla simply deploys OpenStack, it is alot closer to a client or a
library than it is to Nova or Neutron. And given its mission maybe it
should break from the "typical OpenStack backports policy" so we can give a
consistent deployment experience across all stable and supported version of
OpenStack at any given time.

Those are my thoughts on the matter at least. I look forward to some
conversations about this in Tokyo.

Sam Yaple
__
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] Requests + urllib3 + distro packages

On 2015-10-09 14:58:36 +0100 (+0100), Cory Benfield wrote:
[...]
> IMO, what OpenStack needs is a decision about where it’s getting
> its packages from, and then to refuse to mix the two.

I have yet to find a Python-based operating system installable in
whole via pip. There will always be _at_least_some_ packages you
install from your operating system's package management. What you
seem to be missing is that Linux distros are now shipping base
images which include their python-requests and python-urllib3
packages already pre-installed as dependencies of Python-based tools
they deem important to their users.

To work around this in our test infrastructure we're effectively
abandoning all hope of using distro-provided server images, and
building our own from scratch to avoid the possibility that they may
bring with them their own versions of any Python libraries
whatsoever. We're at the point where we're basically maintaining our
own derivative Linux distributions. The web of dependencies in
OpenStack has reached a level of complexity where it's guaranteed to
overlap with just about any pre-installed python-.* packages in a
distro-supplied image.

We're only now reaching the point where our Python dependencies
actually all function within the context of a virtualenv without
needing system-site-packages contamination, so the next logical step
is probably to see if virtualenv isolation is possible for
frameworks like DevStack (the QA team may already be trying to
figure that out, I'm not sure).
-- 
Jeremy Stanley

__
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] [all] service catalog: TNG

2015-10-09 Thread Sean Dague

It looks like some great conversation got going on the service catalog
standardization spec / discussion at the last cross project meeting.
Sorry I wasn't there to participate.

A lot of that ended up in here (which was an ether pad stevemar and I
started working on the other day) -
https://etherpad.openstack.org/p/mitaka-service-catalog which is great.

A couple of things that would make this more useful:

1) if you are commenting, please (ircnick) your comments. It's not easy
to always track down folks later if the comment was not understood.

2) please provide link to code when explaining a point. Github supports
the ability to very nicely link to (and highlight) a range of code by a
stable object ref. For instance -
https://github.com/openstack/nova/blob/2dc2153c289c9d5d7e9827a4908b0ca61d87dabb/nova/context.py#L126-L132

That will make comments about X does Y, or Z can't do W, more clear
because we'll all be looking at the same chunk of code and start to
build more shared context here. One of the reasons this has been long
and difficult is that we're missing a lot of that shared context between
projects. Reassembling that by reading each other's relevant code will
go a long way to understanding the whole picture.

Lastly, I think it's pretty clear we probably need a dedicated workgroup
meeting to keep this ball rolling, come to a reasonable plan that
doesn't break any existing deployed code, but lets us get to a better
world in a few cycles. annegentle, stevemar, and I have been pushing on
that ball so far, however I'd like to know who else is willing to commit
a chunk of time over this cycle to this. Once we know that we can try to
figure out when a reasonable weekly meeting point would be.

Thanks,

-Sean

--
Sean Dague
http://dague.net

__
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] Requests + urllib3 + distro packages

2015-10-09 Thread Joshua Harlow

For those who are interested in more of the historical aspect around this,

https://github.com/kennethreitz/requests/issues/1811

https://github.com/kennethreitz/requests/pull/1812

My own thoughts are varied here, I get the angle of vendoring, but I don't get 
the resistance to unvendoring it (which it seems like quite a few people have 
asked for); if many people want it unvendored then this just ends up creating a 
bad taste in the mouth of many people (this is a bad thing to have happen in 
opensource and is how forks and such get created...).

But as was stated,

The decision to stop vendoring it likely won't be made here anyway ;)

From: c...@lukasa.co.uk
Date: Fri, 9 Oct 2015 14:58:36 +0100
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Requests + urllib3 + distro packages

> On 9 Oct 2015, at 14:40, William M Edmonds  wrote:
> 
> Cory Benfield  writes:
>>> The problem that occurs is the result of a few interacting things:
>>>  - requests has very very specific versions of urllib3 it works with.
>>> So specific they aren't always released yet.
>>
>> This should no longer be true. Our downstream redistributors pointedout to us
>> that this  was making their lives harder than they needed to be, so it's now
>> our policy to only  update to actual release versions of urllib3.
> 
> That's great... except that I'm confused as to why requests would continue to 
> repackage urllib3 if that's the case. Why not just prereq the version of 
> urllib3 that it needs? I thought the one and only answer to that question had 
> been so that requests could package non-standard versions.
> 

That is not and was never the only reason for vendoring urllib3. However, and I 
cannot stress this enough, the decision to vendor urllib3 is *not going to be 
changed on this thread*. If and when it changes, it will be by consensus 
decision from the requests maintenance team, which we do not have at this time.

Further, as I pointed out to Donald Stufft on IRC, if requests unbundled 
urllib3 *today* that would not fix the problem. The reason is that we’d specify 
our urllib3 dependency as: urllib3>=1.12,   
 __
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] [Horizon] Suggestions for handling new panels and refactors in the future

2015-10-09 Thread Douglas Fish

I have two suggestions for handling both new panels and refactoring existing panels that I think could benefit us in the future:
1) When we are creating a panel that's a major refactor of an existing it should be a new separate panel, not a direct code replacement of the existing panel
2) New panels (include the refactors of existing panels) should be developed in an out of tree gerrit repository.
Why make refactors a separate panel?
I was taken a bit off guard after we merged the Network Topology->Curvature improvement: this was a surprise to some people outside of the Horizon community (though it had been discussed within Horizon for as long as I've been on the project). In retrospect, I think it would have been better to keep both the old Network Topology and new curvature based topology in our Horizon codebase. Doing so would have allowed operators to perform A-B/ Red-Black testing if they weren't immediately convinced of the awesomeness of the panel. It also would have allowed anyone with a customization of the Network Topology panel to have some time to configure their Horizon instance to continue to use the Legacy panel while they updated their customization to work with the new panel.
Perhaps we should treat panels more like an API element and take them through a deprecation cycle before removing them completely. Giving time for customizers to update their code is going to be especially important as we build angular replacements for python panels. While we have much better plugin support for angular there is still a learning curve for those developers.
Why build refactors and new panels out of tree?
First off, it appears to me trying to build new panels in tree has been fairly painful. I've seen big long lived patches pushed along without being merged. It's quite acceptable and expected to quickly merge half-complete patches into a brand new repository - but you can't behave that way working in tree in Horizon. Horizon needs to be kept production/operator ready. External repositories do not. Merging code quickly can ease collaboration and avoid this kind of long lived patch set.
Secondly, keeping new panels/plugins in a separate repository decentralizes decisions about which panels are "ready" and which aren't. If one group feels a plugin is "ready" they can make it their default version of the panel, and perhaps put resources toward translating it. If we develop these panels in-tree we need to make a common decision about what "ready" means - and once it's in everyone who wants a translated Horizon will need to translate it.
Finally, I believe developing new panels out of tree will help improve our plugin support in Horizon. It's this whole "eating your own dog food" idea. As soon as we start using our own Horizon plugin mechanism for our own development we are going to become aware of it's shortcomings (like quotas) and will be sufficiently motivated to fix them.
Looking forward to further discussion and other ideas on this!
Doug Fish

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

2015-10-09 Thread John Griffith

On Fri, Oct 9, 2015 at 3:42 AM, Thierry Carrez 
wrote:

> Hello everyone,
>
> OpenStack has become quite big, and it's easier than ever to feel lost,
> to feel like nothing is really happening. It's more difficult than ever
> to feel part of a single community, and to celebrate little successes
> and progress.
>
> In a (small) effort to help with that, I suggested making it easier to
> record little moments of joy and small success bits. Those are usually
> not worth the effort of a blog post or a new mailing-list thread, but
> they show that our community makes progress *every day*.
>
> So whenever you feel like you made progress, or had a little success in
> your OpenStack adventures, or have some joyful moment to share, just
> throw the following message on your local IRC channel:
>
> #success [Your message here]
>
> The openstackstatus bot will take that and record it on this wiki page:
>
> https://wiki.openstack.org/wiki/Successes
>
> We'll add a few of those every week to the weekly newsletter (as part of
> the developer digest that we reecently added there).
>
> Caveats: Obviously that only works on channels where openstackstatus is
> present (the official OpenStack IRC channels), and we may remove entries
> that are off-topic or spam.
>
> So... please use #success liberally and record lttle everyday OpenStack
> successes. Share the joy and make the OpenStack community a happy place.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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
>

Great idea Thierry, great to promote some positive things!  Thanks for
putting this together.
__
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] [all] service catalog: TNG

2015-10-09 Thread Dean Troyer

On Fri, Oct 9, 2015 at 9:39 AM, Sean Dague  wrote:

> Lastly, I think it's pretty clear we probably need a dedicated workgroup
> meeting to keep this ball rolling, come to a reasonable plan that
> doesn't break any existing deployed code, but lets us get to a better
> world in a few cycles. annegentle, stevemar, and I have been pushing on
> that ball so far, however I'd like to know who else is willing to commit
> a chunk of time over this cycle to this. Once we know that we can try to
> figure out when a reasonable weekly meeting point would be.
>

Count me in...

dt

-- 

Dean Troyer
dtro...@gmail.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

Re: [openstack-dev] We should move strutils.mask_password back into oslo-incubator

2015-10-09 Thread Matt Riedemann




On 10/9/2015 1:49 AM, Paul Carlton wrote:


On 08/10/15 16:49, Doug Hellmann wrote:

Excerpts from Matt Riedemann's message of 2015-10-07 14:38:07 -0500:

Here's why:

https://review.openstack.org/#/c/220622/

That's marked as fixing an OSSA which means we'll have to backport the
fix in nova but it depends on a change to strutils.mask_password in
oslo.utils, which required a release and a minimum version bump in
global-requirements.

To backport the change in nova, we either have to:

1. Copy mask_password out of oslo.utils and add it to nova in the
backport or,

2. Backport the oslo.utils change to a stable branch, release it as a
patch release, bump minimum required version in stable g-r and then
backport the nova change and depend on the backported oslo.utils stable
release - which also makes it a dependent library version bump for any
packagers/distros that have already frozen libraries for their stable
releases, which is kind of not fun.

Bug fix releases do not generally require a minimum version bump. The
API hasn't changed, and there's nothing new in the library in this case,
so it's a documentation issue to ensure that users update to the new
release. All we should need to do is backport the fix to the appropriate
branch of oslo.utils and release a new version from that branch that is
compatible with the same branch of nova.

Doug


So I'm thinking this is one of those things that should ultimately live
in oslo-incubator so it can live in the respective projects. If
mask_password were in oslo-incubator, we'd have just fixed and
backported it there and then synced to nova on master and stable
branches, no dependent library version bumps required.

Plus I miss the good old days of reviewing oslo-incubator
syncs...(joking of course).


__

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

I've been following this discussion, is there now a consensus on the way
forward?

My understanding is that Doug is suggesting back porting my oslo.utils
change to the stable juno and kilo branches?



It means you'll have to backport the oslo.utils change to each stable 
branch that you also backport the nova change to, which probably goes 
back to stable/juno (so liberty->kilo->juno backports in both projects).


--

Thanks,

Matt Riedemann


__
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] Requests + urllib3 + distro packages

2015-10-09 Thread Cory Benfield

> On 9 Oct 2015, at 15:18, Jeremy Stanley  wrote:
> 
> On 2015-10-09 14:58:36 +0100 (+0100), Cory Benfield wrote:
> [...]
>> IMO, what OpenStack needs is a decision about where it’s getting
>> its packages from, and then to refuse to mix the two.
> 
> I have yet to find a Python-based operating system installable in
> whole via pip. There will always be _at_least_some_ packages you
> install from your operating system's package management. What you
> seem to be missing is that Linux distros are now shipping base
> images which include their python-requests and python-urllib3
> packages already pre-installed as dependencies of Python-based tools
> they deem important to their users.
> 

Yeah, this has been an ongoing problem.

For my part, Donald Stufft has informed me that if the distribution-provided 
requests package has the appropriate install_requires field in its setup.py, 
pip will respect that dependency. Given that requests has recently switched to 
not providing mid-cycle urllib3 versions, it should be entirely possible for 
downstream redistributors in Debian/Fedora to put that metadata into their 
packages when they unbundle requests. I’m chasing up with our downstream 
redistributors right now to ask them to start doing that.

This should resolve the problem for systems where requests 2.7.0 or higher are 
being used. In other systems, this problem still exists and cannot be fixed by 
requests directly.

Cory

signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [all] service catalog: TNG

2015-10-09 Thread David Lyle

I'm in too.

David

On Fri, Oct 9, 2015 at 8:51 AM, Dean Troyer  wrote:
> On Fri, Oct 9, 2015 at 9:39 AM, Sean Dague  wrote:
>>
>> Lastly, I think it's pretty clear we probably need a dedicated workgroup
>> meeting to keep this ball rolling, come to a reasonable plan that
>> doesn't break any existing deployed code, but lets us get to a better
>> world in a few cycles. annegentle, stevemar, and I have been pushing on
>> that ball so far, however I'd like to know who else is willing to commit
>> a chunk of time over this cycle to this. Once we know that we can try to
>> figure out when a reasonable weekly meeting point would be.
>
>
> Count me in...
>
> dt
>
> --
>
> Dean Troyer
> dtro...@gmail.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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

2015-10-09 Thread Shamail



> On Oct 9, 2015, at 10:49 AM, John Griffith  wrote:
> 
> Great idea Thierry, great to promote some positive things!  Thanks for 
> putting this together.

+1
Great indeed... thanks Thierry.

Regards,
Shamail 
__
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] [Neutron] L2 gateway project

2015-10-09 Thread Gary Kotton

Hi,
Who will be creating the stable/liberty branch?
Thanks
Gary
__
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] [all] service catalog: TNG


On 10/09/2015 11:07 AM, David Lyle wrote:

I'm in too.


Yes please.


On Fri, Oct 9, 2015 at 8:51 AM, Dean Troyer  wrote:

On Fri, Oct 9, 2015 at 9:39 AM, Sean Dague  wrote:


Lastly, I think it's pretty clear we probably need a dedicated workgroup
meeting to keep this ball rolling, come to a reasonable plan that
doesn't break any existing deployed code, but lets us get to a better
world in a few cycles. annegentle, stevemar, and I have been pushing on
that ball so far, however I'd like to know who else is willing to commit
a chunk of time over this cycle to this. Once we know that we can try to
figure out when a reasonable weekly meeting point would be.



Count me in...

dt

--

Dean Troyer
dtro...@gmail.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
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] [infra] Try to introduce RFC mechanism to CI.

2015-10-09 Thread Znoinski, Waldemar

 >-Original Message-
 >From: Jeremy Stanley [mailto:fu...@yuggoth.org]
 >Sent: Friday, October 9, 2015 1:17 PM
 >To: OpenStack Development Mailing List (not for usage questions)
 >
 >Subject: Re: [openstack-dev] [infra] Try to introduce RFC mechanism to CI.
 >
 >On 2015-10-09 18:06:55 +0800 (+0800), Tang Chen wrote:
 >[...]
 >> It is just a waste of resource if reviewers are discussing about where
 >> this function should be, or what the function should be named. After
 >> all these details are agreed on, run the CI.
 >[...]
 
[WZ] I'm maintaining 2 3rdparty CIs here, for Nova and Neutron each, and to me 
there's no big difference in maintaining/supporting a CI that runs 5 or 150 
times a day. The only difference may be in resources required to keep up with 
the Gerrit stream. In my opinion (3rdparty) CIs should help early-discover the 
problems so should run on all patchsets as they appear - that's their main 
purpose to me.

 >As one of the people maintaining the upstream CI and helping coordinate our
 >resources/quotas, I don't see that providing early test feedback is a waste.
 >We're steadily increasing the instance quotas available to us, so check
 >pipeline utilization should continue to become less and less of a concern
 >anyway.
 >
 >For a change which is still under debate, feel free to simply ignore test 
 >results
 >until you get it to a point where you see them start to become relevant.
 >--
 >Jeremy Stanley
 >
 >__
 >
 >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
--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.



__
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] [all] service catalog: TNG

2015-10-09 Thread Shamail



> On Oct 9, 2015, at 10:39 AM, Sean Dague  wrote:
> 
> It looks like some great conversation got going on the service catalog
> standardization spec / discussion at the last cross project meeting.
> Sorry I wasn't there to participate.
> 
Apologize if this is a question that has already been address but why can't we 
just leverage something like consul.io?

> A lot of that ended up in here (which was an ether pad stevemar and I
> started working on the other day) -
> https://etherpad.openstack.org/p/mitaka-service-catalog which is great.
I didn't see anything immediately in the etherpad that couldn't be covered with 
the tool mentioned above.  It is open-source so we could always try to 
contribute there if we need something extra (written in golang though).
> 
> A couple of things that would make this more useful:
> 
> 1) if you are commenting, please (ircnick) your comments. It's not easy
> to always track down folks later if the comment was not understood.
> 
> 2) please provide link to code when explaining a point. Github supports
> the ability to very nicely link to (and highlight) a range of code by a
> stable object ref. For instance -
> https://github.com/openstack/nova/blob/2dc2153c289c9d5d7e9827a4908b0ca61d87dabb/nova/context.py#L126-L132
> 
> That will make comments about X does Y, or Z can't do W, more clear
> because we'll all be looking at the same chunk of code and start to
> build more shared context here. One of the reasons this has been long
> and difficult is that we're missing a lot of that shared context between
> projects. Reassembling that by reading each other's relevant code will
> go a long way to understanding the whole picture.
> 
> 
> Lastly, I think it's pretty clear we probably need a dedicated workgroup
> meeting to keep this ball rolling, come to a reasonable plan that
> doesn't break any existing deployed code, but lets us get to a better
> world in a few cycles. annegentle, stevemar, and I have been pushing on
> that ball so far, however I'd like to know who else is willing to commit
> a chunk of time over this cycle to this. Once we know that we can try to
> figure out when a reasonable weekly meeting point would be.
> 
> Thanks,
> 
>-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __
> 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] [all] service catalog: TNG

On 10/09/2015 10:39 AM, Sean Dague wrote:

It looks like some great conversation got going on the service catalog
standardization spec / discussion at the last cross project meeting.
Sorry I wasn't there to participate.

Just so folks know, the collection of existing service catalogs has been
updated:

https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog

It now includes a new and correct catalog for Rackspace Private (the
previous entry was just a copy of Rackspace Public) as well as entries
for every public cloud I have an account on.

Hopefully that is useful information for folks looking at this.

A lot of that ended up in here (which was an ether pad stevemar and I
started working on the other day) -
https://etherpad.openstack.org/p/mitaka-service-catalog which is great.

A couple of things that would make this more useful:

1) if you are commenting, please (ircnick) your comments. It's not easy
to always track down folks later if the comment was not understood.

Thanks,

-Sean

Re: [openstack-dev] [all] jobs that make break when we remove Devstack extras.d in 10 weeks


On 10/09/2015 12:58 PM, Dmitry Tantsur wrote:

On 10/09/2015 12:35 PM, Sean Dague wrote:

 From now until the removal of devstack extras.d support I'm going to
send a weekly email of jobs that may break. A warning was added that we
can track in logstash.

Here are the top 25 jobs (by volume) that are currently tripping the
warning:

gate-murano-devstack-dsvm
gate-cue-integration-dsvm-rabbitmq
gate-murano-congress-devstack-dsvm
gate-solum-devstack-dsvm-centos7
gate-rally-dsvm-murano-task
gate-congress-dsvm-api
gate-tempest-dsvm-ironic-agent_ssh
gate-solum-devstack-dsvm
gate-tempest-dsvm-ironic-pxe_ipa-nv
gate-ironic-inspector-dsvm-nv
gate-tempest-dsvm-ironic-pxe_ssh
gate-tempest-dsvm-ironic-parallel-nv
gate-tempest-dsvm-ironic-pxe_ipa
gate-designate-dsvm-powerdns
gate-python-barbicanclient-devstack-dsvm
gate-tempest-dsvm-ironic-pxe_ssh-postgres
gate-rally-dsvm-designate-designate
gate-tempest-dsvm-ironic-pxe_ssh-dib
gate-tempest-dsvm-ironic-agent_ssh-src
gate-tempest-dsvm-ironic-pxe_ipa-src
gate-muranoclient-dsvm-functional
gate-designate-dsvm-bind9
gate-tempest-dsvm-python-ironicclient-src
gate-python-ironic-inspector-client-dsvm
gate-tempest-dsvm-ironic-lib-src-nv

(You can view this query with http://goo.gl/6p8lvn)

The ironic jobs are surprising, as something is crudding up extras.d
with a file named 23, which isn't currently run. Eventual removal of
that directory is going to potentially make those jobs fail, so someone
more familiar with it should look into it.


Thanks for noticing, looking now.


As I'm leaving for the weekend, I'll post my findings here.

I was not able to spot what writes these files (in my case it was named 
33). I also was not able to reproduce it on my regular devstack environment.


I've posted a temporary patch https://review.openstack.org/#/c/233017/ 
so that we're able to track where and when these files appear. Right now 
I only understood that they really appear during the devstack run, not 
earlier.






This is not guarunteed to be a complete list, but as jobs are removed /
fixed we should end up with other less frequently run jobs popping up in
future weeks.

-Sean




__
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] [all] Recording little everyday OpenStack successes

2015-10-09 Thread Kyle Mestery

On Fri, Oct 9, 2015 at 8:52 AM, Russell Bryant  wrote:

> On 10/09/2015 05:42 AM, Thierry Carrez wrote:
> > Hello everyone,
> >
> > OpenStack has become quite big, and it's easier than ever to feel lost,
> > to feel like nothing is really happening. It's more difficult than ever
> > to feel part of a single community, and to celebrate little successes
> > and progress.
> >
> > In a (small) effort to help with that, I suggested making it easier to
> > record little moments of joy and small success bits. Those are usually
> > not worth the effort of a blog post or a new mailing-list thread, but
> > they show that our community makes progress *every day*.
> >
> > So whenever you feel like you made progress, or had a little success in
> > your OpenStack adventures, or have some joyful moment to share, just
> > throw the following message on your local IRC channel:
> >
> > #success [Your message here]
> >
> > The openstackstatus bot will take that and record it on this wiki page:
> >
> > https://wiki.openstack.org/wiki/Successes
> >
> > We'll add a few of those every week to the weekly newsletter (as part of
> > the developer digest that we reecently added there).
> >
> > Caveats: Obviously that only works on channels where openstackstatus is
> > present (the official OpenStack IRC channels), and we may remove entries
> > that are off-topic or spam.
> >
> > So... please use #success liberally and record lttle everyday OpenStack
> > successes. Share the joy and make the OpenStack community a happy place.
> >
>
> This is *really* cool.  I'm excited to use this and see all the things
> others record.  Thanks!!
>
>
Indeed, sometimes it's easy to get lost in the bike shedding, this is a
good way for everyone to remember the little successes that people are
having. After all, this project is composed of actual people, it's good to
highlight the little things we each consider a success. Well done!

Thanks,
Kyle


> --
> Russell Bryant
>
> __
> 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] [all] Recording little everyday OpenStack successes

2015-10-09 Thread Carl Baldwin

+1 Great idea!

On Fri, Oct 9, 2015 at 3:42 AM, Thierry Carrez  wrote:
> Hello everyone,
>
> OpenStack has become quite big, and it's easier than ever to feel lost,
> to feel like nothing is really happening. It's more difficult than ever
> to feel part of a single community, and to celebrate little successes
> and progress.
>
> In a (small) effort to help with that, I suggested making it easier to
> record little moments of joy and small success bits. Those are usually
> not worth the effort of a blog post or a new mailing-list thread, but
> they show that our community makes progress *every day*.
>
> So whenever you feel like you made progress, or had a little success in
> your OpenStack adventures, or have some joyful moment to share, just
> throw the following message on your local IRC channel:
>
> #success [Your message here]
>
> The openstackstatus bot will take that and record it on this wiki page:
>
> https://wiki.openstack.org/wiki/Successes
>
> We'll add a few of those every week to the weekly newsletter (as part of
> the developer digest that we reecently added there).
>
> Caveats: Obviously that only works on channels where openstackstatus is
> present (the official OpenStack IRC channels), and we may remove entries
> that are off-topic or spam.
>
> So... please use #success liberally and record lttle everyday OpenStack
> successes. Share the joy and make the OpenStack community a happy place.
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [all] Recording little everyday OpenStack successes

2015-10-09 Thread Nick Chase

This is AWESOME!  And I've already found useful resources on the list of 
successes.  Beautiful job, and fantastic idea!


  Nick


On 10/09/2015 05:42 AM, Thierry Carrez wrote:
> Hello everyone,
>
> OpenStack has become quite big, and it's easier than ever to
feel lost,
> to feel like nothing is really happening. It's more difficult
than ever
> to feel part of a single community, and to celebrate little
successes
> and progress.
>
> In a (small) effort to help with that, I suggested making it
easier to
> record little moments of joy and small success bits. Those are
usually
> not worth the effort of a blog post or a new mailing-list
thread, but
> they show that our community makes progress *every day*.
>
> So whenever you feel like you made progress, or had a little
success in
> your OpenStack adventures, or have some joyful moment to share, just
> throw the following message on your local IRC channel:
>
> #success [Your message here]
>
> The openstackstatus bot will take that and record it on this
wiki page:
>
> https://wiki.openstack.org/wiki/Successes
>
> We'll add a few of those every week to the weekly newsletter (as
part of
> the developer digest that we reecently added there).
>
> Caveats: Obviously that only works on channels where
openstackstatus is
> present (the official OpenStack IRC channels), and we may remove
entries
> that are off-topic or spam.
>
> So... please use #success liberally and record lttle everyday
OpenStack
> successes. Share the joy and make the OpenStack community a
happy place.
>



__
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] [all] service catalog: TNG

On 10/09/2015 11:21 AM, Shamail wrote:

On Oct 9, 2015, at 10:39 AM, Sean Dague wrote:

It looks like some great conversation got going on the service catalog
standardization spec / discussion at the last cross project meeting.
Sorry I wasn't there to participate.

Apologize if this is a question that has already been address but why can't we
just leverage something like consul.io?

It's a good question and there have actually been some discussions about
leveraging it on the backend. However, even if we did, we'd still need
keystone to provide the multi-tenancy view on the subject. consul wasn't
designed (quite correctly I think) to be a user-facing service for 50k
users.

I think it would be an excellent backend.

A lot of that ended up in here (which was an ether pad stevemar and I
started working on the other day) -
https://etherpad.openstack.org/p/mitaka-service-catalog which is great.

I didn't see anything immediately in the etherpad that couldn't be covered with
the tool mentioned above. It is open-source so we could always try to
contribute there if we need something extra (written in golang though).

A couple of things that would make this more useful:

1) if you are commenting, please (ircnick) your comments. It's not easy
to always track down folks later if the comment was not understood.

Thanks,

-Sean

--
Sean Dague
http://dague.net

Re: [openstack-dev] [Neutron] L2 gateway project

2015-10-09 Thread Kyle Mestery

On Fri, Oct 9, 2015 at 10:13 AM, Gary Kotton  wrote:

> Hi,
> Who will be creating the stable/liberty branch?
> Thanks
> Gary
>
>
I'll be doing this once someone from the L2GW team lets me know a commit
SHA to create it from.

Thanks,
Kyle


> __
> 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] [Heat] mox to mock migration

2015-10-09 Thread Steven Hardy

On Fri, Oct 09, 2015 at 09:06:57AM -0400, Jay Dobies wrote:
> I forget where we left things at the last meeting with regard to whether or
> not there should be a blueprint on this. I was going to work on some during
> some downtime but I wanted to make sure I wasn't overlapping with what
> others may be converting (it's more time consuming than I anticipated).
> 
> Any thoughts on how to track it?

I'd probably suggest raising either a bug or a blueprint (not spec), then
link from that to an etherpad where you can track all the tests requiring
rework, and who's working on them.

"it's more time consuming than I anticipated" is pretty much my default
response for anything to do with heat unit tests btw, good luck! :)

Steve

__
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] [congress] Symantec's security group management policies

2015-10-09 Thread Shiv Haris

Hi Su,

This looks very good.

Will it be possible to put your usecase as part of the Usecase VM.
Have you tried it out on the Usecase VM that I published earlier. I can help if 
you get stuck.

LMK,

Thanks,

-Shiv


From: Su Zhang [mailto:westlif...@gmail.com]
Sent: Thursday, October 08, 2015 1:23 PM
To: openstack-dev
Subject: [openstack-dev] [congress] Symantec's security group management 
policies

Hello,

I've implemented a set of security group management policies and already put 
them into our usecase doc.
Let me know if you guys have any comments. My policies is called "Security 
Group Management "
You can find the use case doc at: 
https://docs.google.com/document/d/1ExDmT06vDZjzOPePYBqojMRfXodvsk0R8nRkX-zrkSw/edit#heading=h.6z1ggtfrzg3n

Thanks,

--
Su Zhang
Senior Software Engineer
Symantec Corporation
__
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] [all] service catalog: TNG

2015-10-09 Thread Adam Young

On 10/09/2015 12:28 PM, Monty Taylor wrote:

On 10/09/2015 11:21 AM, Shamail wrote:

On Oct 9, 2015, at 10:39 AM, Sean Dague wrote:

It looks like some great conversation got going on the service catalog
standardization spec / discussion at the last cross project meeting.
Sorry I wasn't there to participate.

Apologize if this is a question that has already been address but why
can't we just leverage something like consul.io?

It's a good question and there have actually been some discussions
about leveraging it on the backend. However, even if we did, we'd
still need keystone to provide the multi-tenancy view on the subject.
consul wasn't designed (quite correctly I think) to be a user-facing
service for 50k users.

I think it would be an excellent backend.

The better question is, "Why are we not using DNS for the service catalog?"

Right now, we have the aspect of "project filtering of endpoints" which
means that a token does not need to have every endpoint for a specified
service. If we were to use DNS, how would that map to the existing
functionality.

Can we make better use of regions to help in endpoint filtering/selection?

Do we still need a query to Keystone to play arbiter if there are two
endpoints assigned for a specific use case to help determine which is
appropriate?

A lot of that ended up in here (which was an ether pad stevemar and I
started working on the other day) -
https://etherpad.openstack.org/p/mitaka-service-catalog which is great.
I didn't see anything immediately in the etherpad that couldn't be
covered with the tool mentioned above. It is open-source so we could
always try to contribute there if we need something extra (written in
golang though).

A couple of things that would make this more useful:

1) if you are commenting, please (ircnick) your comments. It's not easy
to always track down folks later if the comment was not understood.

projects. Reassembling that by reading each other's relevant code will
go a long way to understanding the whole picture.

Lastly, I think it's pretty clear we probably need a dedicated
workgroup

meeting to keep this ball rolling, come to a reasonable plan that
doesn't break any existing deployed code, but lets us get to a better
world in a few cycles. annegentle, stevemar, and I have been pushing on
that ball so far, however I'd like to know who else is willing to
commit
a chunk of time over this cycle to this. Once we know that we can
try to

figure out when a reasonable weekly meeting point would be.

Thanks,

-Sean

--
Sean Dague
http://dague.net

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] [kolla] Backport policy for Liberty

2015-10-09 Thread Jastrzebski, Michal

Hello,

Since we have little actual logic, and ansible itself is pretty pluggable by 
its very nature, backporting should be quite easy and would not affect existing 
deployment much. We will make sure that it will be safe to have stable/liberty 
code and will keep working at all times. I agree with Sam that we need careful 
CI for that, and it will be our first priority.

I would very much like to introduce operators to our session regarding this 
policy, as they will be most affected party and we want to make sure that they 
will take part in decision.

Regards,
Michał

From: Sam Yaple [mailto:sam...@yaple.net]
Sent: Friday, October 9, 2015 4:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [kolla] Backport policy for Liberty

On Thu, Oct 8, 2015 at 2:47 PM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
Kolla operators and developers,

The general consensus of the Core Reviewer team for Kolla is that we should 
embrace a liberal backport policy for the Liberty release.  An example of 
liberal -> We add a new server service to Ansible, we would backport the 
feature to liberty.  This is in breaking with the typical OpenStack backports 
policy.  It also creates a whole bunch more work and has potential to introduce 
regressions in the Liberty release.

Given these realities I want to put on hold any liberal backporting until after 
Summit.  I will schedule a fishbowl session for a backport policy discussion 
where we will decide as a community what type of backport policy we want.  The 
delivery required before we introduce any liberal backporting policy then 
should be a description of that backport policy discussion at Summit distilled 
into a RST file in our git repository.

If you have any questions, comments, or concerns, please chime in on the thread.

Regards
-steve

__
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

I am in favor of a very liberal backport policy. We have the potential to have 
very little code difference between N, N-1, and N-2 releases while still 
deploying the different versions of OpenStack. However, I recognize is a big 
undertaking to backport all things, not to mention the testing involved.

I would like to see two things before we truly embrace a liberal policy. The 
first is better testing. A true gate that does upgrades and potentially 
multinode (at least from a network perspective). The second thing is a bot or 
automation of some kind to automatically propose non-conflicting patches to the 
stable branches if they include the 'backport: xyz' tag in the commit message. 
Cores would still need to confirm these changes with the normal review process 
and could easily abandon them, but that would remove alot of overhead of 
performing the actual backport.
Since Kolla simply deploys OpenStack, it is alot closer to a client or a 
library than it is to Nova or Neutron. And given its mission maybe it should 
break from the "typical OpenStack backports policy" so we can give a consistent 
deployment experience across all stable and supported version of OpenStack at 
any given time.
Those are my thoughts on the matter at least. I look forward to some 
conversations about this in Tokyo.
Sam Yaple

__
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] nova-manage db archive_deleted_rows broken

2015-10-09 Thread Jay Pipes


On 10/07/2015 11:04 AM, Matt Riedemann wrote:

I'm wondering why we don't reverse sort the tables using the sqlalchemy
metadata object before processing the tables for delete?  That's the
same thing I did in the 267 migration since we needed to process the
tree starting with the leafs and then eventually get back to the
instances table (since most roads lead to the instances table).


Yes, that would make a lot of sense to me if we used the SA metadata 
object for reverse sorting.



Another thing that's really weird is how max_rows is used in this code.
There is cumulative tracking of the max_rows value so if the value you
pass in is too small, you might not actually be removing anything.

I figured max_rows meant up to max_rows from each table, not max_rows
*total* across all tables. By my count, there are 52 tables in the nova
db model. The way I read the code, if I pass in max_rows=10 and say it
processes table A and archives 7 rows, then when it processes table B it
will pass max_rows=(max_rows - rows_archived), which would be 3 for
table B. If we archive 3 rows from table B, rows_archived >= max_rows
and we quit. So to really make this work, you have to pass in something
big for max_rows, like 1000, which seems completely random.

Does this seem odd to anyone else?


Uhm, yes it does.

> Given the relationships between

tables, I'd think you'd want to try and delete max_rows for all tables,
so archive 10 instances, 10 block_device_mapping, 10 pci_devices, etc.

I'm also bringing this up now because there is a thread in the operators
list which pointed me to a set of scripts that operators at GoDaddy are
using for archiving deleted rows:

http://lists.openstack.org/pipermail/openstack-operators/2015-October/008392.html

Presumably because the command in nova doesn't work. We should either
make this thing work or just punt and delete it because no one cares.


The db archive code in Nova just doesn't make much sense to me at all. 
The algorithm for purging stuff, like you mention above, does not take 
into account the relationships between tables; instead of diving into 
the children relations and archiving those first, the code just uses a 
simplistic "well, if we hit a foreign key error, just ignore and 
continue archiving other things, we will eventually repeat the call to 
delete this row" strategy:


https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L6021-L6023

I had a proposal [1] to completely rework the whole shadow table mess 
and db archiving functionality. I continue to believe that is the 
appropriate solution for this, and that we should rip out the existing 
functionality because it simply does not work properly.


Best,
-jay

[1] https://review.openstack.org/#/c/137669/

__
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] [all] service catalog: TNG

2015-10-09 Thread Shamail



> On Oct 9, 2015, at 12:28 PM, Monty Taylor  wrote:
> 
>> On 10/09/2015 11:21 AM, Shamail wrote:
>> 
>> 
>>> On Oct 9, 2015, at 10:39 AM, Sean Dague  wrote:
>>> 
>>> It looks like some great conversation got going on the service catalog
>>> standardization spec / discussion at the last cross project meeting.
>>> Sorry I wasn't there to participate.
>> Apologize if this is a question that has already been address but why can't 
>> we just leverage something like consul.io?
> 
> It's a good question and there have actually been some discussions about 
> leveraging it on the backend. However, even if we did, we'd still need 
> keystone to provide the multi-tenancy view on the subject. consul wasn't 
> designed (quite correctly I think) to be a user-facing service for 50k users.
> 
> I think it would be an excellent backend.
Thanks, that makes sense.  I agree that it might be a good backend but not the 
overall solution... I was bringing it up to ensure we consider existing options 
(where possible) and spend cycles on the unsolved bits.

I am going to look into the scaling limitations for consul to educate myself.
> 
>> 
>>> A lot of that ended up in here (which was an ether pad stevemar and I
>>> started working on the other day) -
>>> https://etherpad.openstack.org/p/mitaka-service-catalog which is great.
>> I didn't see anything immediately in the etherpad that couldn't be covered 
>> with the tool mentioned above.  It is open-source so we could always try to 
>> contribute there if we need something extra (written in golang though).
>>> 
>>> A couple of things that would make this more useful:
>>> 
>>> 1) if you are commenting, please (ircnick) your comments. It's not easy
>>> to always track down folks later if the comment was not understood.
>>> 
>>> 2) please provide link to code when explaining a point. Github supports
>>> the ability to very nicely link to (and highlight) a range of code by a
>>> stable object ref. For instance -
>>> https://github.com/openstack/nova/blob/2dc2153c289c9d5d7e9827a4908b0ca61d87dabb/nova/context.py#L126-L132
>>> 
>>> That will make comments about X does Y, or Z can't do W, more clear
>>> because we'll all be looking at the same chunk of code and start to
>>> build more shared context here. One of the reasons this has been long
>>> and difficult is that we're missing a lot of that shared context between
>>> projects. Reassembling that by reading each other's relevant code will
>>> go a long way to understanding the whole picture.
>>> 
>>> 
>>> Lastly, I think it's pretty clear we probably need a dedicated workgroup
>>> meeting to keep this ball rolling, come to a reasonable plan that
>>> doesn't break any existing deployed code, but lets us get to a better
>>> world in a few cycles. annegentle, stevemar, and I have been pushing on
>>> that ball so far, however I'd like to know who else is willing to commit
>>> a chunk of time over this cycle to this. Once we know that we can try to
>>> figure out when a reasonable weekly meeting point would be.
>>> 
>>> Thanks,
>>> 
>>>-Sean
>>> 
>>> --
>>> Sean Dague
>>> http://dague.net
>>> 
>>> __
>>> 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

Re: [openstack-dev] Scheduler proposal

2015-10-09 Thread Zane Bitter


On 08/10/15 21:32, Ian Wells wrote:


> 2. if many hosts suit the 5 VMs then this is *very* unlucky,because we 
should be choosing a host at random from the set of
suitable hosts and that's a huge coincidence - so this is a tiny
corner case that we shouldn't be designing around

Here is where we differ in our understanding. With the current
system of filters and weighers, 5 schedulers getting requests for
identical VMs and having identical information are *expected* to
select the same host. It is not a tiny corner case; it is the most
likely result for the current system design. By catching this
situation early (in the scheduling process) we can avoid multiple
RPC round-trips to handle the fail/retry mechanism.


And so maybe this would be a different fix - choose, at random, one of
the hosts above a weighting threshold, not choose the top host every
time? Technically, any host passing the filter is adequate to the task
from the perspective of an API user (and they can't prove if they got
the highest weighting or not), so if we assume weighting an operator
preference, and just weaken it slightly, we'd have a few more options.


The optimal way to do this would be a weighted random selection, where 
the probability of any given host being selected is proportional to its 
weighting. (Obviously this is limited by the accuracy of the weighting 
function in expressing your actual preferences - and it's at least 
conceivable that this could vary with the number of schedulers running.)


In fact, the choice of the name 'weighting' would normally imply that 
it's done this way; hearing that the 'weighting' is actually used as a 
'score' with the highest one always winning is quite surprising.


cheers,
Zane.

__
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] [ironic] Nominating two new core reviewers

2015-10-09 Thread Devananda van der Veen

++ on both counts!

On Thu, Oct 8, 2015 at 2:47 PM, Jim Rollenhagen 
wrote:

> Hi all,
>
> I've been thinking a lot about Ironic's core reviewer team and how we might
> make it better.
>
> I'd like to grow the team more through trust and mentoring. We should be
> able to promote someone to core based on a good knowledge of *some* of
> the code base, and trust them not to +2 things they don't know about. I'd
> also like to build a culture of mentoring non-cores on how to review, in
> preparation for adding them to the team. Through these pieces, I'm hoping
> we can have a few rounds of core additions this cycle.
>
> With that said...
>
> I'd like to nominate Vladyslav Drok (vdrok) for the core team. His reviews
> have been super high quality, and the quantity is ever-increasing. He's
> also started helping out with some smaller efforts (full tempest, for
> example), and I'd love to see that continue with larger efforts.
>
> I'd also like to nominate John Villalovos (jlvillal). John has been
> reviewing a ton of code and making a real effort to learn everything,
> and keep track of everything going on in the project.
>
> Ironic cores, please reply with your vote; provided feedback is positive,
> I'd like to make this official next week sometime. Thanks!
>
> // jim
>
>
> __
> 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] [fuel] PTL & Component Leads elections

2015-10-09 Thread Mike Scherbakov

Congratulations to Dmitry!
Now you are officially titled with PTL.
It won't be easy, but we will support you!

118 contributors voted. Thanks everyone! Thank you Sergey for organizing
elections for us.

On Thu, Oct 8, 2015 at 3:52 PM Sergey Lukjanov 
wrote:

> Voting period ended and so we have an officially selected Fuel PTL - DB.
> Congrats!
>
> Poll results & details -
> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1&id=E_b79041aa56684ec0
>
> Let's start proposing candidates for the component lead positions!
>
> On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov 
> wrote:
>
>> Hi folks,
>>
>> I've just setup the voting system and you should start receiving email
>> with topic "Poll: Fuel PTL Elections Fall 2015".
>>
>> NOTE: Please, don't forward this email, it contains *personal* unique
>> token for the voting.
>>
>> Thanks.
>>
>> On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin 
>> wrote:
>>
>>> +1 to Igor. Do we have voting system set up?
>>>
>>> On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky >> > wrote:
>>>
 > * September 29 - October 8: PTL elections

 So, it's in progress. Where I can vote? I didn't receive any emails.

 On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala
  wrote:
 >> On 18 Sep 2015, at 04:39, Sergey Lukjanov 
 wrote:
 >>
 >>
 >> Time line:
 >>
 >> PTL elections
 >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL
 position
 >> * September 29 - October 8: PTL elections
 >
 > Just a reminder that we have a deadline for candidates today.
 >
 > Regards,
 > --
 > Tomasz 'Zen' Napierala
 > Product Engineering - Poland
 >
 >
 >
 >
 >
 >
 >
 >
 >
 __
 > 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

>>>
>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@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
>>>
>>>
>>
>>
>> --
>> Sincerely yours,
>> Sergey Lukjanov
>> Sahara Technical Lead
>> (OpenStack Data Processing)
>> Principal Software Engineer
>> Mirantis Inc.
>>
>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> __
> 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
>
-- 
Mike Scherbakov
#mihgen
__
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] [all] service catalog: TNG

2015-10-09 Thread Clint Byrum

Excerpts from Adam Young's message of 2015-10-09 09:51:55 -0700:
> On 10/09/2015 12:28 PM, Monty Taylor wrote:
> > On 10/09/2015 11:21 AM, Shamail wrote:
> >>
> >>
> >>> On Oct 9, 2015, at 10:39 AM, Sean Dague  wrote:
> >>>
> >>> It looks like some great conversation got going on the service catalog
> >>> standardization spec / discussion at the last cross project meeting.
> >>> Sorry I wasn't there to participate.
> >>>
> >> Apologize if this is a question that has already been address but why 
> >> can't we just leverage something like consul.io?
> >
> > It's a good question and there have actually been some discussions 
> > about leveraging it on the backend. However, even if we did, we'd 
> > still need keystone to provide the multi-tenancy view on the subject. 
> > consul wasn't designed (quite correctly I think) to be a user-facing 
> > service for 50k users.
> >
> > I think it would be an excellent backend.
> 
> The better question is, "Why are we not using DNS for the service catalog?"
> 

Agreed, we're using HTTP and JSON for what DNS is supposed to do.

As an aside, consul has a lovely DNS interface.

> Right now, we have the aspect of "project filtering of endpoints" which 
> means that a token does not need to have every endpoint for a specified 
> service.  If we were to use DNS, how would that map to the existing 
> functionality.
> 

There are a number of "how?" answers, but the "what?" question is the
more interesting one. As in, what is the actual point of this
functionality, and what do people want to do per-project?

I think what really ends up happening is you have 99.9% the same
catalogs to the majority of projects, with a few getting back a
different endpoint or two. For that, it seems like you would have two
queries needed in the "discovery" phase:

SRV compute.myprojectid.region1.mycloud.com
SRV compute.region1.mycloud.com

Use the first one you get an answer for. Keystone would simply add
or remove entries for special project<->endpoint mappings. You don't
need Keystone to tell you what your project ID is, so you just make
these queries. When you get a negative answer, respect the TTL and stop
querying for it.

Did I miss a use case with that?

> 
> Can we make better use of regions to help in endpoint filtering/selection?
> 
> Do we still need a query to Keystone to play arbiter if there are two 
> endpoints assigned for a specific use case to help determine which is 
> appropriate?
> 

I'd hope not. If the user is authorized then they should be able
to access the endpoint that they're assigned to. It's confusing to
me sometimes how keystone is thought of as an authorization service,
when it is named "Identity", and primarily performs authentication and
service discovery.

__
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] [all] service catalog: TNG

2015-10-09 Thread Jonathan D. Proulx

On Fri, Oct 09, 2015 at 01:01:20PM -0400, Shamail wrote:
:> On Oct 9, 2015, at 12:28 PM, Monty Taylor  wrote:
:> 
:>> On 10/09/2015 11:21 AM, Shamail wrote:
:>> 
:>> 
:>>> On Oct 9, 2015, at 10:39 AM, Sean Dague  wrote:
:>>> 
:>>> It looks like some great conversation got going on the service catalog
:>>> standardization spec / discussion at the last cross project meeting.
:>>> Sorry I wasn't there to participate.
:>> Apologize if this is a question that has already been address but why can't 
we just leverage something like consul.io?
:> 
:> It's a good question and there have actually been some discussions about 
leveraging it on the backend. However, even if we did, we'd still need keystone 
to provide the multi-tenancy view on the subject. consul wasn't designed (quite 
correctly I think) to be a user-facing service for 50k users.
:> 
:> I think it would be an excellent backend.
:Thanks, that makes sense.  I agree that it might be a good backend but not the 
overall solution... I was bringing it up to ensure we consider existing options 
(where possible) and spend cycles on the unsolved bits.

As an operator I'd be happy to use SRV records to define endpoints,
though multiple regions could make that messy.

would we make subdomins per region or include region name in the
service name? 

_compute-regionone._tcp.example.com 
   -vs-
_compute._tcp.regionone.example.com

Also not all operators can controll their DNS to this level so it
couldn't be the only option.

Or are you talking about using an internal DNS implementation private
to the OpenStack Deployment?  I'm actually a bit less happy with that
idea.

-Jon
 

__
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] [Openstack-operators] Scheduler proposal

2015-10-09 Thread Clint Byrum

Excerpts from Chris Friesen's message of 2015-10-08 23:52:41 -0700:
> On 10/08/2015 01:37 AM, Clint Byrum wrote:
> > Excerpts from Maish Saidel-Keesing's message of 2015-10-08 00:14:55 -0700:
> >> Forgive the top-post.
> >>
> >> Cross-posting to openstack-operators for their feedback as well.
> >>
> >> Ed the work seems very promising, and I am interested to see how this
> >> evolves.
> >>
> >> With my operator hat on I have one piece of feedback.
> >>
> >> By adding in a new Database solution (Cassandra) we are now up to three
> >> different database solutions in use in OpenStack
> >>
> >> MySQL (practically everything)
> >> MongoDB (Ceilometer)
> >> Cassandra.
> >>
> >> Not to mention two different message queues
> >> Kafka (Monasca)
> >> RabbitMQ (everything else)
> >>
> >> Operational overhead has a cost - maintaining 3 different database
> >> tools, backing them up, providing HA, etc. has operational cost.
> >>
> >> This is not to say that this cannot be overseen, but it should be taken
> >> into consideration.
> >>
> >> And *if* they can be consolidated into an agreed solution across the
> >> whole of OpenStack - that would be highly beneficial (IMHO).
> >>
> >
> > Just because they both say they're databases, doesn't mean they're even
> > remotely similar.
> 
> True, but the fact remains that it means operators (and developers) would 
> have 
> to become familiar with the quirks and problems of yet another piece of 
> technology.
> 

Indeed! And we can get really opinionated here now that we have some
experience I think. Personally, I'd rather become familiar with the
quirks and problems of Cassandra, than try to become familiar with the
quirks and problems of OpenStack's invented complex workarounds for high
scale state management cells.

So I agree with the statement that the cost of adding a technology should
be weighed. However, the cost of inventing a workaround should be weighed
with the same scale. Complex workarounds will, in most cases, weigh much
more than adopting a well known and proven technology that is aimed at
what turns out to be a common problem set.

__
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] [Murano] py26 support in python-muranoclient

2015-10-09 Thread Vahid S Hashemian

Serg, Jeremy,

Thank you for your response, so the issue I ran into with my patch is the 
gate job failing on python26.
You can see it here: https://review.openstack.org/#/c/232271/

Serg suggested that we add 2.6 support to tosca-parser, which is fine with 
us.
But I got a bit confused after reading Jeremy's response.
It seems to me that the support will be going away, but there is no 
timeline (and therefore no near-term plan?)
So, I'm hoping Jeremy can advise whether he also recommends the same 
thing, or not.

Thank you both again.

Regards,
-
Vahid Hashemian, Ph.D.
Advisory Software Engineer, IBM Cloud




__
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] [all] Recording little everyday OpenStack successes

2015-10-09 Thread Mike Spreitzer

Thierry Carrez  wrote on 10/09/2015 05:42:49 AM:

...
> So whenever you feel like you made progress, or had a little success in
> your OpenStack adventures, or have some joyful moment to share, just
> throw the following message on your local IRC channel:
> 
> #success [Your message here]
> 
> The openstackstatus bot will take that and record it on this wiki page:
> 
> https://wiki.openstack.org/wiki/Successes
> 
> We'll add a few of those every week to the weekly newsletter (as part of
> the developer digest that we reecently added there).
> 
> Caveats: Obviously that only works on channels where openstackstatus is
> present (the official OpenStack IRC channels), and we may remove entries
> that are off-topic or spam.
> 
> So... please use #success liberally and record lttle everyday OpenStack
> successes. Share the joy and make the OpenStack community a happy place.

Great.  I am about to contribute one myself.  Lucky I noticed this email. 
How will the word get out to those who did not?  How about a pointer to 
instructions on the Successes page?

Thanks,
Mike


__
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] [all] service catalog: TNG

2015-10-09 Thread David Stanek

On Fri, Oct 9, 2015 at 1:28 PM, Jonathan D. Proulx 
wrote:

> On Fri, Oct 09, 2015 at 01:01:20PM -0400, Shamail wrote:
> :> On Oct 9, 2015, at 12:28 PM, Monty Taylor  wrote:
> :>
> :>> On 10/09/2015 11:21 AM, Shamail wrote:
> :>>
> :>>
> :>>> On Oct 9, 2015, at 10:39 AM, Sean Dague  wrote:
> :>>>
> :>>> It looks like some great conversation got going on the service catalog
> :>>> standardization spec / discussion at the last cross project meeting.
> :>>> Sorry I wasn't there to participate.
> :>> Apologize if this is a question that has already been address but why
> can't we just leverage something like consul.io?
> :>
> :> It's a good question and there have actually been some discussions
> about leveraging it on the backend. However, even if we did, we'd still
> need keystone to provide the multi-tenancy view on the subject. consul
> wasn't designed (quite correctly I think) to be a user-facing service for
> 50k users.
> :>
> :> I think it would be an excellent backend.
> :Thanks, that makes sense.  I agree that it might be a good backend but
> not the overall solution... I was bringing it up to ensure we consider
> existing options (where possible) and spend cycles on the unsolved bits.
>
> As an operator I'd be happy to use SRV records to define endpoints,
> though multiple regions could make that messy.
>
> would we make subdomins per region or include region name in the
> service name?
>
> _compute-regionone._tcp.example.com
>-vs-
> _compute._tcp.regionone.example.com
>
> Also not all operators can controll their DNS to this level so it
> couldn't be the only option.
>
> Or are you talking about using an internal DNS implementation private
> to the OpenStack Deployment?  I'm actually a bit less happy with that
> idea.
>

I was able to put together an implementation[1] of DNS-SD loosely based on
RFC-6763[2]. It'd really a proof of concept, but we've talked so much about
it that I decided to get something working. Although if this seems like a
viable option then there's still much work to be done.

I'd love feedback.

1. https://gist.github.com/dstanek/093f851fdea8ebfd893d
2. https://tools.ietf.org/html/rfc6763

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.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

Re: [openstack-dev] [Murano] py26 support in python-muranoclient

2015-10-09 Thread Clark Boylan



On Fri, Oct 9, 2015, at 10:32 AM, Vahid S Hashemian wrote:
> Serg, Jeremy,
> 
> Thank you for your response, so the issue I ran into with my patch is the 
> gate job failing on python26.
> You can see it here: https://review.openstack.org/#/c/232271/
> 
> Serg suggested that we add 2.6 support to tosca-parser, which is fine
> with 
> us.
> But I got a bit confused after reading Jeremy's response.
> It seems to me that the support will be going away, but there is no 
> timeline (and therefore no near-term plan?)
> So, I'm hoping Jeremy can advise whether he also recommends the same 
> thing, or not.
There is a timeline (though admittedly hard to find) at
https://etherpad.openstack.org/p/YVR-relmgt-stable-branch which says
Juno support would run through the end of November. Since Juno is the
last release to support python2.6 we will remove python2.6 support from
the test infrastructure at that time as well.

I personally probably wouldn't bother with extra work to support
python2.6, but that all depends on how much work it is and whether or
not you find value in it. Ultimately it is up to you, just know that the
Infrastructure team will stop hosting testing for python2.6 when Juno is
EOLed.

Hope this helps,
Clark

__
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] Scheduler proposal

2015-10-09 Thread Chris Friesen


On 10/09/2015 11:09 AM, Zane Bitter wrote:


The optimal way to do this would be a weighted random selection, where the
probability of any given host being selected is proportional to its weighting.
(Obviously this is limited by the accuracy of the weighting function in
expressing your actual preferences - and it's at least conceivable that this
could vary with the number of schedulers running.)

In fact, the choice of the name 'weighting' would normally imply that it's done
this way; hearing that the 'weighting' is actually used as a 'score' with the
highest one always winning is quite surprising.


If you've only got one scheduler, there's no need to get fancy, you just pick 
the "best" host based on your weighing function.


It's only when you've got parallel schedulers that things get tricky.

Chris

__
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] Scheduler proposal

2015-10-09 Thread Clint Byrum

Excerpts from Chris Friesen's message of 2015-10-09 10:54:36 -0700:
> On 10/09/2015 11:09 AM, Zane Bitter wrote:
> 
> > The optimal way to do this would be a weighted random selection, where the
> > probability of any given host being selected is proportional to its 
> > weighting.
> > (Obviously this is limited by the accuracy of the weighting function in
> > expressing your actual preferences - and it's at least conceivable that this
> > could vary with the number of schedulers running.)
> >
> > In fact, the choice of the name 'weighting' would normally imply that it's 
> > done
> > this way; hearing that the 'weighting' is actually used as a 'score' with 
> > the
> > highest one always winning is quite surprising.
> 
> If you've only got one scheduler, there's no need to get fancy, you just pick 
> the "best" host based on your weighing function.
> 
> It's only when you've got parallel schedulers that things get tricky.
> 

Note that I think you mean _concurrent_ not _parallel_ schedulers.

Parallel schedulers would be trying to solve the same unit of work by
breaking it up into smaller components and doing them at the same time.

Concurrent means they're just doing different things at the same time.

I know this is nit-picky, but we use the wrong word _A LOT_ and the
problem space is actually vastly different, as parallelizable problems
have a whole set of optimizations and advantages that generic concurrent
problems (especially those involving mutating state!) have a whole set
of race conditions that must be managed.

__
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] [kolla] Backport policy for Liberty

2015-10-09 Thread Fox, Kevin M

As an Op, that sounds reasonable so long as they aren't defaulted on. In theory 
it shouldn't be much different then a distro adding additional packages. The 
new packages don't affect existing systems unless the op requests them to be 
installed.

With my App Catalog hat on, I'm curious how horizon plugins might fit into that 
scheme. The App Catalog plugin would need to be added directly to the Horizon 
container. I'm sure there are other plugins that may want to get loaded into 
the container too. They should all be able to be enabled/disabled though via 
docker env variables though. Any thoughts there?

Thanks,
Kevin

From: Steven Dake (stdake) [std...@cisco.com]
Sent: Thursday, October 08, 2015 12:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] Backport policy for Liberty

Kolla operators and developers,

The general consensus of the Core Reviewer team for Kolla is that we should 
embrace a liberal backport policy for the Liberty release.  An example of 
liberal -> We add a new server service to Ansible, we would backport the 
feature to liberty.  This is in breaking with the typical OpenStack backports 
policy.  It also creates a whole bunch more work and has potential to introduce 
regressions in the Liberty release.

Given these realities I want to put on hold any liberal backporting until after 
Summit.  I will schedule a fishbowl session for a backport policy discussion 
where we will decide as a community what type of backport policy we want.  The 
delivery required before we introduce any liberal backporting policy then 
should be a description of that backport policy discussion at Summit distilled 
into a RST file in our git repository.

If you have any questions, comments, or concerns, please chime in on the thread.

Regards
-steve
__
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] [Heat] mox to mock migration

2015-10-09 Thread Jay Dobies

This sounds good, I was hoping it'd be acceptable to use etherpad. I 
filed a blueprint [1] but I'm anticipating using the etherpad much more 
regularly to track which files are being worked or completed.


[1] https://blueprints.launchpad.net/heat/+spec/mox-to-mock-conversion
[2] https://etherpad.openstack.org/p/heat-mox-to-mock

Thanks for the guidance :)

On 10/09/2015 12:42 PM, Steven Hardy wrote:

On Fri, Oct 09, 2015 at 09:06:57AM -0400, Jay Dobies wrote:

I forget where we left things at the last meeting with regard to whether or
not there should be a blueprint on this. I was going to work on some during
some downtime but I wanted to make sure I wasn't overlapping with what
others may be converting (it's more time consuming than I anticipated).

Any thoughts on how to track it?


I'd probably suggest raising either a bug or a blueprint (not spec), then
link from that to an etherpad where you can track all the tests requiring
rework, and who's working on them.

"it's more time consuming than I anticipated" is pretty much my default
response for anything to do with heat unit tests btw, good luck! :)

Steve

__
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] [Murano] py26 support in python-muranoclient

2015-10-09 Thread Vahid S Hashemian

Thank Clark. That really helps.
We'll consider this timeline and make a decision on which way to go 
bearing in mind that waiting for 2.6 phase out would mean a 2 months delay 
in getting this blueprint implemented.

Regards,
-
Vahid Hashemian, Ph.D.
Advisory Software Engineer, IBM Cloud



__
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] nova-manage db archive_deleted_rows broken

2015-10-09 Thread Matt Riedemann




On 10/9/2015 12:03 PM, Jay Pipes wrote:

On 10/07/2015 11:04 AM, Matt Riedemann wrote:

I'm wondering why we don't reverse sort the tables using the sqlalchemy
metadata object before processing the tables for delete?  That's the
same thing I did in the 267 migration since we needed to process the
tree starting with the leafs and then eventually get back to the
instances table (since most roads lead to the instances table).


Yes, that would make a lot of sense to me if we used the SA metadata
object for reverse sorting.


When I get some free time next week I'm going to play with this.




Another thing that's really weird is how max_rows is used in this code.
There is cumulative tracking of the max_rows value so if the value you
pass in is too small, you might not actually be removing anything.

I figured max_rows meant up to max_rows from each table, not max_rows
*total* across all tables. By my count, there are 52 tables in the nova
db model. The way I read the code, if I pass in max_rows=10 and say it
processes table A and archives 7 rows, then when it processes table B it
will pass max_rows=(max_rows - rows_archived), which would be 3 for
table B. If we archive 3 rows from table B, rows_archived >= max_rows
and we quit. So to really make this work, you have to pass in something
big for max_rows, like 1000, which seems completely random.

Does this seem odd to anyone else?


Uhm, yes it does.

 > Given the relationships between

tables, I'd think you'd want to try and delete max_rows for all tables,
so archive 10 instances, 10 block_device_mapping, 10 pci_devices, etc.

I'm also bringing this up now because there is a thread in the operators
list which pointed me to a set of scripts that operators at GoDaddy are
using for archiving deleted rows:

http://lists.openstack.org/pipermail/openstack-operators/2015-October/008392.html


Presumably because the command in nova doesn't work. We should either
make this thing work or just punt and delete it because no one cares.


The db archive code in Nova just doesn't make much sense to me at all.
The algorithm for purging stuff, like you mention above, does not take
into account the relationships between tables; instead of diving into
the children relations and archiving those first, the code just uses a
simplistic "well, if we hit a foreign key error, just ignore and
continue archiving other things, we will eventually repeat the call to
delete this row" strategy:

https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L6021-L6023


Yeah, I noticed that too and I don't think it actually does anything. We 
never actually come back since that would require some 
tracking/stack/recursion stuff to retry failed tables, which we don't do.





I had a proposal [1] to completely rework the whole shadow table mess
and db archiving functionality. I continue to believe that is the
appropriate solution for this, and that we should rip out the existing
functionality because it simply does not work properly.

Best,
-jay

[1] https://review.openstack.org/#/c/137669/


Are you going to pick that back up? Or sick some minions on it.



__
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



--

Thanks,

Matt Riedemann


__
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] [all] service catalog: TNG