Re: [openstack-dev] [mistral] Meeting Time

[Renat Akhmerov]

> On 22 Nov 2016, at 18:11, Deja, Dawid  wrote:
> 
> If we want to have another meeting that would suit mostly New Zeland
> and US, can we move current meeting time to slightly earlier, so it
> fits India better (and also may be more comfortable for people in
> Europe)?


For me 30-60 mins earlier would be ok, better 30 than 60. But 60 mins is the 
biggest shift that would work for me.

Renat Akhmerov
@Nokia

__
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] Meeting Time

[Renat Akhmerov]

> On 22 Nov 2016, at 23:30, Dougal Matthews  wrote:
> 
> 
> 
> On 22 November 2016 at 10:45, Renat Akhmerov  > wrote:
> Dougal,
> 
> I think we should have this alternate meeting. The reason is although the 
> current time doesn’t work only for 2-3 people those people are very important 
> for the project (I primarily mean Lingxian (kong) and Winson (m4dcoder)). As 
> far as I understand, for Hardik Parekh (hparekh) the current time also 
> doesn’t work well.
> 
> I’m volunteering to participate in this alternate meeting even if it’s not 
> too comfortable for me.
> 
> Great. Do you want to start this next week or the week after?
> 
> I'm not sure how/where we need to update with the new meeting information. I 
> also think we need to reserve the time in IRC.

I want to make sure to talk to all needed folks again about it. Lingxian is now 
on vacation (till Nov 24 if I remember correctly), so we need to wait till he 
is back.

I’ll get back to this thread once we discuss that.

Thanks

Renat Akhmerov
@Nokia


__
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] [Rally] broken jobs

[Andrey Kurilin]

Finally, fixes are merged and our jobs work now.

On Tue, Nov 22, 2016 at 3:01 PM, Andrey Kurilin 
wrote:

> Hi Renat,
>
> As soon as one [1][2] changes will be merged, everything should be
> unblocked.
>
> [1] - https://review.openstack.org/#/c/399752
> [2] - https://review.openstack.org/#/c/400183
>
>
> On Tue, Nov 22, 2016 at 12:40 PM, Renat Akhmerov  > wrote:
>
>> Andrey, thanks for reporting this. Any estimations on how long it will
>> take to fix it?
>>
>> Renat Akhmerov
>> @Nokia
>>
>> On 19 Nov 2016, at 02:23, Andrey Kurilin  wrote:
>>
>> yse, I think you are right.
>>
>> On Fri, Nov 18, 2016 at 4:04 PM, gordon chung  wrote:
>>
>>> this seems related to fact we use datetime type in mysql which requires
>>> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the
>>> required mysql.
>>>
>>> On 18/11/16 07:50 AM, Andrey Kurilin wrote:
>>> > Hi stackers,
>>> >
>>> > I hate to report such things, but most of rally jobs are broken now due
>>> > to uncompatibility aodh service with ubuntu-trusty nodes.
>>> >
>>> > If you find failed rally jobs with
>>> > http://paste.openstack.org/show/589707/ in devstacklogs, recheck will
>>> > not help.
>>> >
>>> > I'm working on two changes now for Rally jobs which should unblock and
>>> > fix gates:
>>> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long
>>> time ago.
>>> > - Disable telemetry services in those jobs which do not need them.
>>> >
>>> >
>>> > --
>>> > Best regards,
>>> > Andrey Kurilin.
>>> >
>>> >
>>> > 
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> 
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> --
>>> gord
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best regards,
> Andrey Kurilin.
>



-- 
Best regards,
Andrey Kurilin.
__
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] [tricircle]agenda of weekly meeting Nov.23

[joehuang]

Hello, team,

Ocata Milestone-1 is approaching, let's continue the weekly meeting.

Agenda of Nov.23 weekly meeting:

  1.  Ocata feature development review
  2.  Py35, Ubuntu Xenial gate and check jobs
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi Huang (joehuang)
__
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-docs] [OpenStack-operators] [docs][upgrades] time to add official docs for upgrading services?

[darren chan]

No problem :) I simplified the spec to be more realistic about what we can 
achieve for Ocata.
https://review.openstack.org/#/c/394261/
 

On Friday, 18 November 2016, 23:53, Steve Martinelli 
 wrote:
 

 
On Thu, Nov 17, 2016 at 11:04 PM, darren chan  wrote:

Good timing, I was about to send a follow-up email about this spec.
I agree, this content needs to be more visible, which is why the spec proposed 
to move upgrade notes to the Upgrades chapter in the Operations Guide. However, 
it seems like the general consensus is to keep content in project repos because 
it is more likely to be maintained there. 


Considering the Ocata development cycle is pretty short, we've already 
established our docs deliverables, and other projects are still developing 
upgrade notes, would links to the upgrade notes in the Ops Guide suffice in the 
interim? We can then propose and plan a better solution for Pike, such as 
in-tree official guides? 
Thoughts? 


The project teams will always use the maintenance argument. But I understand 
your concern, and in my initial draft to the mailing list i was going to voice 
a similar statement. Maybe wait until teams have fleshed out their various 
supported upgrade strategies? 

 
Darren

On Friday, 18 November 2016, 13:33, Lana Brindley 
 wrote:
 

 Isn't that more or less what this is?

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



Yup! Thanks for reading my mind docs team :)

   __
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][stable][ptls] Tagging liberty as EOL

[Tony Breeds]

On Tue, Nov 22, 2016 at 05:51:30PM -0700, Alex Schultz wrote:
> On Tue, Nov 22, 2016 at 5:13 PM, Tony Breeds  wrote:
> > On Tue, Nov 22, 2016 at 09:21:00AM -0700, Alex Schultz wrote:
> >
> >> For the puppet items on the second list[0], the liberty branches of
> >> puppet-aodh and puppet-openstack_spec_helper can be EOL'ed.
> >
> > Thanks I updated the list.  Can I ask why puppet-murano will be left behind?
> >
> 
> Because I got side tracked with barbican and forgot to include it in
> the list. That can be EOL'ed as well.

Ahh cool.  Thanks.

Yours Tony.


signature.asc
Description: 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] [Horizon] Meeting at 20:00 UTC this Wednesday, 23rd November

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 23rd November in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

Richard

__
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-lbaas][octavia] About running Neutron LBaaS

[Yipei Niu]

Hi, Micheal,

Thanks a lot for your help. I am trying your solution.

Best regards,
Yipei

On Sun, Nov 20, 2016 at 1:46 PM, Yipei Niu  wrote:

> Hi, Micheal,
>
> Thanks a lot for your comments.
>
> Please find the errors of o-cw.log in link http://paste.openstack.
> org/show/589806/ . Hope it will
> help.
>
> About the lb-mgmt-net, I just follow the guide of running LBaaS. If I
> create a ordinary subnet with neutron for the two VMs, will it prevent the
> issue you mentioned happening?
>
> Best regards,
> Yipei
>
__
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] [tricircle]Questions about Tricircle L2 and L3 implementation

[joehuang]

Hello, Dina,

Thank you for your comments, it'll be good to discuss tricircle related topic 
in openstack-dev so that more people can be involved in if necessary, and keep 
the project transparent. So I copied the reply to  
openstack-dev@lists.openstack.org.

For L2VxLAN, the VNI identifiers will be allocated in central Neutron, and then 
same VNI segment will be used for local Neutron during get_network or get_port 
from Nova, the local plugin in local Neutron will query the network segment 
info. and persist same uuid and VNI in local Neutron. But VxLAN based cross 
Neutron L2 networking has not started yet, the spec has not submitted for 
review yet, currently only VLAN based L2/L3 networking were implemented, 
supported features could be found in the release 
notes:https://github.com/openstack/tricircle/blob/master/releasenotes/notes/initial-release-notes.yaml
 .

 VxLAN L2 networking and VxLAN as the bridge network for L3 networking will 
rely on the patch for "formalize the tunnel termination point by adding it to 
the port binding data model" which is mentioned in "Eliminating L2pop as a 
mechanism driver" 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107061.html

Before VxLAN L2 networking and VxLAN as the bridge network for L3 networking, 
this spec is being reviewed, https://review.openstack.org/#/c/396564/, please 
join the review to see whether it can meet your demands, especially for the 
cross Neutron networking models.

What is "RT parameters"?

Tricircle supported L3 networking based on shared VLAN bridge network, you can 
refer to "6.6  L3 Networking across Neutron", but just as what mentioned in the 
release notes,  only VLAN L2 network and shared VLAN as the bridge network for 
L3 networking are supported.

There are todo list for the usage documentation in ocata release, you are 
welcome to join the contribution, no matter documentation or source code or 
review.

Best Regards
Chaoyi Huang (joehuang)

From: dina@orange.com [dina@orange.com]
Sent: 22 November 2016 21:54
To: joehuang
Subject: Questions about Tricircle L2 and L3 implementation

Hello Chaoyi Huang,

I have read Tricirle wiki documentation and some presentations.
May I ask you I have few questions about Tricircle implementation ?
Here there are :

1°) L2 VxLAN
How are choosen VNI identifiers ?
How are choosen RT parameters ? Is a control plane used or all is configured 
within a pool ?

2°) L3
Does Tricircle support L3 interconnection ?
Have you documentation about that ?

Thanks,
Best Regards,

Dina SOL

[logo-Orange]
Dina Sol
Orange/ IMT/ OLN/ WTC/ IEE/ NAVI (Network Automation and Virtualized 
Infrastructure)
Orange Labs
2, avenue Pierre Marzin
22307 Lannion Cedex
tel : 00 33 (0)2 96 07 11 22
dina@orange.com



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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][ptls][tc][goals] acknowledging community goals for Ocata

[joehuang]

Hello, Doug,

Tricircle will submit a patch for the "remove-incubated-oslo-code.rst" goal. 
For Tricircle was just approved last week, need to dig into how to achieve this 
goal.

Best Regards
Chaoyi Huang (joehuang)


From: Doug Hellmann [d...@doughellmann.com]
Sent: 16 November 2016 23:35
To: openstack-dev
Subject: [openstack-dev] [all][ptls][tc][goals] acknowledging community goals 
for Ocata

We still have quite a few teams who have not acknowledged the goal for
Ocata. Remember, *all* teams are expected to respond, even if there is
no work to be done. The most important feature of this new process is
communication, which won't happen if teams don't participate.

Please take a few minutes to review
http://governance.openstack.org/goals/index.html and
http://governance.openstack.org/goals/ocata/remove-incubated-oslo-code.html
then submit a patch to add your planning artifacts to
openstack/governance/goals/ocata/remove-incubated-oslo-code.rst before
the deadline tomorrow.

Doug

__
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] [tripleo] POC patch for using tripleo-repos for repo setup

[Emilien Macchi]

Even if I was part of those who approved this feature, I still have
some comments, inline:

On Tue, Nov 22, 2016 at 1:30 PM, Alex Schultz  wrote:
> On Tue, Nov 22, 2016 at 11:06 AM, Ben Nemec  wrote:
>>
>>
>> On 11/21/2016 05:26 PM, Alex Schultz wrote:
>>>
>>> On Mon, Nov 21, 2016 at 2:57 PM, Ben Nemec  wrote:

 Hi,

 I have a POC patch[1] up to demonstrate the use of the tripleo-repos tool
 [2] as a replacement for most of tripleo.sh --repo-setup.  It has now
 passed
 all of the CI jobs so I wanted to solicit some feedback.

 There are a few changes related to repo naming because the tool names
 repo
 files based on the repo name rather than always calling them something
 generic like delorean.repo.  I think it's less confusing to have the
 delorean-newton repo file named delorean-newton.repo, but I'm open to
 discussion on that.

 If no one has any major objections to how the tool looks/works right now,
 I'll proceed with the work to get it imported into the openstack
 namespace
 as part of TripleO.  We can always iterate on it after import too, of
 course, so this isn't a speak now or forever hold your peace situation.
 :-)

>>>
>>> Why a python standalone application for the management of specifically
>>> (and only?) tripleo repositories.  It seems we should be trying to
>>> leverage existing tooling and not hiding the problem behind a python
>>> app.  It's not that I enjoy the current method described in the spec
>>> (3 curls, 1 sed, 1 bash thing, and a yum install) but it seems like to
>>> write 586 lines of python and tests might be the wrong approach.
>>> Would it be better to just devote some time to rpm generation for
>>> these and deliver it in discrete RPMs?  'yum install
>>> http://tripleo.org/repos-current.rpm' seems way more straight forward.
>>
>>
>> That's essentially trading "curl ..." for "yum install ..." in the docs.
>> The repo rpm would have to be part of the delorean build so you'd still have
>> to be pointing people at a delorean repo.  It would also still require code
>> changes somewhere to handle the mixed current/current-tripleo setup that we
>> run for development and test. Given how specific to tripleo that is I'm not
>> sure how much sense it makes to implement it elsewhere.
>>
>
> I'm asking because essentially we're delivering basically static repo
> files.  Which should really be done via RPM. Upgrades and cleanups are
> already well established practices between RPMs.  I'm not seeing the
> reasoning why a python app.  I thought about this further and I'm not
> sure why this should be done on the client side via an app rather than
> at repository build/promotion time.  As long as we're including the
> repo rpm, we can always create simple 302 redirects from a webserver
> to get the latest version.  I don't see why we should introduce a
> client tool for this when the action is really on the repository
> packaging side.   This seems odd doing system configuration via a
> python script rather than a configuration management tool like
> ansible, puppet or even just packaging.
>
>> There are also optional ceph and opstool repos and at least ceph needs to
>> match the version of OpenStack being installed.  Sure, you could just
>> document all that logic, but then the logic has to be reimplemented in CI
>> anyway so you end up with code to maintain either way.  At least with one
>> tool the logic is shared between the user and dev/test paths, which is one
>> of the primary motivations behind it.  Pretty much every place that we have
>> divergence between what users do and what developers do becomes a pain point
>> for users because developers only fix the things they actually use.
>>
>
> Yes we should not have a different path for dev/test vs operational
> deployments, but I'm not convinced we need to add a custom python tool
> to handle this only for tripleo.  There are already established
> patterns of repository rpm delivery and installation via existing
> tools.  What are we getting from this tool that can't already be done?

That is true, here are some of them:
- centos-release-ceph-(hammer|jewel) rpm that deploys repos.
- since we are moving TripleO CI to use tripleo-quickstart, we could
handle repository with Ansible, directly in the roles.

>> There are other benefits too - the tool cleans up old repos so you don't
>> have to worry about accidentally being left with a stray repo file that
>> could cause problems.  You can also install the repos to a non-system path
>> so you can make use of them without actually installing them on the host
>> system.  I'm not entirely clear on the use case for that, but it's something
>> that comes up from time to time.
>>
>
> If it's an rpm, the upgrades should cleanup after themselves.  Do we
> have specific and documented use cases where dropping the repo
> information into an alternative location is required?  Even with rpm,
> can't we just rpm -

[openstack-dev] [tripleo] CI scenarios design - how to add more services

[Emilien Macchi]

== Context

In Newton we added new multinode jobs called "scenarios".
The challenged we tried to solve was "how to test the maximum of
services without overloading the nodes that run tests".

Each scenarios deploys a set of services, which allows us to
horizontally scale the number of scenarios to increase the service
testing coverage.
See the result here:
https://github.com/openstack-infra/tripleo-ci#service-testing-matrix

To implement this model, we took example of Puppet OpenStack CI:
https://github.com/openstack/puppet-openstack-integration#description
We even tried to keep consistent the services/scenarios relations, so
it's consistent and easier to maintain.

Everything was fine until we had to add new services during Ocata cycles.
Because tripleo-ci repository is not branched, adding Barbican service
in the TripleO environment for scenario002 would break Newton CI jobs.
During my vacations, the team created a new scenario, scenario004,
that deploys Barbican and that is only run for Ocata jobs.
I don't think we should proceed this way, and let me explain why.

== Problem

How to scale the number of services that we test without increasing
the number of scenarios and therefore the complexity of maintaining
them on long-term.


== Solutions

The list is not exhaustive, feel free to add more.

1) Re-use experience from Puppet OpenStack CI and have environments
that are in a branched repository.
environments.
In Puppet OpenStack CI, the repository that deploys environments
(puppet-openstack-integration) is branched. So if puppet-barbican is
ready to be tested in Ocata, we'll patch
puppet-openstack-integration/master to start testing it and it won't
break stable jobs.
Like this, we were successfully able to maintain a fair number of
scenarios and keep our coverage increasing over each cycle.

I see 2 sub-options here:

a) Move CI environments and pingtest into
tripleo-heat-templates/environments/ci/(scenarios|pingtest). This repo
is branched and we could add a README to explain these files are used
in CI and we don't guarantee they would work outside TripleO CI tools.
b) Branch tripleo-ci repository. Personally I don't like this solution
because a lot of patches in this repo are not related to OpenStack
versions, which means we would need to backport most of the things
from master.

2) Introduce branch-based scenario tests -
https://review.openstack.org/#/c/396008/
It duplicates a lot of code and it's imho not really effective, though
this solution would correctly works.

3) Introduce a new scenario each time we have new services (like we
did with scenario004).
By adding new scenarios at each release because we test new services
is imho the wrong choice because:
a) it adds complexity in our we're going to maintain these scenarios.
b) it consumes more CI resources that we would need when some patches
have to run all scenarios jobs.


So I gave my opinion on the solutions, discussion is now open and my
hope is that we find a consensus soon, so we can make progress in our
testing coverage.
Thanks,
-- 
Emilien Macchi

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Stepping down from keystone core

[Steve Martinelli]

Marek, thanks for everything you've done in Keystone. It was loads of fun
to develop some of the early federation work with you back in the Icehouse
release! Good luck in whatever the future holds for you!

On Tue, Nov 22, 2016 at 5:18 PM, Marek Denis <
marek.denis+openst...@gmail.com> wrote:

> Hi,
>
> Due to my current responsibilities I cannot serve as keystone core
> anymore. I also feel I should make some space for others who will surely
> bring new quality to the OpenStack Identity Program.
>
> It's been a great journey, I surely learned a lot and improved both my
> technical and soft skills. I can only hope my contributions and reviews
> have been useful and made OpenStack a little bit better.
>
> I wish you all the best in the future.
>
> With kind regards,
> Marek Denis
>
__
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] [tripleo] Ocata schedule and feature freeze

[Emilien Macchi]

Team,

During our weekly meeting, we found useful to send a recap about our
plans to release TripleO Ocata.

== Ocata cycle is *short*.
As a reminder, Ocata cycle is shorter than usual:
https://releases.openstack.org/ocata/schedule.html
Though we accepted a lot of blueprints for this cycle and we are quite
sure some of them won't make it on time.
We'll defer some blueprints to Ocata-3 if we feel like they won't be
implemented by December 12th. During Ocata-3, we'll tag some
blueprints at risk if we feel like they won't make it on time for
final release.

== Feature Freeze exception will be stricter.
At the end of Newton cycle, we accepted (too much) FFEs and we had
some critical stability issues during the release time. We don't want
that anymore.
Blueprints at risk for Ocata-3 will be deferred to Pike and we'll have
the lowest number of FFEs as possible (if not zero).
Instead of burning our time to add as many features as we can during
RC time, we'll rather work on bugfixes and stabilization, so we
improve our release quality.

== Breaking down blueprints
We notices some blueprints were not achievable in one cycle. Please
breakdown your blueprint if you feel like it's not doable in a cycle.
Set some dependencies (in Launchpad) so we can have some dependencies
and correctly schedule the work that needs to be done.
Basically, if your blueprint will be deferred to Pike, please consider
a split so we can have different iterations on the feature we want to
be done.

== Deadline for specs
Some TripleO specs are still under review, while they concern a
feature schedule for this cycle. We've not done a very good job in
reviewing specs on time but we might want to improve ourselves:
https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open
We decided to freeze Ocata specs for Ocata-2 (we will probably change
this limit in the next cycle to be pike-1?).


Please let us know any question or feedback.
Thanks,
-- 
Emilien Macchi

__
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] [TripleO] How to add support for setting 'my_ip' in nova.conf?

[melanie witt]

On Tue, 22 Nov 2016 19:42:32 -0500, Emilien Macchi wrote:

On Tue, Nov 22, 2016 at 6:36 PM, melanie witt  wrote:

In the Nova configuration, the 'my_ip' setting is the IP address the host
uses to connect to the management network [1]. This is the IP Nova uses to
set up iptables rules for the metadata service listening on port 8775.


To correct this part a bit, Nova sets up ibtables rules for the metadata 
service using the 'metadata_host' config setting which defaults to 
$my_ip. There are a handful of config settings that default to $my_ip if 
not specified. But, I think since 'my_ip' is defined as the host's IP on 
the management network, we anyway need to give users the ability to set 
it if they are in a situation where their host has more than one IP.



1) puppet-nova and add the parameter in the class that requires it.
Which Nova service does require it? If all, add the param in init.pp
otherwise in the service class. Ping us on #puppet-openstack if you
need any help, in the case you're not familiar with Puppet. We'll
enjoy to help.


For the metadata service iptables issue, it's only needed by the Nova 
metadata API service. But, I wonder if it should be able to be set for 
any Nova service since any Nova service could make use of the 'my_ip' 
setting and 'my_ip' is defined as "IP on the management network." I'm 
not sure. I need to do a full audit on where all it's used directly and 
indirectly.


Thank you all for the helpful replies!

-melanie

__
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][stable][ptls] Tagging liberty as EOL

[Alex Schultz]

On Tue, Nov 22, 2016 at 5:13 PM, Tony Breeds  wrote:
> On Tue, Nov 22, 2016 at 09:21:00AM -0700, Alex Schultz wrote:
>
>> For the puppet items on the second list[0], the liberty branches of
>> puppet-aodh and puppet-openstack_spec_helper can be EOL'ed.
>
> Thanks I updated the list.  Can I ask why puppet-murano will be left behind?
>

Because I got side tracked with barbican and forgot to include it in
the list. That can be EOL'ed as well.

Thanks,
-Alex

>> I assume
>> puppet-barbican is on that list because it doesn't have a
>> stable/liberty branch since the first release was newton, so that's
>> fine.
>
> Yup that sounds about right.
>
> Yours Tony.
>
> __
> 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] [keystone] Pike PTL

[Matt Fischer]

Steve,

Your tenure as PTL was excellent for the continued stability and
performance of Keystone. You did a great job in taking feedback from
operators also. Thanks for your work!

On Nov 22, 2016 2:06 PM, "De Rose, Ronald"  wrote:

> Thank you Steve, we’ve been lucky to have you as PTL.  Very much
> appreciate your work.
>
>
>
> -Ron
>
>
>
>
>
> *From:* Lance Bragstad [mailto:lbrags...@gmail.com]
> *Sent:* Monday, November 21, 2016 1:23 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [keystone] Pike PTL
>
>
>
> Steve, thanks for all the hard work and dedication over the last 3 cycles.
> I hope you have a nice break and I look forward to working with you on Pike!
>
>
>
> Enjoy you're evenings :)
>
>
>
>
>
>
>
> On Mon, Nov 21, 2016 at 1:38 PM, Steve Martinelli 
> wrote:
>
> one of these days i'll learn how to spell :)
>
>
>
> On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli 
> wrote:
>
> Keystoners,
>
>
>
> I do not intend to run for the PTL position of the Pike development cycle.
> I'm sending this out early so I can work with folks interested in the role,
> If you intend to run for PTL in Pike and are interested in learning the
> ropes (or just want to hear more about what the role means) then shoot me
> an email.
>
>
>
> It's been an unforgettable ride. Being PTL a is very rewarding experience,
> I encourage anyone interested to put your name forward. I'm not going away
> from OpenStack, I just think three terms as PTL has been enough. It'll be
> nice to have my evenings back :)
>
>
>
> To *all* the keystone contributors (cores and non-cores), thank you for
> all your time and commitment. More importantly thank you for putting up
> with my many questions, pings, pokes and -1s. Each of you are amazing and
> together you make an awesome team. It has been an absolute pleasure to
> serve as PTL, thank you for letting me do so.
>
>
> stevemar
>
>
>
>
>
> 
>
>
>
> Thanks for the idea Lana [1]
>
> [1] http://lists.openstack.org/pipermail/openstack-docs/
> 2016-November/009357.html
>
>
>
>
> __
> 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] [TripleO] How to add support for setting 'my_ip' in nova.conf?

[Alex Schultz]

Hey Melanie,


On Tue, Nov 22, 2016 at 4:36 PM, melanie witt  wrote:
> Hi all,
>
> In the Nova configuration, the 'my_ip' setting is the IP address the host
> uses to connect to the management network [1]. This is the IP Nova uses to
> set up iptables rules for the metadata service listening on port 8775.
>
> By default, 'my_ip' is set to the result of oslo_utils.netutils.get_my_ipv4
> which does a getsockname() to determine the host's own IP address. A problem
> can occur if the host is connected to more than one network in the
> environment because the default may not pick the IP connected to the
> management network and the iptables rules for the metadata service will be
> set incorrectly. An example is a host connected to both the management
> network and the network used for the floating IP range.
>
> For this reason, it's necessary to be able to configure 'my_ip' in TripleO
> and currently there's no support for it. I wanted to get initial feedback
> from you all on the idea and if it sounds okay, what's the process for
> adding support for a Nova configuration setting in TripleO?
>

I believe you'll  need to get the my_ip support into the
puppet-nova[0] module. Once it's available in puppet-nova, it would be
a tripleo-heat-template update to configure it.  Something similar was
done in the past for a my_ip configuration for ironic[1][2].

Thanks,
-Alex

[0] https://github.com/openstack/puppet-nova/
[1] https://review.openstack.org/#/c/315261/
[2] 
https://github.com/openstack/tripleo-heat-templates/blob/89f9a3f2e0274169f305a503f642867ef14244e1/puppet/services/ironic-conductor.yaml#L96


> Thanks,
> -melanie
>
> [1]
> https://github.com/openstack/nova/blob/9fd1507/nova/conf/netconf.py#L25-L40
>
> __
> 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] [TripleO] How to add support for setting 'my_ip' in nova.conf?

[Emilien Macchi]

On Tue, Nov 22, 2016 at 6:36 PM, melanie witt  wrote:
> Hi all,
>
> In the Nova configuration, the 'my_ip' setting is the IP address the host
> uses to connect to the management network [1]. This is the IP Nova uses to
> set up iptables rules for the metadata service listening on port 8775.
>
> By default, 'my_ip' is set to the result of oslo_utils.netutils.get_my_ipv4
> which does a getsockname() to determine the host's own IP address. A problem
> can occur if the host is connected to more than one network in the
> environment because the default may not pick the IP connected to the
> management network and the iptables rules for the metadata service will be
> set incorrectly. An example is a host connected to both the management
> network and the network used for the floating IP range.
>
> For this reason, it's necessary to be able to configure 'my_ip' in TripleO
> and currently there's no support for it. I wanted to get initial feedback
> from you all on the idea and if it sounds okay, what's the process for
> adding support for a Nova configuration setting in TripleO?

You would need to patch 2 things:

1) puppet-nova and add the parameter in the class that requires it.
Which Nova service does require it? If all, add the param in init.pp
otherwise in the service class. Ping us on #puppet-openstack if you
need any help, in the case you're not familiar with Puppet. We'll
enjoy to help.

2) tripleo-heat-templates and the Nova composable services that
require this parameter set with Hiera. Same thing, if you need help,
please ping us on #tripleo.

Thanks,

> Thanks,
> -melanie
>
> [1]
> https://github.com/openstack/nova/blob/9fd1507/nova/conf/netconf.py#L25-L40
>
> __
> 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



-- 
Emilien Macchi

__
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][stable][ptls] Tagging liberty as EOL

[Tony Breeds]

On Tue, Nov 22, 2016 at 12:14:30PM -0500, Emilien Macchi wrote:
> In TripleO, we agreed to EOL Liberty for all projects, included those
> in the second list:

> openstack/instack-undercloud
> openstack/tripleo-heat-templates tripleo
> openstack/tripleo-puppet-elements

Added and I've updated the lists.  You can see the chnages at [1]

Yours Tony.

[1] but the nett effect is we're EOL'ing 5 more repos.


signature.asc
Description: 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

Re: [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Tony Breeds]

On Tue, Nov 22, 2016 at 09:21:00AM -0700, Alex Schultz wrote:

> For the puppet items on the second list[0], the liberty branches of
> puppet-aodh and puppet-openstack_spec_helper can be EOL'ed.

Thanks I updated the list.  Can I ask why puppet-murano will be left behind?

> I assume
> puppet-barbican is on that list because it doesn't have a
> stable/liberty branch since the first release was newton, so that's
> fine.

Yup that sounds about right.

Yours Tony.


signature.asc
Description: 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] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

We have weekly Nova API meeting today. The meeting is being held Wednesday
UTC1300 and irc channel is #openstack-meeting-4.

The proposed agenda and meeting details are here:

https://wiki.openstack.org/wiki/Meetings/NovaAPI

Please feel free to add items to the agenda.

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][networking-sfc] No networking-sfc meeting at 1700 UTC on 11/24/2016

[Cathy Zhang]

Hi Everyone,

No meeting on 11/24/2016.

Happy Thanksgiving Holiday!

Cathy
__
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] [TripleO] How to add support for setting 'my_ip' in nova.conf?

[melanie witt]

Hi all,

In the Nova configuration, the 'my_ip' setting is the IP address the 
host uses to connect to the management network [1]. This is the IP Nova 
uses to set up iptables rules for the metadata service listening on port 
8775.


By default, 'my_ip' is set to the result of 
oslo_utils.netutils.get_my_ipv4 which does a getsockname() to determine 
the host's own IP address. A problem can occur if the host is connected 
to more than one network in the environment because the default may not 
pick the IP connected to the management network and the iptables rules 
for the metadata service will be set incorrectly. An example is a host 
connected to both the management network and the network used for the 
floating IP range.


For this reason, it's necessary to be able to configure 'my_ip' in 
TripleO and currently there's no support for it. I wanted to get initial 
feedback from you all on the idea and if it sounds okay, what's the 
process for adding support for a Nova configuration setting in TripleO?


Thanks,
-melanie

[1] 
https://github.com/openstack/nova/blob/9fd1507/nova/conf/netconf.py#L25-L40


__
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] [glance] Ocata specs - final push

[Brian Rosmaita]

The Glance spec freeze for Ocata is 23:59 UTC on Friday 25 November 2016.

Glance cores, please review the proposed specs listed below, and please
keep a watch for submitted revisions.

Spec contributors, please keep an eye on your specs so you can make timely
revisions and resubmit for review.

Need review:
https://review.openstack.org/331489  rolling upgrades
https://review.openstack.org/331740  database strategy for upgrades
https://review.openstack.org/374278  expand/contract migrations with
alembic

Lite-specs needing review:
https://review.openstack.org/375123  "Range" header in requests
https://review.openstack.org/383024  expand metadefs for vz hypervisor
https://review.openstack.org/383067  add 'ploop' disk_format

Not subject to freeze, but could use comments:
https://review.openstack.org/315752  add newton priorities
https://review.openstack.org/396919  community image spec update

Specs/Lite-specs requiring work (not yet ready for review):
https://review.openstack.org/329236  image os auto-detect
https://review.openstack.org/349174  change work_dir ref for tasks
https://review.openstack.org/373896  glance purge to keep deleted IDs



thanks,
brian


__
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][infra] Proposed changes to unit-test setup

[Jeremy Stanley]

On 2016-11-22 19:47:32 +0100 (+0100), Andreas Jaeger wrote:
[...]
> Projects are suggested to add to their developer documents, e.g. the
> README or CONTRIBUTING or TESTING file, the usage of
> tools/testsetup.sh. Developers should be able to use the script to
> set up prerequisites for unit tests locally.
[...]

Note that we've also got a fairly well-received addendum to the
Consistent Testing Guidelines which aligns nicely with this option:

https://review.openstack.org/397502

-- 
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] [Nova] Stepping back

[melanie witt]

On Tue, 22 Nov 2016 11:39:54 -0500, Andrew Laski wrote:

It has been a true pleasure working with you all these past few years
and I'm thankful to have had the opportunity. As I've told people many
times when they ask me what it's like to work on an open source project
like this: working on proprietary software exposes you to smart people
but you're limited to the small set of people within an organization,
working on a project like this exposed me to smart people from many
companies and many parts of the world. I have learned a lot working with
you all. Thanks.


Likewise, Andrew. To echo all the other sentiments, I have truly enjoyed 
working with you and learning from you. Your departure leaves a 
significant void, but I focus on the fact that myself and the Nova 
community were very fortunate for the years you contributed with us. 
Thanks for all your hard work.


I wish you all the best in your next adventure and I'll be happy to see 
you around in #openstack-nova.


-melanie

__
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] Stepping back

[Tony Breeds]

On Tue, Nov 22, 2016 at 11:39:54AM -0500, Andrew Laski wrote:
> I should have sent this weeks ago but I'm a bad person who forgets
> common courtesy. My employment situation has changed in a way that does
> not afford me the necessary time to remain a regular contributor to
> Nova, or the broader OpenStack community. So it is with regret that I
> announce that I will no longer be actively involved in the project.

Andrew,
Otehrs have said it better than I can but I just wanted to echo those
statements.  It's been awesom working with you and I thank you for the time and
support you've given since I started hacking on OpenStack.

Good luck and have fun!

> I will continue to lurk in #openstack-nova, and try to stay minimally
> involved as time allows, so feel free to ping me there.

\0/

Yours Tony.


signature.asc
Description: 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] [keystone] Stepping down from keystone core

[Marek Denis]

Hi,

Due to my current responsibilities I cannot serve as keystone core anymore.
I also feel I should make some space for others who will surely bring new
quality to the OpenStack Identity Program.

It's been a great journey, I surely learned a lot and improved both my
technical and soft skills. I can only hope my contributions and reviews
have been useful and made OpenStack a little bit better.

I wish you all the best in the future.

With kind regards,
Marek Denis
__
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] [TripleO] Proposing Julie Pichon for tripleo core

[Brent Eagles]

On Tue, Nov 22, 2016 at 1:31 PM, Dougal Matthews  wrote:

> Hi all,
>
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
>
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
>
> I think she will be a valuable addition to the review team
>
> Dougal
>

​+1​
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core

[Carlos Camacho Gonzalez]

+1

On Tue, Nov 22, 2016 at 10:05 PM, Marios Andreou  wrote:
> +1
>
> __ sent from my mobile device kindly excuse spacing & spelling __
>
>
> -Original Message-
> From: Dougal Matthews [dou...@redhat.com]
> Received: Tuesday, 22 Nov 2016, 19:06
> To: OpenStack Development Mailing List (not for usage questions)
> [openstack-dev@lists.openstack.org]
> Subject: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core
>
>
> Hi all,
>
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
>
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
>
> I think she will be a valuable addition to the review team
>
> Dougal
>
>
> [1]: http://stackalytics.com/report/contribution/tripleo-group/90
> [2]: https://review.openstack.org/#/c/352852/
>
> __
> 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] [TripleO] Proposing Julie Pichon for tripleo core

[Marios Andreou]

+1 

__ sent from my mobile device kindly excuse spacing & spelling __


-Original Message-
From: Dougal Matthews [dou...@redhat.com]
Received: Tuesday, 22 Nov 2016, 19:06
To: OpenStack Development Mailing List (not for usage questions) 
[openstack-dev@lists.openstack.org]
Subject: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core

Hi all,

I would like to propose we add Julie (jpich) to the TripleO core team for
python-tripleoclient and tripleo-common. This nomination is based partially
on review stats[1] and also my experience with her reviews and
contributions.

Julie has consistently provided thoughtful and detailed reviews since the
start of the Newton cycle. She has made a number of contributions which
improve the CLI and has been extremely helpful with other tasks that don't
often get enough attention (backports, bug triaging/reporting and improving
our processes[2]).

I think she will be a valuable addition to the review team

Dougal


[1]: http://stackalytics.com/report/contribution/tripleo-group/90
[2]: https://review.openstack.org/#/c/352852/
__
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] [TripleO] Proposing Julie Pichon for tripleo core

[James Slagle]

On Tue, Nov 22, 2016 at 12:01 PM, Dougal Matthews  wrote:
> Hi all,
>
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
>
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
>
> I think she will be a valuable addition to the review team

+1

-- 
-- James Slagle
--

__
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] [tripleo] [tripleo-quickstart] Tripleo-Quickstart root privileges

[Gabriele Cerami]

On 22 Nov, Yolanda Robla Mota wrote:
> Hi all
> I wanted to start a thread about the current privileges model for TripleO 
> quickstart.
> Currently there is the assumption that quickstart does not need root 
> privileges after the environment and provision roles. However, this 
> assumption cannot be valid for several use cases.
> In particular, I have the need of creating working directories outside the 
> home directory of the user running quickstart. This can be useful on 
> environments where /home partition is small and cannot be modified (so there 
> is not enough disk space to host TripleO quickstart artifacts there).
> This is the change i'm working on for that use case: 
> https://review.openstack.org/#/c/384892

Hi,

I may suggest a compromise that will allow not to break the model, and
moving forward with you patch.
If you can make it work, you can try to move the working_dir creation
tasks to the provision role.
You already moved working_dir default var to common role, so it should
work.

Any other thoughts ?
Thanks for raising the question.

__
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] [devstack] Specify OpenvSwitch version in local.conf

[Sean M. Collins]

Sean M. Collins wrote:
> zhi wrote:
> > hi, all.
> > 
> > I have a quick question about devstack.
> > 
> > Can I specify OpenvSwitch version in local.conf when during the
> > installation of devstack? I want to OVS 2.6.0 in my devstack. Can I specify
> > it?
> 
> 
> The DevStack plugin for Neutron has a way to build a specific OVS
> version from source
> 
> https://github.com/openstack/neutron/blob/master/devstack/lib/ovs
> 
> However there is not a lot of documentation for how it can be used
> (which really should be fixed).
> 
> I believe it would be something like this in your local.conf:
> 
> 
> enable_plugin neutron https://git.openstack.org/openstack/neutron
> OVS_BRANCH="v2.6.0"
> 
> I haven't tried it locally, but I think that's the idea.
> 


Sorry, you will also need to set:

Q_BUILD_OVS_FROM_GIT=True

-- 
Sean M. Collins

__
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] [devstack] Specify OpenvSwitch version in local.conf

[Sean M. Collins]

zhi wrote:
> hi, all.
> 
> I have a quick question about devstack.
> 
> Can I specify OpenvSwitch version in local.conf when during the
> installation of devstack? I want to OVS 2.6.0 in my devstack. Can I specify
> it?


The DevStack plugin for Neutron has a way to build a specific OVS
version from source

https://github.com/openstack/neutron/blob/master/devstack/lib/ovs

However there is not a lot of documentation for how it can be used
(which really should be fixed).

I believe it would be something like this in your local.conf:


enable_plugin neutron https://git.openstack.org/openstack/neutron
OVS_BRANCH="v2.6.0"

I haven't tried it locally, but I think that's the idea.


-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Pike PTL

[De Rose, Ronald]

Thank you Steve, we’ve been lucky to have you as PTL.  Very much appreciate 
your work.

-Ron


From: Lance Bragstad [mailto:lbrags...@gmail.com]
Sent: Monday, November 21, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [keystone] Pike PTL

Steve, thanks for all the hard work and dedication over the last 3 cycles. I 
hope you have a nice break and I look forward to working with you on Pike!

Enjoy you're evenings :)



On Mon, Nov 21, 2016 at 1:38 PM, Steve Martinelli 
mailto:s.martine...@gmail.com>> wrote:
one of these days i'll learn how to spell :)

On Mon, Nov 21, 2016 at 12:52 PM, Steve Martinelli 
mailto:s.martine...@gmail.com>> wrote:
Keystoners,

I do not intend to run for the PTL position of the Pike development cycle. I'm 
sending this out early so I can work with folks interested in the role, If you 
intend to run for PTL in Pike and are interested in learning the ropes (or just 
want to hear more about what the role means) then shoot me an email.

It's been an unforgettable ride. Being PTL a is very rewarding experience, I 
encourage anyone interested to put your name forward. I'm not going away from 
OpenStack, I just think three terms as PTL has been enough. It'll be nice to 
have my evenings back :)

To *all* the keystone contributors (cores and non-cores), thank you for all 
your time and commitment. More importantly thank you for putting up with my 
many questions, pings, pokes and -1s. Each of you are amazing and together you 
make an awesome team. It has been an absolute pleasure to serve as PTL, thank 
you for letting me do so.

stevemar




Thanks for the idea Lana [1]
[1] 
http://lists.openstack.org/pipermail/openstack-docs/2016-November/009357.html


__
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] [Nova] Stepping back

[Anita Kuno]

On 2016-11-22 11:39 AM, Andrew Laski wrote:

I should have sent this weeks ago but I'm a bad person who forgets
common courtesy. My employment situation has changed in a way that does
not afford me the necessary time to remain a regular contributor to
Nova, or the broader OpenStack community. So it is with regret that I
announce that I will no longer be actively involved in the project.

Fortunately, for those of you reading this, the Nova community is full
of wonderful and talented individuals who have picked up the work that
I'm not able to continue. Primarily this means parts of the cellsv2
effort, for which I am extremely grateful.

It has been a true pleasure working with you all these past few years
and I'm thankful to have had the opportunity. As I've told people many
times when they ask me what it's like to work on an open source project
like this: working on proprietary software exposes you to smart people
but you're limited to the small set of people within an organization,
working on a project like this exposed me to smart people from many
companies and many parts of the world. I have learned a lot working with
you all. Thanks.

I will continue to lurk in #openstack-nova, and try to stay minimally
involved as time allows, so feel free to ping me there.

-Laski



Thanks Andrew, continued good wishes for whatever you do.

Anita.

__
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][infra] Proposed changes to unit-test setup

[Andreas Jaeger]

On 11/22/2016 07:56 PM, John Dickinson wrote:
> 
> 
> On 22 Nov 2016, at 10:47, Andreas Jaeger wrote:
> 
>> When we (infra) changed the unit test jobs to not set up databases by
>> default, we created special python-db and tox-db jobs that set up both
>> MySQL and PostgreSQL databases. And that complicated the setup of those
>> projects and lead to problems like setting projects up via bindep for
>> both databases even if one was used.
>>
>> We had last week an IRC discussion [1] and came up with the following
>> approach:
>>
>>   Projects can use a tools/test-setup.sh script that is called from
>>   our unit test (tox, python27, python34, python35) targets. The
>>   script is executed as root and should set up the needed databases -
>>   or whatever is needed. The script needs to reside in the repository -
>>   and thus might need to get backported to older branches.
>>
>>   This setup should be used for any kind of repo specific unit test
>>   setup.
>>
>>   Projects are suggested to add to their developer documents, e.g. the
>>   README or CONTRIBUTING or TESTING file, the usage of
>>   tools/testsetup.sh. Developers should be able to use the script to
>>   set up prerequisites for unit tests locally.
>>
>>   Long term goal is for projects to not use the -db jobs anymore, new
>>   changes for them should not be accepted.
>>
>> This is implemented in project-config [2], an example usage in
>> nodepool [3,4], which leads to a cleanup [5].
>>
>> Further investigation shows that the special searchlight setup can be
>> solved with the same approach (searchlight change [6], project-config
>> [7]). Here it's interesting to note that moving the setup in the
>> repository, found a problem: The repo needs elasticsearch 1 for
>> liberty and 2 for newer branches, this can now be done inside the
>> repository.
>>
>> The xfs TMPDIR setup of swift [2] could been done in general this way as
>> well but that change needs to set TMPDIR for the unittests, passing
>> information from the set up builder to the tox builder. This is
>> currently not possible using only the proposed solution, and so would
>> still require a custom tox job. Alternative, this could be changed with
>> some other way of passing the value of TMPDIR between these different
>> invocations.
> 
> (actually link [10])

Indeed, thanks for correcting.

> This sounds like a great idea that I would have loved to have in place a few 
> weeks ago!
> 
> One question: is there a limit to which tox environments will call this 
> in-repo script? Above you list a few, but Swift and other projects have 
> repo-specific environments that would need the setup as well. How will that 
> work?

So far it's the templates I mentioned. The custom swift jobs are not
setup this way and I'm fine with removing the custom jobs and use the
default jobs again.

In general, if additional jobs need the change from [2], we can add them
- let's discuss this one by one in a review,

Andreas

> 
>>
>> Today, a change was proposed [8,9] that would setup docker for kolla
>> and kolla-ansible. I suggest to not merge it and instead use the same
>> approach here.
>>
>> Credits for the proposal go to Jeremy - and this got triggered by
>> comments by Jim. Thanks!
>>
>> Andreas
>>
>> [1]
>> http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-11-17.log.html#t2016-11-17T15:07:38
>>
>> [2] https://review.openstack.org/399105
>> [3] https://review.openstack.org/399079
>> [4] https://review.openstack.org/399177
>> [5] https://review.openstack.org/399180
>> [6] https://review.openstack.org/399159
>> [7] https://review.openstack.org/399169
>> [8] https://review.openstack.org/400128
>> [9] https://review.openstack.org/400474
>> [10] https://review.openstack.org/394600
>> -- 
>>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>>HRB 21284 (AG Nürnberg)
>> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>>
>> __
>> 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


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[openstack-dev] [neutron] Drivers meeting on Nov 24th cancelled

[Armando M.]

Happy Thanksgiving!

Armando
__
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-Infra] [infra][neutron] Intel NFV CI voting permission in Neutron

[Armando M.]

On 22 November 2016 at 06:09, Znoinski, Waldemar <
waldemar.znoin...@intel.com> wrote:

>
>
>  >-Original Message-
>  >From: Jeremy Stanley [mailto:fu...@yuggoth.org]
>  >Sent: Monday, November 14, 2016 3:40 PM
>  >To: openstack-in...@lists.openstack.org; openstack-dev@lists.openstack.
> org
>  >Subject: Re: [openstack-dev] [OpenStack-Infra] [infra][neutron] Intel
> NFV CI
>  >voting permission in Neutron
>  >
>  >On 2016-11-14 10:44:42 + (+), Znoinski, Waldemar wrote:
>  >> I would like to acquire voting (+/-1 Verified) permission for our
>  >> Intel NFV CI.
>  >[...]
>  >
>  >The requested permission is configured by addition to
>  >https://review.openstack.org/#/admin/groups/neutron-ci which is
>  >controlled by the members of the
>  >https://review.openstack.org/#/admin/groups/neutron-release group.
>  >The Infra team tries not to be involved in these decisions and instead
> prefers
>  >to leave them up to the project team(s) involved.
> [WZ] thanks for explanation Jeremy, that was my intention - the ask is to
> Neutron(-release) guys, with Infra as FYI
>

done


>
>  >
>  >> 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.
>  >[...]
>  >
>  >This seems wholly inappropriate for a public mailing list. I strongly
>  >recommend not sending messages to our mailing lists in which you strictly
>  >prohibit review or distribution by others, as it is guaranteed to happen
> and
>  >we cannot prevent that (nor would we want to).
> [WZ] requested removal of that footer, thanks
>
>  >--
>  >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 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][infra] Proposed changes to unit-test setup

[John Dickinson]

On 22 Nov 2016, at 10:47, Andreas Jaeger wrote:

> When we (infra) changed the unit test jobs to not set up databases by
> default, we created special python-db and tox-db jobs that set up both
> MySQL and PostgreSQL databases. And that complicated the setup of those
> projects and lead to problems like setting projects up via bindep for
> both databases even if one was used.
>
> We had last week an IRC discussion [1] and came up with the following
> approach:
>
>   Projects can use a tools/test-setup.sh script that is called from
>   our unit test (tox, python27, python34, python35) targets. The
>   script is executed as root and should set up the needed databases -
>   or whatever is needed. The script needs to reside in the repository -
>   and thus might need to get backported to older branches.
>
>   This setup should be used for any kind of repo specific unit test
>   setup.
>
>   Projects are suggested to add to their developer documents, e.g. the
>   README or CONTRIBUTING or TESTING file, the usage of
>   tools/testsetup.sh. Developers should be able to use the script to
>   set up prerequisites for unit tests locally.
>
>   Long term goal is for projects to not use the -db jobs anymore, new
>   changes for them should not be accepted.
>
> This is implemented in project-config [2], an example usage in
> nodepool [3,4], which leads to a cleanup [5].
>
> Further investigation shows that the special searchlight setup can be
> solved with the same approach (searchlight change [6], project-config
> [7]). Here it's interesting to note that moving the setup in the
> repository, found a problem: The repo needs elasticsearch 1 for
> liberty and 2 for newer branches, this can now be done inside the
> repository.
>
> The xfs TMPDIR setup of swift [2] could been done in general this way as
> well but that change needs to set TMPDIR for the unittests, passing
> information from the set up builder to the tox builder. This is
> currently not possible using only the proposed solution, and so would
> still require a custom tox job. Alternative, this could be changed with
> some other way of passing the value of TMPDIR between these different
> invocations.

(actually link [10])

This sounds like a great idea that I would have loved to have in place a few 
weeks ago!

One question: is there a limit to which tox environments will call this in-repo 
script? Above you list a few, but Swift and other projects have repo-specific 
environments that would need the setup as well. How will that work?


>
> Today, a change was proposed [8,9] that would setup docker for kolla
> and kolla-ansible. I suggest to not merge it and instead use the same
> approach here.
>
> Credits for the proposal go to Jeremy - and this got triggered by
> comments by Jim. Thanks!
>
> Andreas
>
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-11-17.log.html#t2016-11-17T15:07:38
>
> [2] https://review.openstack.org/399105
> [3] https://review.openstack.org/399079
> [4] https://review.openstack.org/399177
> [5] https://review.openstack.org/399180
> [6] https://review.openstack.org/399159
> [7] https://review.openstack.org/399169
> [8] https://review.openstack.org/400128
> [9] https://review.openstack.org/400474
> [10] https://review.openstack.org/394600
> -- 
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
> __
> 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: 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

[openstack-dev] [neutron] oslo liasion

[Armando M.]

Hi neutrinos,

I would like to announce Victor Morales, aka electrocucaracha as our oslo
liasion [1].

If you would like to be help in any of the liasion capacities available,
please review [1] and reach out to me.

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo
__
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][infra] Proposed changes to unit-test setup

[Andreas Jaeger]

When we (infra) changed the unit test jobs to not set up databases by
default, we created special python-db and tox-db jobs that set up both
MySQL and PostgreSQL databases. And that complicated the setup of those
projects and lead to problems like setting projects up via bindep for
both databases even if one was used.

We had last week an IRC discussion [1] and came up with the following
approach:

  Projects can use a tools/test-setup.sh script that is called from
  our unit test (tox, python27, python34, python35) targets. The
  script is executed as root and should set up the needed databases -
  or whatever is needed. The script needs to reside in the repository -
  and thus might need to get backported to older branches.

  This setup should be used for any kind of repo specific unit test
  setup.

  Projects are suggested to add to their developer documents, e.g. the
  README or CONTRIBUTING or TESTING file, the usage of
  tools/testsetup.sh. Developers should be able to use the script to
  set up prerequisites for unit tests locally.

  Long term goal is for projects to not use the -db jobs anymore, new
  changes for them should not be accepted.

This is implemented in project-config [2], an example usage in
nodepool [3,4], which leads to a cleanup [5].

Further investigation shows that the special searchlight setup can be
solved with the same approach (searchlight change [6], project-config
[7]). Here it's interesting to note that moving the setup in the
repository, found a problem: The repo needs elasticsearch 1 for
liberty and 2 for newer branches, this can now be done inside the
repository.

The xfs TMPDIR setup of swift [2] could been done in general this way as
well but that change needs to set TMPDIR for the unittests, passing
information from the set up builder to the tox builder. This is
currently not possible using only the proposed solution, and so would
still require a custom tox job. Alternative, this could be changed with
some other way of passing the value of TMPDIR between these different
invocations.

Today, a change was proposed [8,9] that would setup docker for kolla
and kolla-ansible. I suggest to not merge it and instead use the same
approach here.

Credits for the proposal go to Jeremy - and this got triggered by
comments by Jim. Thanks!

Andreas

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-11-17.log.html#t2016-11-17T15:07:38

[2] https://review.openstack.org/399105
[3] https://review.openstack.org/399079
[4] https://review.openstack.org/399177
[5] https://review.openstack.org/399180
[6] https://review.openstack.org/399159
[7] https://review.openstack.org/399169
[8] https://review.openstack.org/400128
[9] https://review.openstack.org/400474
[10] https://review.openstack.org/394600
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [TripleO] Proposing Julie Pichon for tripleo core

[Dan Trainor]

On Tue, Nov 22, 2016 at 11:36 AM, Michele Baldessari 
wrote:

> On Tue, Nov 22, 2016 at 05:01:49PM +, Dougal Matthews wrote:
> > Hi all,
> >
> > I would like to propose we add Julie (jpich) to the TripleO core team for
> > python-tripleoclient and tripleo-common. This nomination is based
> partially
> > on review stats[1] and also my experience with her reviews and
> > contributions.
> >
> > Julie has consistently provided thoughtful and detailed reviews since the
> > start of the Newton cycle. She has made a number of contributions which
> > improve the CLI and has been extremely helpful with other tasks that
> don't
> > often get enough attention (backports, bug triaging/reporting and
> improving
> > our processes[2]).
> >
> > I think she will be a valuable addition to the review team
>

+1 couldn't agree more
__
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] [TripleO] Proposing Julie Pichon for tripleo core

[Michele Baldessari]

On Tue, Nov 22, 2016 at 05:01:49PM +, Dougal Matthews wrote:
> Hi all,
> 
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
> 
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
> 
> I think she will be a valuable addition to the review team

+1

-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

__
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] [tripleo] POC patch for using tripleo-repos for repo setup

[Alex Schultz]

On Tue, Nov 22, 2016 at 11:06 AM, Ben Nemec  wrote:
>
>
> On 11/21/2016 05:26 PM, Alex Schultz wrote:
>>
>> On Mon, Nov 21, 2016 at 2:57 PM, Ben Nemec  wrote:
>>>
>>> Hi,
>>>
>>> I have a POC patch[1] up to demonstrate the use of the tripleo-repos tool
>>> [2] as a replacement for most of tripleo.sh --repo-setup.  It has now
>>> passed
>>> all of the CI jobs so I wanted to solicit some feedback.
>>>
>>> There are a few changes related to repo naming because the tool names
>>> repo
>>> files based on the repo name rather than always calling them something
>>> generic like delorean.repo.  I think it's less confusing to have the
>>> delorean-newton repo file named delorean-newton.repo, but I'm open to
>>> discussion on that.
>>>
>>> If no one has any major objections to how the tool looks/works right now,
>>> I'll proceed with the work to get it imported into the openstack
>>> namespace
>>> as part of TripleO.  We can always iterate on it after import too, of
>>> course, so this isn't a speak now or forever hold your peace situation.
>>> :-)
>>>
>>
>> Why a python standalone application for the management of specifically
>> (and only?) tripleo repositories.  It seems we should be trying to
>> leverage existing tooling and not hiding the problem behind a python
>> app.  It's not that I enjoy the current method described in the spec
>> (3 curls, 1 sed, 1 bash thing, and a yum install) but it seems like to
>> write 586 lines of python and tests might be the wrong approach.
>> Would it be better to just devote some time to rpm generation for
>> these and deliver it in discrete RPMs?  'yum install
>> http://tripleo.org/repos-current.rpm' seems way more straight forward.
>
>
> That's essentially trading "curl ..." for "yum install ..." in the docs.
> The repo rpm would have to be part of the delorean build so you'd still have
> to be pointing people at a delorean repo.  It would also still require code
> changes somewhere to handle the mixed current/current-tripleo setup that we
> run for development and test. Given how specific to tripleo that is I'm not
> sure how much sense it makes to implement it elsewhere.
>

I'm asking because essentially we're delivering basically static repo
files.  Which should really be done via RPM. Upgrades and cleanups are
already well established practices between RPMs.  I'm not seeing the
reasoning why a python app.  I thought about this further and I'm not
sure why this should be done on the client side via an app rather than
at repository build/promotion time.  As long as we're including the
repo rpm, we can always create simple 302 redirects from a webserver
to get the latest version.  I don't see why we should introduce a
client tool for this when the action is really on the repository
packaging side.   This seems odd doing system configuration via a
python script rather than a configuration management tool like
ansible, puppet or even just packaging.

> There are also optional ceph and opstool repos and at least ceph needs to
> match the version of OpenStack being installed.  Sure, you could just
> document all that logic, but then the logic has to be reimplemented in CI
> anyway so you end up with code to maintain either way.  At least with one
> tool the logic is shared between the user and dev/test paths, which is one
> of the primary motivations behind it.  Pretty much every place that we have
> divergence between what users do and what developers do becomes a pain point
> for users because developers only fix the things they actually use.
>

Yes we should not have a different path for dev/test vs operational
deployments, but I'm not convinced we need to add a custom python tool
to handle this only for tripleo.  There are already established
patterns of repository rpm delivery and installation via existing
tools.  What are we getting from this tool that can't already be done?

> There are other benefits too - the tool cleans up old repos so you don't
> have to worry about accidentally being left with a stray repo file that
> could cause problems.  You can also install the repos to a non-system path
> so you can make use of them without actually installing them on the host
> system.  I'm not entirely clear on the use case for that, but it's something
> that comes up from time to time.
>

If it's an rpm, the upgrades should cleanup after themselves.  Do we
have specific and documented use cases where dropping the repo
information into an alternative location is required?  Even with rpm,
can't we just rpm --prefix=/some/other/location?

Thanks,
-Alex


>
>>
>> Thanks,
>> -Alex
>>
>>> 1: https://review.openstack.org/#/c/395813
>>> 2:
>>>
>>> https://specs.openstack.org/openstack/tripleo-specs/specs/policy/tripleo-repos.html
>>> (note that this spec was mistakenly submitted as a policy, it will be
>>> moving
>>> to the ocata directory soon)
>>>
>>> Thanks.
>>>
>>> -Ben
>>>
>>>
>>> __
>>> OpenStack Developmen

[openstack-dev] [release] 25 Nov team meeting canceled

[Doug Hellmann]

Several of us will be on holiday this week and we don't have anything
pressing to discuss, so let's skip this meeting and resume next
week on 2 December.

Doug

__
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] [tripleo] POC patch for using tripleo-repos for repo setup

[Ben Nemec]

On 11/21/2016 05:26 PM, Alex Schultz wrote:

On Mon, Nov 21, 2016 at 2:57 PM, Ben Nemec  wrote:

Hi,

I have a POC patch[1] up to demonstrate the use of the tripleo-repos tool
[2] as a replacement for most of tripleo.sh --repo-setup.  It has now passed
all of the CI jobs so I wanted to solicit some feedback.

There are a few changes related to repo naming because the tool names repo
files based on the repo name rather than always calling them something
generic like delorean.repo.  I think it's less confusing to have the
delorean-newton repo file named delorean-newton.repo, but I'm open to
discussion on that.

If no one has any major objections to how the tool looks/works right now,
I'll proceed with the work to get it imported into the openstack namespace
as part of TripleO.  We can always iterate on it after import too, of
course, so this isn't a speak now or forever hold your peace situation. :-)



Why a python standalone application for the management of specifically
(and only?) tripleo repositories.  It seems we should be trying to
leverage existing tooling and not hiding the problem behind a python
app.  It's not that I enjoy the current method described in the spec
(3 curls, 1 sed, 1 bash thing, and a yum install) but it seems like to
write 586 lines of python and tests might be the wrong approach.
Would it be better to just devote some time to rpm generation for
these and deliver it in discrete RPMs?  'yum install
http://tripleo.org/repos-current.rpm' seems way more straight forward.


That's essentially trading "curl ..." for "yum install ..." in the docs. 
 The repo rpm would have to be part of the delorean build so you'd 
still have to be pointing people at a delorean repo.  It would also 
still require code changes somewhere to handle the mixed 
current/current-tripleo setup that we run for development and test. 
Given how specific to tripleo that is I'm not sure how much sense it 
makes to implement it elsewhere.


There are also optional ceph and opstool repos and at least ceph needs 
to match the version of OpenStack being installed.  Sure, you could just 
document all that logic, but then the logic has to be reimplemented in 
CI anyway so you end up with code to maintain either way.  At least with 
one tool the logic is shared between the user and dev/test paths, which 
is one of the primary motivations behind it.  Pretty much every place 
that we have divergence between what users do and what developers do 
becomes a pain point for users because developers only fix the things 
they actually use.


There are other benefits too - the tool cleans up old repos so you don't 
have to worry about accidentally being left with a stray repo file that 
could cause problems.  You can also install the repos to a non-system 
path so you can make use of them without actually installing them on the 
host system.  I'm not entirely clear on the use case for that, but it's 
something that comes up from time to time.




Thanks,
-Alex


1: https://review.openstack.org/#/c/395813
2:
https://specs.openstack.org/openstack/tripleo-specs/specs/policy/tripleo-repos.html
(note that this spec was mistakenly submitted as a policy, it will be moving
to the ocata directory soon)

Thanks.

-Ben

__
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] [TripleO] Proposing Julie Pichon for tripleo core

[John Trowbridge]

On 11/22/2016 12:01 PM, Dougal Matthews wrote:
> Hi all,
> 
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
> 
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
> 
> I think she will be a valuable addition to the review team
> 
> Dougal
> 
> 
> [1]: http://stackalytics.com/report/contribution/tripleo-group/90
> [2]: https://review.openstack.org/#/c/352852/
> 
> 
> 
> __
> 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
> 

+1

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core

[Steven Hardy]

On Tue, Nov 22, 2016 at 05:01:49PM +, Dougal Matthews wrote:
>Hi all,
> 
>I would like to propose we add Julie (jpich) to the TripleO core team for
>python-tripleoclient and tripleo-common. This nomination is based
>partially on review stats[1] and also my experience with her reviews and
>contributions.
> 
>Julie has consistently provided thoughtful and detailed reviews since the
>start of the Newton cycle. She has made a number of contributions which
>improve the CLI and has been extremely helpful with other tasks that don't
>often get enough attention (backports, bug triaging/reporting and
>improving our processes[2]).
> 
>I think she will be a valuable addition to the review team

+1!

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Proposing Julie Pichon for tripleo core

[Dan Sneddon]

On 11/22/2016 09:01 AM, Dougal Matthews wrote:
> Hi all,
> 
> I would like to propose we add Julie (jpich) to the TripleO core team
> for python-tripleoclient and tripleo-common. This nomination is based
> partially on review stats[1] and also my experience with her reviews
> and contributions.
> 
> Julie has consistently provided thoughtful and detailed reviews since
> the start of the Newton cycle. She has made a number of contributions
> which improve the CLI and has been extremely helpful with other tasks
> that don't often get enough attention (backports, bug
> triaging/reporting and improving our processes[2]).
> 
> I think she will be a valuable addition to the review team
> 
> Dougal
> 
> 
> [1]: http://stackalytics.com/report/contribution/tripleo-group/90
> [2]: https://review.openstack.org/#/c/352852/
> 
> 
> __
> 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
> 

+1!

-- 
Dan Sneddon |  Senior Principal OpenStack Engineer
dsned...@redhat.com |  redhat.com/openstack
dsneddon:irc|  @dxs:twitter

__
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] [TripleO] Proposing Julie Pichon for tripleo core

[Giulio Fidente]

On 11/22/2016 06:01 PM, Dougal Matthews wrote:

Hi all,

I would like to propose we add Julie (jpich) to the TripleO core team
for python-tripleoclient and tripleo-common. This nomination is based
partially on review stats[1] and also my experience with her reviews and
contributions.

Julie has consistently provided thoughtful and detailed reviews since
the start of the Newton cycle. She has made a number of contributions
which improve the CLI and has been extremely helpful with other tasks
that don't often get enough attention (backports, bug triaging/reporting
and improving our processes[2]).

I think she will be a valuable addition to the review team


Thanks Dougal and Julie, +1
--
Giulio Fidente
GPG KEY: 08D733BA

__
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] [TripleO] Proposing Julie Pichon for tripleo core

[Ryan Brady]

On Tue, Nov 22, 2016 at 12:01 PM, Dougal Matthews  wrote:

> Hi all,
>
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
>
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
>
> I think she will be a valuable addition to the review team
>

+1!


>
> Dougal
>
>
> [1]: http://stackalytics.com/report/contribution/tripleo-group/90
> [2]: https://review.openstack.org/#/c/352852/
>
> __
> 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
>
>


-- 
Ryan Brady
Cloud Engineering
rbr...@redhat.com
919.890.8925
__
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] Stepping back

[Dan Smith]

> It has been a true pleasure working with you all these past few years
> and I'm thankful to have had the opportunity. As I've told people many
> times when they ask me what it's like to work on an open source project
> like this: working on proprietary software exposes you to smart people
> but you're limited to the small set of people within an organization,
> working on a project like this exposed me to smart people from many
> companies and many parts of the world. I have learned a lot working with
> you all. Thanks.

Andrew, thanks so much for all your contributions to the Nova community
over the years. I have so enjoyed working with you, learning from you,
and making nova better alongside you. I'm really sad to see you go, but
purely from a selfish point of view. I know you will go on to make other
software and communities better, and I wish you the best of luck.

I'll leave you with a snippet from my #openstack-nova archives, on a
Friday in late 2013, where I think you had just figured out something
that I broke in those early days of objectification. I stand by my
statement:

Oct 25 11:05:13 bearhands: my official opinion is that
you should hang on to lascii, just FYI

--Dan

__
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] [TripleO] Proposing Julie Pichon for tripleo core

[Emilien Macchi]

On Tue, Nov 22, 2016 at 12:01 PM, Dougal Matthews  wrote:
> Hi all,
>
> I would like to propose we add Julie (jpich) to the TripleO core team for
> python-tripleoclient and tripleo-common. This nomination is based partially
> on review stats[1] and also my experience with her reviews and
> contributions.
>
> Julie has consistently provided thoughtful and detailed reviews since the
> start of the Newton cycle. She has made a number of contributions which
> improve the CLI and has been extremely helpful with other tasks that don't
> often get enough attention (backports, bug triaging/reporting and improving
> our processes[2]).
>
> I think she will be a valuable addition to the review team

I agree, big +1 here.
Thanks!

> Dougal
>
>
> [1]: http://stackalytics.com/report/contribution/tripleo-group/90
> [2]: https://review.openstack.org/#/c/352852/
>
> __
> 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
>



-- 
Emilien Macchi

__
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] Removing Ekaterina Chernova and Filip Blaha from cores

[Kirill Zaitsev]

Implemented

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

Le 17 novembre 2016 à 18:28:19, Kirill Zaitsev (kzait...@mirantis.com) a écrit:

I’m proposing to remove Ekaterina Chernova and Filip Blaha from the list of 
murano cores. They both have been very active in the previous cycles, but their 
focus have shifted and we haven’t seen much activity in Newton and Ocata.
If the situation would change — I would be very happy to welcome back both 
Ekaterina and Filip to murano core team. I would also like to express my thanks 
for all the hard work Ekaterina and Filip has put into murano. Hope to see you 
back in future.

You can find statistics info here 
http://stackalytics.com/?module=murano-group&release=all&user_id=filip.bl...@hpe.com
and here: 
http://stackalytics.com/?module=murano-group&release=all&user_id=efedorova 
Ekaterina is also core in murano-milestone (i.e. stable branches), so this also 
implies removing her from the group too.

If you have any thoughts or objections to this decision — please voice them.

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

signature.asc
Description: Message signed with OpenPGP using AMPGpg
__
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] Nominating Felipe Monteiro for murano core

[Kirill Zaitsev]

Done.

Congratulations Felipe! =)

-- 
Kirill Zaitsev
Murano Project Tech Lead
Software Engineer at
Mirantis, Inc

Le 17 novembre 2016 à 18:06:47, Serg Melikyan (smelik...@mirantis.com) a écrit:

+1

On Thu, Nov 17, 2016 at 5:54 AM, Alexander Tivelkov  
wrote:
+1

On Thu, Nov 17, 2016 at 4:29 PM Kirill Zaitsev  wrote:
Hello team, I would like to nominate Felipe for murano core.
His and his teams work on increasing murano unit test coverage in Newton and 
Ocata has allowed us to reach astonishing 85%
I would like to personally thank Felipe for his dedication to making murano a 
more mature and stable project!
You can view statistics for his work here: 
http://stackalytics.com/?metric=commits&release=ocata&module=murano-group&user_id=felipe.monte...@att.com

Please respond with +1/-1 on the candidate =)

-- 
Kirill Zaitsev
Sent with Airmail
__
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,
Alexander Tivelkov

__
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, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
__  
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 AMPGpg
__
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][stable][ptls] Tagging liberty as EOL

[Emilien Macchi]

Hey Tony,

On Mon, Nov 21, 2016 at 9:35 PM, Tony Breeds  wrote:
> Hi all,
> I'm late in sending this announement, but I'm glad to see several projects
> have already requested EOL releases to make it trivial and obvious where to
> apply the tag.
>
> I'm proposing to EOL all projects that meet one or more of the following
> criteria:
>
> - The project is openstack-dev/devstack, openstack-dev/grenade or
>   openstack/requirements
> - The project has the 'check-requirements' job listed as a template in
>   project-config:zuul/layout.yaml
> - The project gates with either devstack or grenade jobs
> - The project is listed in governance:reference/projects.yaml and is tagged
>   with 'stable:follows-policy'.
>
>
> Some statistics:
> All Repos  : 1493 (covered in zuul/layout.yaml)
> Checked Repos  :  406 (match one or more of the above 
> criteria)
> Repos with liberty branches:  305
> EOL Repos  :  171 (repos that match the criteria *and* 
> have
>a liberty branch) [1]
> NOT EOL Repos  :  134 (repos with a liberty branch but
>otherwise do not match) [2]
> DSVM Repos (staying)   :   68 (repos that use dsvm but don't have
>liberty branches)
> Open Reviews   :   94 (reviews to close)
>
>
> Please look over both lists by 2016-11-27 00:00 UTC and let me know if:
> - A project is in list 1 and *really* *really* wants to opt *OUT* of EOLing 
> and
>   why.  Note doing this will amost certainly reduce the testing coverage you
>   have in the gate.
> - A project is in list 2 that would like to opt *IN* to tagging/EOLing
>
> Any projects that will be EOL'd will need all open reviews abandoned before it
> can be processed.  I'm very happy to do this, or if I don't have permissios to
> do it ask a gerrit admin to do it.

In TripleO, we agreed to EOL Liberty for all projects, included those
in the second list:
openstack/instack-undercloud
openstack/tripleo-heat-templates tripleo
openstack/tripleo-puppet-elements

I'll make sure today that all open reviews are merged or abandoned.
Please let me know if you need any help for tagging & zuul things.

Thanks,

> I'll batch the removal of the stable/liberty branches between Nov 28th and Dec
> 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup 
> zuul/layout.yaml
> to remove liberty exclusions and jobs.
>
> Yours Tony.
>
> [1] 
> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L1
> [2] 
> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L181
>
> __
> 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
>

-- 
Emilien Macchi

__
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] [trove] Weekly meeting canceled for Thanksgiving holiday week

[Amrith Kumar]

As tomorrow (Wednesday) is a light day in the US at least, and given that
other projects appear to be doing this as well, I'm going to cancel the
Trove weekly meeting for tomorrow (23rd).

 

I'm sure all of you will spend the extra hour doing reviews and preparing
your Turkey.

 

-amrith



smime.p7s
Description: S/MIME cryptographic 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] [Neutron][networking-*] Refactor of segments db

[Anna Taraday]

Hello everyone!
I'm working on implementation new engine facade in Neutron. [1] We have a
number of functions that expect to get session as one the arguments.
Passing session is not correct and this prevents of usage new enginefacade
which expect context to be passed and session to be injected in current
context. And also when we use new enginefacade the concept of a
"subtransaction" is completely different. So, I made refactor patch for
Neutron [2]. As these changes affect other projects that use these
functions, I propose patches to fix them [3].
Kindly, please be aware of these changes.
[1] - https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch [2]
- https://review.openstack.org/#/c/398873/
[4] -
https://review.openstack.org/#/q/message:%22Change+passing+session+to+context+in+segments+db+functions%22
-- 
Regards,
Ann Taraday
__
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] [TripleO] Proposing Julie Pichon for tripleo core

[Dougal Matthews]

Hi all,

I would like to propose we add Julie (jpich) to the TripleO core team for
python-tripleoclient and tripleo-common. This nomination is based partially
on review stats[1] and also my experience with her reviews and
contributions.

Julie has consistently provided thoughtful and detailed reviews since the
start of the Newton cycle. She has made a number of contributions which
improve the CLI and has been extremely helpful with other tasks that don't
often get enough attention (backports, bug triaging/reporting and improving
our processes[2]).

I think she will be a valuable addition to the review team

Dougal


[1]: http://stackalytics.com/report/contribution/tripleo-group/90
[2]: https://review.openstack.org/#/c/352852/
__
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] Stepping back

[Matt Riedemann]

On 11/22/2016 10:39 AM, Andrew Laski wrote:

I should have sent this weeks ago but I'm a bad person who forgets
common courtesy. My employment situation has changed in a way that does
not afford me the necessary time to remain a regular contributor to
Nova, or the broader OpenStack community. So it is with regret that I
announce that I will no longer be actively involved in the project.

Fortunately, for those of you reading this, the Nova community is full
of wonderful and talented individuals who have picked up the work that
I'm not able to continue. Primarily this means parts of the cellsv2
effort, for which I am extremely grateful.

It has been a true pleasure working with you all these past few years
and I'm thankful to have had the opportunity. As I've told people many
times when they ask me what it's like to work on an open source project
like this: working on proprietary software exposes you to smart people
but you're limited to the small set of people within an organization,
working on a project like this exposed me to smart people from many
companies and many parts of the world. I have learned a lot working with
you all. Thanks.

I will continue to lurk in #openstack-nova, and try to stay minimally
involved as time allows, so feel free to ping me there.

-Laski

__
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



Andrew, thanks for all you've done over the years. You were around when 
I got started in Nova and I learned a lot from you over that time. I'm 
happy to have gotten to know you more over that time, because another 
thing that's great about working in this community is not just working 
with others, but actually getting to know them in person and becoming 
friends with people you otherwise wouldn't have met. I wish you all the 
best.


--

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] [Nova] Stepping back

[Diana Clarke]

Thank you so much for your reviews over the past year! I wish you all
the best at the new gig.

You will be missed,

--diana

On Tue, Nov 22, 2016 at 11:39 AM, Andrew Laski  wrote:
> I should have sent this weeks ago but I'm a bad person who forgets
> common courtesy. My employment situation has changed in a way that does
> not afford me the necessary time to remain a regular contributor to
> Nova, or the broader OpenStack community. So it is with regret that I
> announce that I will no longer be actively involved in the project.
>
> Fortunately, for those of you reading this, the Nova community is full
> of wonderful and talented individuals who have picked up the work that
> I'm not able to continue. Primarily this means parts of the cellsv2
> effort, for which I am extremely grateful.
>
> It has been a true pleasure working with you all these past few years
> and I'm thankful to have had the opportunity. As I've told people many
> times when they ask me what it's like to work on an open source project
> like this: working on proprietary software exposes you to smart people
> but you're limited to the small set of people within an organization,
> working on a project like this exposed me to smart people from many
> companies and many parts of the world. I have learned a lot working with
> you all. Thanks.
>
> I will continue to lurk in #openstack-nova, and try to stay minimally
> involved as time allows, so feel free to ping me there.
>
> -Laski
>
> __
> 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] [Nova] Stepping back

[Jay Pipes]

On 11/22/2016 11:39 AM, Andrew Laski wrote:

I should have sent this weeks ago but I'm a bad person who forgets
common courtesy. My employment situation has changed in a way that does
not afford me the necessary time to remain a regular contributor to
Nova, or the broader OpenStack community. So it is with regret that I
announce that I will no longer be actively involved in the project.

Fortunately, for those of you reading this, the Nova community is full
of wonderful and talented individuals who have picked up the work that
I'm not able to continue. Primarily this means parts of the cellsv2
effort, for which I am extremely grateful.

It has been a true pleasure working with you all these past few years
and I'm thankful to have had the opportunity. As I've told people many
times when they ask me what it's like to work on an open source project
like this: working on proprietary software exposes you to smart people
but you're limited to the small set of people within an organization,
working on a project like this exposed me to smart people from many
companies and many parts of the world. I have learned a lot working with
you all. Thanks.

I will continue to lurk in #openstack-nova, and try to stay minimally
involved as time allows, so feel free to ping me there.


Andrew, thank you for the incredible contributions you made to the Nova 
project over the years. It was my honor and pleasure to work closely 
with you.


I know you will excel at your next adventure, and I wish you all the 
luck in the world "up in the clouds" :)


Best,
-jay

__
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] [Nova] Stepping back

[Andrew Laski]

I should have sent this weeks ago but I'm a bad person who forgets
common courtesy. My employment situation has changed in a way that does
not afford me the necessary time to remain a regular contributor to
Nova, or the broader OpenStack community. So it is with regret that I
announce that I will no longer be actively involved in the project.

Fortunately, for those of you reading this, the Nova community is full
of wonderful and talented individuals who have picked up the work that
I'm not able to continue. Primarily this means parts of the cellsv2
effort, for which I am extremely grateful.

It has been a true pleasure working with you all these past few years
and I'm thankful to have had the opportunity. As I've told people many
times when they ask me what it's like to work on an open source project
like this: working on proprietary software exposes you to smart people
but you're limited to the small set of people within an organization,
working on a project like this exposed me to smart people from many
companies and many parts of the world. I have learned a lot working with
you all. Thanks.

I will continue to lurk in #openstack-nova, and try to stay minimally
involved as time allows, so feel free to ping me there.

-Laski

__
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] Meeting Time

[Dougal Matthews]

On 22 November 2016 at 10:45, Renat Akhmerov 
wrote:

> Dougal,
>
> I think we should have this alternate meeting. The reason is although the
> current time doesn’t work only for 2-3 people those people are very
> important for the project (I primarily mean Lingxian (kong) and Winson
> (m4dcoder)). As far as I understand, for Hardik Parekh (hparekh) the
> current time also doesn’t work well.
>
> I’m volunteering to participate in this alternate meeting even if it’s not
> too comfortable for me.
>

Great. Do you want to start this next week or the week after?

I'm not sure how/where we need to update with the new meeting information.
I also think we need to reserve the time in IRC.

Thanks
Dougal



>
>
> Renat Akhmerov
> @Nokia
>
> On 21 Nov 2016, at 21:14, Dougal Matthews  wrote:
>
>
>
> On 7 November 2016 at 16:20, Dougal Matthews  wrote:
>
>> Hi all,
>>
>> We want to make sure that the Mistral meeting time is as good as
>> possible, so that everyone interested can attend. To do that, please add
>> your name/nick and the times that suit you to this etherpad:
>>
>> https://etherpad.openstack.org/p/mistral-meeting-time
>>
>> If we are really lucky, we will find a time in that for everyone. if we
>> are slightly lucky we will find two time slots that covers everyone and the
>> meeting can alternate.
>>
>> We may find that the current time is best for everyone, but I wanted to
>> make sure.
>>
>> Cheers,
>> Dougal
>>
>
> Hey all,
>
> Thanks to everyone that added their names to the etherpad. It looks like
> the current time does work for most people. How else can we reach out and
> increase participation?
>
> I would like to propose that we alternate the meetings each week between
> the normal time and a time later in the day. This assumes we have a
> volunteer that is able to regularly attend this meeting and start it - if
> not, we can just stick with the current meeting time. The other time should
> be arranged so it suits rakhmerov, kong and m4dcode (at least).
>
> Hopefully with two alternating meeting slots we can involve more people in
> the meetings.
>
> I'll bring this up today in the meeting too.
>
> Thanks,
> Dougal
>
> __
> 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] [mistral] Meeting Time

[Dougal Matthews]

On 22 November 2016 at 11:11, Deja, Dawid  wrote:

> Dougla, Renat
>
> If we want to have another meeting that would suit mostly New Zeland
> and US, can we move current meeting time to slightly earlier, so it
> fits India better (and also may be more comfortable for people in
> Europe)?
>

That should be fine with me. How much earlier would it need to be?

Cheers,
Dougal


Dawid Deja
>
> On Tue, 2016-11-22 at 17:45 +0700, Renat Akhmerov wrote:
> > Dougal,
> >
> > I think we should have this alternate meeting. The reason is although
> > the current time doesn’t work only for 2-3 people those people are
> > very important for the project (I primarily mean Lingxian (kong) and
> > Winson (m4dcoder)). As far as I understand, for Hardik Parekh
> > (hparekh) the current time also doesn’t work well.
> >
> > I’m volunteering to participate in this alternate meeting even if
> > it’s not too comfortable for me.
> >
> >
> > Renat Akhmerov
> > @Nokia
> >
> > > On 21 Nov 2016, at 21:14, Dougal Matthews 
> > > wrote:
> > >
> > >
> > >
> > > On 7 November 2016 at 16:20, Dougal Matthews 
> > > wrote:
> > > > Hi all,
> > > >
> > > > We want to make sure that the Mistral meeting time is as good as
> > > > possible, so that everyone interested can attend. To do that,
> > > > please add your name/nick and the times that suit you to this
> > > > etherpad:
> > > >
> > > > https://etherpad.openstack.org/p/mistral-meeting-time
> > > >
> > > > If we are really lucky, we will find a time in that for everyone.
> > > > if we are slightly lucky we will find two time slots that covers
> > > > everyone and the meeting can alternate.
> > > >
> > > > We may find that the current time is best for everyone, but I
> > > > wanted to make sure.
> > > >
> > > > Cheers,
> > > > Dougal
> > > >
> > >
> > > Hey all,
> > >
> > > Thanks to everyone that added their names to the etherpad. It looks
> > > like the current time does work for most people. How else can we
> > > reach out and increase participation?
> > >
> > > I would like to propose that we alternate the meetings each week
> > > between the normal time and a time later in the day. This assumes
> > > we have a volunteer that is able to regularly attend this meeting
> > > and start it - if not, we can just stick with the current meeting
> > > time. The other time should be arranged so it suits rakhmerov, kong
> > > and m4dcode (at least).
> > >
> > > Hopefully with two alternating meeting slots we can involve more
> > > people in the meetings.
> > >
> > > I'll bring this up today in the meeting too.
> > >
> > > Thanks,
> > > Dougal
> __
> 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][stable][ptls] Tagging liberty as EOL

[Alex Schultz]

Hey Tony,


On Mon, Nov 21, 2016 at 7:35 PM, Tony Breeds  wrote:
> Hi all,
> I'm late in sending this announement, but I'm glad to see several projects
> have already requested EOL releases to make it trivial and obvious where to
> apply the tag.
>
> I'm proposing to EOL all projects that meet one or more of the following
> criteria:
>
> - The project is openstack-dev/devstack, openstack-dev/grenade or
>   openstack/requirements
> - The project has the 'check-requirements' job listed as a template in
>   project-config:zuul/layout.yaml
> - The project gates with either devstack or grenade jobs
> - The project is listed in governance:reference/projects.yaml and is tagged
>   with 'stable:follows-policy'.
>
>
> Some statistics:
> All Repos  : 1493 (covered in zuul/layout.yaml)
> Checked Repos  :  406 (match one or more of the above 
> criteria)
> Repos with liberty branches:  305
> EOL Repos  :  171 (repos that match the criteria *and* 
> have
>a liberty branch) [1]
> NOT EOL Repos  :  134 (repos with a liberty branch but
>otherwise do not match) [2]
> DSVM Repos (staying)   :   68 (repos that use dsvm but don't have
>liberty branches)
> Open Reviews   :   94 (reviews to close)
>
>
> Please look over both lists by 2016-11-27 00:00 UTC and let me know if:
> - A project is in list 1 and *really* *really* wants to opt *OUT* of EOLing 
> and
>   why.  Note doing this will amost certainly reduce the testing coverage you
>   have in the gate.
> - A project is in list 2 that would like to opt *IN* to tagging/EOLing
>

For the puppet items on the second list[0], the liberty branches of
puppet-aodh and puppet-openstack_spec_helper can be EOL'ed. I assume
puppet-barbican is on that list because it doesn't have a
stable/liberty branch since the first release was newton, so that's
fine.

Thanks,
-Alex

[0] 
https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L308-L310

> Any projects that will be EOL'd will need all open reviews abandoned before it
> can be processed.  I'm very happy to do this, or if I don't have permissios to
> do it ask a gerrit admin to do it.
>
> I'll batch the removal of the stable/liberty branches between Nov 28th and Dec
> 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup 
> zuul/layout.yaml
> to remove liberty exclusions and jobs.
>
> Yours Tony.
>
> [1] 
> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L1
> [2] 
> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L181
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Stepping down from core

[Nate Johnston]

Carl,

Thanks for all of the help and encouragement you have given to me, especially
in the L3 arena.  Sometimes what can seem like a small thing to someone deeply
versed in a project is a real lifeline for a newer contributor.  I look forward
to seeing where your story goes from here.

Thanks,

--N.

__
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] Stepping down from core

[Das, Anindita]

Sad to see you go, Carl. Thank you for your guidance and support.

All the best for your future endeavors.

--Anindita

From: Carl Baldwin mailto:c...@ecbaldwin.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, November 17, 2016 at 6:42 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron] Stepping down from core

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such that 
I'm not able to keep up with my duties as a Neutron core reviewer, L3 
lieutenant, and drivers team member. My participation has dropped off 
considerably since Newton was released and I think it is fair to step down and 
leave an opening for others to fill. There is no shortage of talent in Neutron 
and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in Openstack and 
Neutron in the future if things change again in that direction. This is a great 
community and I've had a great time participating and learning with you all.

Well, I don't want to drag this out. I will still be around on IRC and will be 
happy to help out where I am able. Feel free to ping me.

Carl


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
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][kolla-ansible][kolla-kubernetes] Kolla core election policy change - vote

[Kwasniewska, Alicja]

+1

From: Jeffrey Zhang [mailto:zhang.lei@gmail.com]
Sent: Thursday, November 17, 2016 2:56 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [kolla][kolla-ansible][kolla-kubernetes] Kolla 
core election policy change - vote

+1

On Thu, Nov 17, 2016 at 8:26 PM, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:
Can we stick to one tag [kolla] for all ML discussion?  A whole slew of people 
already have filters setup.  Kolla is one project with one mission with 
multiple deliverables.  No other project that has multiple deliverables tags 
emails per deliverable.  I don’t think this is an occasion to be a special 
snowflake.

TIA :)
-steve





On 11/16/16, 11:23 AM, "Michał Jastrzębski" 
mailto:inc...@gmail.com>> wrote:

>Hello,
>
>In light of recent events (kolla-kubernetes becoming thriving project,
>kolla-ansible being split) I feel we need to change of core reviewer
>election process.
>
>Currently Kolla was single core team. That is no longer the case, as
>right now we have 3 distinct core teams (kolla, kolla-ansible and
>kolla-kubernetes), although for now with big overlap in terms of
>people in them.
>
>For future-proofing, as we already have difference between teams, I
>propose following change to core election process:
>
>
>Core reviewer voting rights are reserved by core team in question.
>Which means if someone propose core reviewer to kolla-kubernetes, only
>kolla-kubernetes cores has a voting right (not kolla or kolla-ansible
>cores).
>
>
>Voting will be open until 30 Nov '16 end of day. Reviewers from all
>core teams in kolla has voting rights on this policy change.
>
>Regards
>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



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [nova] 23-Nov Cells meeting cancelled

[Dan Smith]

Hi all,

Since this week's cells meeting falls on food-coma-day-eve, we're
canceling it. Anyone that wants to help move things along could review
the following patches:

https://review.openstack.org/#/q/topic:bp/cells-sched-staging+project:openstack/nova+status:open

https://review.openstack.org/#/q/topic:cell-databases-fixture

Thanks!

--Dan

__
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][sahara] Drop icehouse branches from repositories

[Vitaly Gridnev]

Hello,

Several days ago I’ve noticed that sahara-extra and sahara-image-elements 
repositories still have icehouse branch. Could someone help us with removing 
these branches? Thanks in advance. 

Best regards,
Vitaly Gridnev


__
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] [OpenStackClient] Weekly IRC meeting cancelled

[Dean Troyer]

The odd week OpenStackClient meeting at 19:00 on Nov 24 is cancelled
due to the US holiday.  We will see you all again on Dec 1 at 13:00
UTC in #openstack-meeting-3

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-dev] [Searchlight] Weekly IRC meeting cancelled for Thanksgiving

[McLellan, Steven]

Hi,

This week's IRC meeting will be cancelled due to the US Thanksgiving holiday on 
Thursday. Meetings will resume on Thursday December 1st.

Thanks!

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] [Vitrage] Problem at our gate in gerrit

[Weyl, Alexey (Nokia - IL)]

Hi,

We have temporary set the heat datasource tempest to ignore because of some 
problems with the heatclient that we didn't succeed to resolve in the xenial 
image.

I have rechecked all the failed commits.

If someone wants and have the time to check how exactly we should use the 
heatclient in xenial, that can be great.
Otherwise we will fix it soon.

Best regards,
Alexey

> -Original Message-
> From: vin...@vn.fujitsu.com [mailto:vin...@vn.fujitsu.com]
> Sent: Tuesday, November 22, 2016 11:43 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Vitrage] Problem at our gate in gerrit
> 
> Thank you for your work!
> 
> Best regards,
> 
> Vinh Nguyen Trong
> PODC - Fujitsu Vietnam Ltd.
> Mobile: +84-164-953-8507 - Email: vin...@vn.fujitsu.com
> 
> > -Original Message-
> > From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> > Sent: Tuesday, November 22, 2016 4:34 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: [openstack-dev] [Vitrage] Problem at our gate in gerrit
> >
> > Hi,
> >
> > We have some problems at our gate in gerrit.
> >
> > We have fixed one problem by changing the image that the tempests run
> > on to xenial image.
> >
> > But that has created some other problem, and we are checking it.
> >
> > I will send an email to update when the problem is resolved.
> >
> > Alexey
> >
> > ___
> > ___
> > 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] [neutron] [classifier] Common Classifier + OVS Flow Manager Meeting

[Duarte Cardoso, Igor]

Hi all,

Common Classifier / OVS Flow Manager developers and interested parties are 
invited for today's meeting. The agenda is below, feel free to add more topics.

https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_22_November_2016

The time has not changed (still 1700 UTC), but multiple locations have had 
daylight saving time clock changes since the last meeting, so double-check your 
current local time offset against UTC.

Best regards,
Igor.

__
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-Infra] [infra][neutron] Intel NFV CI voting permission in Neutron

[Znoinski, Waldemar]

 >-Original Message-
 >From: Jeremy Stanley [mailto:fu...@yuggoth.org]
 >Sent: Monday, November 14, 2016 3:40 PM
 >To: openstack-in...@lists.openstack.org; openstack-dev@lists.openstack.org
 >Subject: Re: [openstack-dev] [OpenStack-Infra] [infra][neutron] Intel NFV CI
 >voting permission in Neutron
 >
 >On 2016-11-14 10:44:42 + (+), Znoinski, Waldemar wrote:
 >> I would like to acquire voting (+/-1 Verified) permission for our
 >> Intel NFV CI.
 >[...]
 >
 >The requested permission is configured by addition to
 >https://review.openstack.org/#/admin/groups/neutron-ci which is
 >controlled by the members of the
 >https://review.openstack.org/#/admin/groups/neutron-release group.
 >The Infra team tries not to be involved in these decisions and instead prefers
 >to leave them up to the project team(s) involved.
[WZ] thanks for explanation Jeremy, that was my intention - the ask is to 
Neutron(-release) guys, with Infra as FYI

 >
 >> 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.
 >[...]
 >
 >This seems wholly inappropriate for a public mailing list. I strongly
 >recommend not sending messages to our mailing lists in which you strictly
 >prohibit review or distribution by others, as it is guaranteed to happen and
 >we cannot prevent that (nor would we want to).
[WZ] requested removal of that footer, thanks

 >--
 >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 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] Finish test job transition to Ubuntu Xenial

[Neil Jerram]

On Tue, Nov 22, 2016 at 2:00 PM Neil Jerram  wrote:

> After fixing those...  I see that the reproduce.sh script appears to do
> DevStack setup correctly, but not to run any Tempest tests.  Is
> reproduce.sh supposed to run the Tempest tests as well?
>
>
Sorry, please ignore that.  I still have a Xenial-related issue in my
DevStack setup.

Neil
__
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] Finish test job transition to Ubuntu Xenial

[Neil Jerram]

On Tue, Nov 22, 2016 at 11:41 AM Neil Jerram  wrote:

> On Tue, Nov 22, 2016 at 10:58 AM Neil Jerram  wrote:
>
> On Mon, Nov 7, 2016 at 9:50 PM Clark Boylan  wrote:
>
> [...]
>
> If you have jobs still running on trusty the next step is to fire up a
> Xenial instance locally and run that test to see if it works. Usually
> this will mean running the appropriate tox target or if using
> devstack-gate you can grab the reproduce.sh script for that job and run
> that script locally.
>
>
> Is there doc somewhere about what needs adding to a fresh Xenial server
> image, to allow reproduce.sh script to run successfully?
>
> So far, I've hit:
> - virtualenv
> - gcc
>
> - python-all-dev
>
> Then I think I'm into genuine issues with my DevStack plugin...
>

After fixing those...  I see that the reproduce.sh script appears to do
DevStack setup correctly, but not to run any Tempest tests.  Is
reproduce.sh supposed to run the Tempest tests as well?

Thanks,
  Neil
__
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][release] Final releases for stable/liberty and liberty-eol

[Tom Barron]

On 11/21/2016 06:38 AM, Alan Pevec wrote:
>> 1. Final stable/liberty releases should happen next week, probably by
>> Thursday 11/17.
> 
> I see only Cinder did it https://review.openstack.org/397282
> and Nova is under review https://review.openstack.org/397841
> 
> Is that all or other project are not aware Liberty is EOL now?
> 
> Cheers,
> Alan
> 
> __
> 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
> 


manila 1.0.2 has been released for Liberty EOL.

-- Tom

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [api] 24 November api-wg meeting cancelled

[Chris Dent]

Because of US holidays and other commitments, this week's API working
group meeting will be cancelled.

The next one will be 16:00 UTC on the 1st of December.

If you have something you'd like to discuss before then, please post
to this list with a tag of '[api]'. If you'd prefer to wait for the
meeting please add it as a topic to the agenda[1].

Thanks!

[1] https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda

--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] [acceleration]Team Biweekly Meeting 2016.11.10 minutes

[Zhipeng Huang]

No problem Moshe.

@Harm yes I will send out the channel in advance :)

On Tue, Nov 22, 2016 at 9:17 PM, Moshe Levi  wrote:

> Hi Howard,
>
> I won’t be able to make it from tomorrow meeting. Sorry.
>
>
>
> *From:* Harm Sluiman [mailto:harm.slui...@gmail.com]
> *Sent:* Tuesday, November 22, 2016 3:16 PM
> *To:* Zhipeng Huang 
> *Cc:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>; rodolfo.alonso.hernan...@intel.com;
> Michele Paolino ; Scott Kelso <
> ske...@lenovo.com>; Roman Dobosz ; Jim Golden <
> jim.gol...@nist.gov>; Miroslav Halas ; Moshe Levi <
> mosh...@mellanox.com>; pradeep.jagade...@huawei.com;
> michael.ro...@nokia.com; martial.mic...@nist.gov; jian-feng.d...@intel.com
> *Subject:* Re: [acceleration]Team Biweekly Meeting 2016.11.10 minutes
>
>
>
> Hi Howard. Can you send out the IRC in advance if you have it for
> Wednesday meeting?
>
>
>
> On Thu, Nov 10, 2016 at 10:55 AM, Zhipeng Huang 
> wrote:
>
> Hi Team,
>
>
>
> Thanks for attending today's meeting and again sorry for not be able to
> host it on yesterday.
>
>
>
> Since we don't have a meetbot now associated with a fix channel, I
> recorded the irc chat in a doc file and you could find it in the attachment.
>
>
>
> Key Takeaways:
>
> 1. Nomad project will be renamed to Cyborg (what a cool name) based upon
> our final tally on the etherpad
> 
>
> 2. Moshe introduced Nacsa project proposal, and an initial design doc has
> been shared among the team. We will make the doc public after a few rounds
> of review and discussion
>
> 3. Reminder for the team to take a look at the Scientific Working Group
> etherpad  for
> use cases
>
>
>
> Our next meeting will be on Nov 23th, 10:00am on irc
>
>
>
> --
>
> Zhipeng (Howard) Huang
>
>
>
> Standard Engineer
>
> IT Standard & Patent/IT Prooduct Line
>
> Huawei Technologies Co,. Ltd
>
> Email: huangzhip...@huawei.com
>
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
>
>
> (Previous)
>
> Research Assistant
>
> Mobile Ad-Hoc Network Lab, Calit2
>
> University of California, Irvine
>
> Email: zhipe...@uci.edu
>
> Office: Calit2 Building Room 2402
>
>
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
>
>
>
>
> --
>
> 宋慢
> Harm Sluiman
>
>
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [stable] Proposing Jay Faulkner for ironic-stable-maint

[Alan Pevec]

> Well, apparently I don't have access to add you, so we'll have
> to wait for Tony or someone else from the stable team to do that
> thing. :)

Done and welcome Jay!

Cheers,
Alan

__
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] [acceleration]Team Biweekly Meeting 2016.11.10 minutes

[Moshe Levi]

Hi Howard,
I won’t be able to make it from tomorrow meeting. Sorry.

From: Harm Sluiman [mailto:harm.slui...@gmail.com]
Sent: Tuesday, November 22, 2016 3:16 PM
To: Zhipeng Huang 
Cc: OpenStack Development Mailing List (not for usage questions) 
; rodolfo.alonso.hernan...@intel.com; 
Michele Paolino ; Scott Kelso 
; Roman Dobosz ; Jim Golden 
; Miroslav Halas ; Moshe Levi 
; pradeep.jagade...@huawei.com; michael.ro...@nokia.com; 
martial.mic...@nist.gov; jian-feng.d...@intel.com
Subject: Re: [acceleration]Team Biweekly Meeting 2016.11.10 minutes

Hi Howard. Can you send out the IRC in advance if you have it for Wednesday 
meeting?

On Thu, Nov 10, 2016 at 10:55 AM, Zhipeng Huang 
mailto:zhipengh...@gmail.com>> wrote:
Hi Team,

Thanks for attending today's meeting and again sorry for not be able to host it 
on yesterday.

Since we don't have a meetbot now associated with a fix channel, I recorded the 
irc chat in a doc file and you could find it in the attachment.

Key Takeaways:
1. Nomad project will be renamed to Cyborg (what a cool name) based upon our 
final tally on the 
etherpad
2. Moshe introduced Nacsa project proposal, and an initial design doc has been 
shared among the team. We will make the doc public after a few rounds of review 
and discussion
3. Reminder for the team to take a look at the Scientific Working Group 
etherpad for 
use cases

Our next meeting will be on Nov 23th, 10:00am on irc

--
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado



--
宋慢
Harm Sluiman



__
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] [acceleration]Team Biweekly Meeting 2016.11.10 minutes

[Harm Sluiman]

Hi Howard. Can you send out the IRC in advance if you have it for Wednesday
meeting?

On Thu, Nov 10, 2016 at 10:55 AM, Zhipeng Huang 
wrote:

> Hi Team,
>
> Thanks for attending today's meeting and again sorry for not be able to
> host it on yesterday.
>
> Since we don't have a meetbot now associated with a fix channel, I
> recorded the irc chat in a doc file and you could find it in the attachment.
>
> Key Takeaways:
> 1. Nomad project will be renamed to Cyborg (what a cool name) based upon
> our final tally on the etherpad
> 
> 2. Moshe introduced Nacsa project proposal, and an initial design doc has
> been shared among the team. We will make the doc public after a few rounds
> of review and discussion
> 3. Reminder for the team to take a look at the Scientific Working Group
> etherpad  for
> use cases
>
> Our next meeting will be on Nov 23th, 10:00am on irc
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>



-- 
宋慢
Harm Sluiman
__
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] Cancelling net-bgpvpn today's meeting

[Mathieu Rohon]

Hi,

neither thomas nor I are available to chair today's bgpvpn meeting.
We don't have a lot of topics on today's agenda, so let's cancel today's
meeting.

See you next week.

Mathieu
__
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] [Rally] broken jobs

[Andrey Kurilin]

Hi Renat,

As soon as one [1][2] changes will be merged, everything should be
unblocked.

[1] - https://review.openstack.org/#/c/399752
[2] - https://review.openstack.org/#/c/400183


On Tue, Nov 22, 2016 at 12:40 PM, Renat Akhmerov 
wrote:

> Andrey, thanks for reporting this. Any estimations on how long it will
> take to fix it?
>
> Renat Akhmerov
> @Nokia
>
> On 19 Nov 2016, at 02:23, Andrey Kurilin  wrote:
>
> yse, I think you are right.
>
> On Fri, Nov 18, 2016 at 4:04 PM, gordon chung  wrote:
>
>> this seems related to fact we use datetime type in mysql which requires
>> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the
>> required mysql.
>>
>> On 18/11/16 07:50 AM, Andrey Kurilin wrote:
>> > Hi stackers,
>> >
>> > I hate to report such things, but most of rally jobs are broken now due
>> > to uncompatibility aodh service with ubuntu-trusty nodes.
>> >
>> > If you find failed rally jobs with
>> > http://paste.openstack.org/show/589707/ in devstacklogs, recheck will
>> > not help.
>> >
>> > I'm working on two changes now for Rally jobs which should unblock and
>> > fix gates:
>> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time
>> ago.
>> > - Disable telemetry services in those jobs which do not need them.
>> >
>> >
>> > --
>> > Best regards,
>> > Andrey Kurilin.
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> 
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> --
>> gord
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best regards,
> Andrey Kurilin.
> __
> 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
>
>


-- 
Best regards,
Andrey Kurilin.
__
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] [MassivelyDistributed] IRC Meeting tomorrow 15:00 UTC

[lebre . adrien]

Hi all, 

Agenda available at: 
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2016
Feel free to add items to the agenda. 

++
ad_rien_

__
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] [tripleo] [tripleo-quickstart] Tripleo-Quickstart root privileges

[Yolanda Robla Mota]

Hi all
I wanted to start a thread about the current privileges model for TripleO 
quickstart.
Currently there is the assumption that quickstart does not need root privileges 
after the environment and provision roles. However, this assumption cannot be 
valid for several use cases.
In particular, I have the need of creating working directories outside the home 
directory of the user running quickstart. This can be useful on environments 
where /home partition is small and cannot be modified (so there is not enough 
disk space to host TripleO quickstart artifacts there).
This is the change i'm working on for that use case: 
https://review.openstack.org/#/c/384892

As you can see, to be able to create working directories outside home 
directories, it will need root privileges to properly create the initial 
working dir and give proper permissions. This break current model but I think 
it could provide advantages and flexibility to the deployment. So what are your 
thoughts about it, shall we continue with that and change privileges model? The 
alternative I can see is to just limit the working directory to home directory, 
but then do not offer the ability to customize it, and document that 
restriction on TripleO quickstart properly.

Best

Yolanda Robla
yrobl...@redhat.com
Principal Software Engineer - NFV Partner Engineer


__
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] Finish test job transition to Ubuntu Xenial

[Neil Jerram]

On Tue, Nov 22, 2016 at 10:58 AM Neil Jerram  wrote:

> On Mon, Nov 7, 2016 at 9:50 PM Clark Boylan  wrote:
>
> [...]
>
> If you have jobs still running on trusty the next step is to fire up a
> Xenial instance locally and run that test to see if it works. Usually
> this will mean running the appropriate tox target or if using
> devstack-gate you can grab the reproduce.sh script for that job and run
> that script locally.
>
>
> Is there doc somewhere about what needs adding to a fresh Xenial server
> image, to allow reproduce.sh script to run successfully?
>
> So far, I've hit:
> - virtualenv
> - gcc
>
- python-all-dev

Then I think I'm into genuine issues with my DevStack plugin...


> Neil
>
>
__
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] Finish test job transition to Ubuntu Xenial

[Denis Makogon]

Hello Neil

See comments inline

Kind regards,
Denis Makogon

2016-11-22 12:58 GMT+02:00 Neil Jerram :

> On Mon, Nov 7, 2016 at 9:50 PM Clark Boylan  wrote:
>
>> [...]
>
> If you have jobs still running on trusty the next step is to fire up a
>> Xenial instance locally and run that test to see if it works. Usually
>> this will mean running the appropriate tox target or if using
>> devstack-gate you can grab the reproduce.sh script for that job and run
>> that script locally.
>>
>>
> Is there doc somewhere about what needs adding to a fresh Xenial server
> image, to allow reproduce.sh script to run successfully?
>
> So far, I've hit:
> - virtualenv
>

In Python 3.x you can create virtualenv with command: python3 -m virtualenv
.venv


> - gcc
>
> Neil
>
>
> __
> 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] [stable] Proposing Jay Faulkner for ironic-stable-maint

[Jim Rollenhagen]

On Mon, Nov 21, 2016 at 9:03 PM, Tony Breeds  wrote:
> On Wed, Nov 16, 2016 at 02:02:44PM +0100, Dmitry Tantsur wrote:
>> Hi!
>>
>> I'm formally proposing that the ironic-stable-maint team [1] adds Jay
>> Faulkner. He's been consistently reviewing stable patches as shown by [2]. I
>> fully trust that his operator experience will help his judgment on not
>> landing dangerous things :)
>>
>> So for those on the team already, please reply with a +1 or -1 vote.
>
> Clearly not an ironic core but with the stable-maint-core hat on it's a +1 
> from
> me!  Jay does good work on the ironic stable branches :)
>
> Go Jay!
>
> Yours Tony.

Sounds like consensus. Welcome to the team, Jay \o/

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

Re: [openstack-dev] [mistral] Meeting Time

[Deja, Dawid]

Dougla, Renat

If we want to have another meeting that would suit mostly New Zeland
and US, can we move current meeting time to slightly earlier, so it
fits India better (and also may be more comfortable for people in
Europe)?

Dawid Deja

On Tue, 2016-11-22 at 17:45 +0700, Renat Akhmerov wrote:
> Dougal,
> 
> I think we should have this alternate meeting. The reason is although
> the current time doesn’t work only for 2-3 people those people are
> very important for the project (I primarily mean Lingxian (kong) and
> Winson (m4dcoder)). As far as I understand, for Hardik Parekh
> (hparekh) the current time also doesn’t work well.
> 
> I’m volunteering to participate in this alternate meeting even if
> it’s not too comfortable for me.
> 
> 
> Renat Akhmerov
> @Nokia
> 
> > On 21 Nov 2016, at 21:14, Dougal Matthews 
> > wrote:
> > 
> > 
> > 
> > On 7 November 2016 at 16:20, Dougal Matthews 
> > wrote:
> > > Hi all,
> > > 
> > > We want to make sure that the Mistral meeting time is as good as
> > > possible, so that everyone interested can attend. To do that,
> > > please add your name/nick and the times that suit you to this
> > > etherpad:
> > > 
> > > https://etherpad.openstack.org/p/mistral-meeting-time
> > > 
> > > If we are really lucky, we will find a time in that for everyone.
> > > if we are slightly lucky we will find two time slots that covers
> > > everyone and the meeting can alternate.
> > > 
> > > We may find that the current time is best for everyone, but I
> > > wanted to make sure.
> > > 
> > > Cheers,
> > > Dougal
> > > 
> > 
> > Hey all,
> > 
> > Thanks to everyone that added their names to the etherpad. It looks
> > like the current time does work for most people. How else can we
> > reach out and increase participation?
> > 
> > I would like to propose that we alternate the meetings each week
> > between the normal time and a time later in the day. This assumes
> > we have a volunteer that is able to regularly attend this meeting
> > and start it - if not, we can just stick with the current meeting
> > time. The other time should be arranged so it suits rakhmerov, kong
> > and m4dcode (at least).
> > 
> > Hopefully with two alternating meeting slots we can involve more
> > people in the meetings.
> > 
> > I'll bring this up today in the meeting too.
> > 
> > Thanks,
> > Dougal
__
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] [stable] Proposing Jay Faulkner for ironic-stable-maint

[Jim Rollenhagen]

On Tue, Nov 22, 2016 at 6:10 AM, Jim Rollenhagen  
wrote:
> On Mon, Nov 21, 2016 at 9:03 PM, Tony Breeds  wrote:
>> On Wed, Nov 16, 2016 at 02:02:44PM +0100, Dmitry Tantsur wrote:
>>> Hi!
>>>
>>> I'm formally proposing that the ironic-stable-maint team [1] adds Jay
>>> Faulkner. He's been consistently reviewing stable patches as shown by [2]. I
>>> fully trust that his operator experience will help his judgment on not
>>> landing dangerous things :)
>>>
>>> So for those on the team already, please reply with a +1 or -1 vote.
>>
>> Clearly not an ironic core but with the stable-maint-core hat on it's a +1 
>> from
>> me!  Jay does good work on the ironic stable branches :)
>>
>> Go Jay!
>>
>> Yours Tony.
>
> Sounds like consensus. Welcome to the team, Jay \o/

Well, apparently I don't have access to add you, so we'll have
to wait for Tony or someone else from the stable team to do that
thing. :)

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

Re: [openstack-dev] [All] Finish test job transition to Ubuntu Xenial

[Neil Jerram]

On Mon, Nov 7, 2016 at 9:50 PM Clark Boylan  wrote:

> [...]

If you have jobs still running on trusty the next step is to fire up a
> Xenial instance locally and run that test to see if it works. Usually
> this will mean running the appropriate tox target or if using
> devstack-gate you can grab the reproduce.sh script for that job and run
> that script locally.
>
>
Is there doc somewhere about what needs adding to a fresh Xenial server
image, to allow reproduce.sh script to run successfully?

So far, I've hit:
- virtualenv
- gcc

Neil
__
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] Meeting Time

[Renat Akhmerov]

Dougal,

I think we should have this alternate meeting. The reason is although the 
current time doesn’t work only for 2-3 people those people are very important 
for the project (I primarily mean Lingxian (kong) and Winson (m4dcoder)). As 
far as I understand, for Hardik Parekh (hparekh) the current time also doesn’t 
work well.

I’m volunteering to participate in this alternate meeting even if it’s not too 
comfortable for me.


Renat Akhmerov
@Nokia

> On 21 Nov 2016, at 21:14, Dougal Matthews  wrote:
> 
> 
> 
> On 7 November 2016 at 16:20, Dougal Matthews  > wrote:
> Hi all,
> 
> We want to make sure that the Mistral meeting time is as good as possible, so 
> that everyone interested can attend. To do that, please add your name/nick 
> and the times that suit you to this etherpad:
> 
> https://etherpad.openstack.org/p/mistral-meeting-time 
> 
> 
> If we are really lucky, we will find a time in that for everyone. if we are 
> slightly lucky we will find two time slots that covers everyone and the 
> meeting can alternate.
> 
> We may find that the current time is best for everyone, but I wanted to make 
> sure.
> 
> Cheers,
> Dougal
> 
> Hey all,
> 
> Thanks to everyone that added their names to the etherpad. It looks like the 
> current time does work for most people. How else can we reach out and 
> increase participation?
> 
> I would like to propose that we alternate the meetings each week between the 
> normal time and a time later in the day. This assumes we have a volunteer 
> that is able to regularly attend this meeting and start it - if not, we can 
> just stick with the current meeting time. The other time should be arranged 
> so it suits rakhmerov, kong and m4dcode (at least).
> 
> Hopefully with two alternating meeting slots we can involve more people in 
> the meetings.
> 
> I'll bring this up today in the meeting too.
> 
> Thanks,
> Dougal
> 
> __
> 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] [Rally] broken jobs

[Renat Akhmerov]

Andrey, thanks for reporting this. Any estimations on how long it will take to 
fix it?

Renat Akhmerov
@Nokia

> On 19 Nov 2016, at 02:23, Andrey Kurilin  wrote:
> 
> yse, I think you are right.
> 
> On Fri, Nov 18, 2016 at 4:04 PM, gordon chung  > wrote:
> this seems related to fact we use datetime type in mysql which requires
> 5.6.4? (i'm guessing on version). but yes, ubuntu-xenial should have the
> required mysql.
> 
> On 18/11/16 07:50 AM, Andrey Kurilin wrote:
> > Hi stackers,
> >
> > I hate to report such things, but most of rally jobs are broken now due
> > to uncompatibility aodh service with ubuntu-trusty nodes.
> >
> > If you find failed rally jobs with
> > http://paste.openstack.org/show/589707/ 
> >  in devstacklogs, recheck will
> > not help.
> >
> > I'm working on two changes now for Rally jobs which should unblock and
> > fix gates:
> > - Port Rally jobs to use ubuntu-xenial nodes. We had to do it long time ago.
> > - Disable telemetry services in those jobs which do not need them.
> >
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> >
> > __
> > 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 
> > 
> >
> 
> --
> gord
> 
> __
> 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 
> 
> 
> 
> 
> -- 
> Best regards,
> Andrey Kurilin.
> __
> 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] [magnum] Managing cluster drivers as individual distro packages

[Ricardo Rocha]

Hi.

I think option 1. is the best one right now, mostly to reduce the
impact on the ongoing developments.

Upgrades, flattening, template versioning and node groups are supposed
to land a lot of patches in the next couple months, moving the drivers
into separate repos now could be a distraction.

We can revisit this later... and maybe improve at the same time the
user experience of adding custom drivers, which is not yet great
(we're using the glance image metadata for this as there's no explicit
--driver option yet).

Cheers,
Ricardo

On Fri, Nov 18, 2016 at 6:04 PM, Drago Rosson
 wrote:
> If we were to go with (2), what should happen to the common code?
>
> From: Spyros Trigazis 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Friday, November 18, 2016 at 8:34 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [magnum] Managing cluster drivers as individual
> distro packages
>
> Hi all,
>
> In magnum, we implement cluster drivers for the different combinations
> of COEs (Container Orchestration Engines) and Operating Systems. The
> reasoning behind it is to better encapsulate driver-specific logic and to
> allow
> operators deploy custom drivers with their deployment specific changes.
>
> For example, operators might want to:
> * have only custom drivers and not install the upstream ones at all
> * offer user only some of the available drivers
> * create different combinations of  COE + os_distro
> * create new experimental/staging drivers
>
> It would be reasonable to manage magnum's cluster drivers as different
> packages, since they are designed to be treated as individual entities. To
> do
> so, we have two options:
>
> 1. in-tree:  remove the entrypoints from magnum/setup.cfg to not install
> them
> by default. This will require some plumbing to manage them like separate
> python
> packages, but allows magnum's development team to manage the official
> drivers
> inside the service repo.
>
> 2. separate repo: This option sounds cleaner, but requires more refactoring
> and
> will separate more the drivers from service, having significant impact in
> the
> development process.
>
> Thoughts?
>
> Spyros
>
> __
> 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