date:20170131

On Tue, Jan 31, 2017 at 07:40:13AM +0530, Digambar Patil wrote:
> Hello Infra team,
> 
> I am implementing new API framework in tacker based on Falcon. We have
> decided to create separate branch for this so that we can push all the code
> to feature branch and once dev is completed, will merge branch to master.
> So we need to create Feature/branch in Tacker.
> 
> Reference Spec - https://review.openstack.org/#/c/368511/ - submitted
> 
> Can someone help create feature branch from Infra team ?

This cycle the release management team (well Doug) added self-service support
for this.  Please check out [1] that shoudl help you do the thing you want.

If you have any questions jump onto #openstack-release and ping.

Yours Tony.

[1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n69


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] [ffe][requirements][gnocchi][rally][mistral] upper-constraint gnocchiclient 3.0.0

On Tue, Jan 31, 2017 at 09:31:44PM +, gordon chung wrote:
> 
> 
> On 31/01/17 04:09 PM, Matthew Thode wrote:
> > So, to summarize, new server doesn't work with old client.  Will this
> > require a global requirements update as well (seems like it)?
> 
> i probably shouldve just typed that ^
> 
> >
> > It will cause a knock-ons for ceilometer, cloudkitty, gnocchi and
> > mistral at least.  We could get the UC bump in I think, but will need to
> > talk about the GR update, if it's requested.
> 
> someone can correct me, but the new client should work with old server 
> code because it actually does same magic on server, just that the client 
> also had the magic (which it arguably should've)

So from a requirements POV we have the following consumers

Package  : gnocchiclient [gnocchiclient>=2.7.0] (used by 8 projects)
Also affects : 8 projects
openstack/aodh[]
openstack/ceilometer  [tc:approved-release]
openstack/cloudkitty  []
openstack/deb-aodh[]
openstack/deb-ceilometer  []
openstack/deb-rally   []
openstack/mistral []
openstack/rally   []

Ignoring openstack/deb-* and checking for constratints support in the remaining 
projects:

$ for prj in openstack/aodh openstack/ceilometer openstack/cloudkitty 
openstack/mistral openstack/rally ; do (cd $prj; git remote update >/dev/null 
2>&1; git grep -i upper-constraints.txt origin/master -- tox.ini ) ; done
/Users/tony8129/projects/openstack/openstack/aodh
origin/master:tox.ini:8:# NOTE(tonyb): This project has chosen to *NOT* consume 
upper-constraints.txt
/Users/tony8129/projects/openstack/openstack/ceilometer
origin/master:tox.ini:9:# NOTE(tonyb): This project has chosen to *NOT* consume 
upper-constraints.txt
/Users/tony8129/projects/openstack/openstack/cloudkitty
/Users/tony8129/projects/openstack/openstack/mistral
origin/master:tox.ini:8:install_command = {toxinidir}/tools/tox_install.sh 
{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
 {opts} {packages}
/Users/tony8129/projects/openstack/openstack/rally
origin/master:tox.ini:18:install_command = pip install -c 
https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt
 -U {opts} {packages}

I'm fine with this *if* mistal and rally are fine with it as they're the only
consumers affected by the review in question (as opposed to the release)

I've added the appropriate PTLs

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

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

2017-01-31 Thread Takashi Yamamoto

hi,

On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann  wrote:
> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
>> hi,
>>
>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann  wrote:
>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
>> >> > hi,
>> >> >
>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> >> >> Hi
>> >> >>
>> >> >> As of today, the project neutron-vpnaas is no longer part of the 
>> >> >> neutron
>> >> >> governance. This was a decision reached after the project saw a 
>> >> >> dramatic
>> >> >> drop in active development over a prolonged period of time.
>> >> >>
>> >> >> What does this mean in practice?
>> >> >>
>> >> >> From a visibility point of view, release notes and documentation will 
>> >> >> no
>> >> >> longer appear on openstack.org as of Ocata going forward.
>> >> >> No more releases will be published by the neutron release team.
>> >> >> The neutron team will stop proposing fixes for the upstream CI, if not
>> >> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >> >>
>> >> >> How does it affect you, the user or the deployer?
>> >> >>
>> >> >> You can continue to use vpnaas and its CLI via the 
>> >> >> python-neutronclient and
>> >> >> expect it to work with neutron up until the newton
>> >> >> release/python-neutronclient 6.0.0. After this point, if you want a 
>> >> >> release
>> >> >> that works for Ocata or newer, you need to proactively request a 
>> >> >> release
>> >> >> [5], and reach out to a member of the neutron release team [3] for 
>> >> >> approval.
>> >> >
>> >> > i want to make an ocata release. (and more importantly the stable 
>> >> > branch,
>> >> > for the benefit of consuming subprojects)
>> >> > for the purpose, the next step would be ocata-3, right?
>> >>
>> >> Hey Takashi,
>> >> If you want to release new version of neutron-vpnaas, please look at [1].
>> >> This is the place, which you need to update and based on provided
>> >> details, tags and branches will be cut.
>> >>
>> >> [1] 
>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>> >
>> > Unfortunately, since vpnaas is no longer part of an official project,
>> > we won't be using the releases repository to manage and publish
>> > information about the releases. It'll need to be done by hand.
>>
>> who can/should do it by hand?
>
> I can do it. Let me know the version number, and for each repository the
> SHA of the commit on the master branch to be tagged.

thank you. i'll ask you when necessary.

i think it's fine to just make a branch from master when stable branch is cut
for neutron.  how others think?

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

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

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

2017-01-31 Thread Takashi Yamamoto

hi,

>> That's great to hear Yamamoto. Since you are already a neutron-core I assume
>> you are already intimate with the work required to strengthen the VPNaaS
>> project. I have added you to [4] and you can lean on me for any changes that
>> needs reviewing.

i wrote a scenario test.
https://review.openstack.org/#/c/424459/
while it's working well with midonet, it seems failing with strongswan driver.
is there any possibly related known issues with strongswan?

__
OpenStack Development Mailing 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] gate jobs - papercuts


On 1/31/2017 11:49 AM, Davanum Srinivas wrote:

Folks,

Here's the list of job failures that failed in the gate queue.
captured with my script[1][2] since around 10:00 AM today. All jobs
failed with just one bad test.

http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/
   - tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/
 - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/
   - tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON
http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/
 - 
tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON
http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/
   - keystone.tests.unit.test_v3_auth.TestMFARules
http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/
  - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/
   - tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps

So our gate is now 36 deep with stuff running for little more than 4
hours repeatedly Can folks look deeper please?

Thanks,
Dims

[1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e
[2] http://paste.openstack.org/show/597071/



I've identified a regression in nova here:

https://bugs.launchpad.net/nova/+bug/1660878

--

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] [openstack-infra] Please add a initial core member to meteos-ui-core.

2017-01-31 Thread Joshua Hesketh

All done :-)

On Wed, Feb 1, 2017 at 11:53 AM, Hiroyuki Eguchi 
wrote:

> Hello Infra Team.
>
>
>
> I've created new projects named meteos-ui
>
> which UI interface for Machine Learning as a Service.
>
>
>
> Could you please add me (Hiroyuki Eguchi )
>
> as a initial core member of meteos-ui-core ?
>
>
>
> Thanks.
>
>
>
> --
>
> Hiroyuki Eguchi
>
>
>
> __
> OpenStack Development Mailing 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][CI] CI freeze and transition to quickstart

On Tue, Jan 31, 2017 at 6:47 PM, Gabriele Cerami  wrote:
> Hi,
>
> despite CI freeze for substantial change is in order, I recognize
> there's always the need to add or modify slightly the jobs for
> important fixes or to improve debugging.
>
> Unfortunately in these days we are wrapping up the gap in feature
> coverage between tripleo-ci and quickstart, and any of those change is
> increasing the list of features to be added to the implementation,
> making the wrap a moving target.
> Also, I'm seen some more-than-minor changes merged in these days, and
> that is making this job even more difficult.
>
> For those reason, we're going to ask everybody, from this moment on, for
> every change proposed to tripleo-ci, to propose an equivalent change to
> quickstart, or, if it seems too difficult, to open a bug in quickstart,
> pointing at the change in tripleo-ci, with some explanation on why it's
> needed, if it's not already clear in the commit message.
>
> At the end of this week we're going to make the final cut to the list
> of features we're going to transition to quickstart. If a feature, a
> test, an improvement, a small fix is added in tripleo-ci without
> signaling quickstart in any way, the risk is that the change will go
> unnoticed, and will be lost in transition.
>
> thanks for your collaboration.

Thanks Gabriele for driving this work. Your proposal sounds fair!
And if there is any doubt or question, folks can reach us out on
#tripleo anytime.
-- 
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] [kolla] Domains support

2017-01-31 Thread Christian Tardif


Hi,

I'm looking for domains support in Kolla. I've searched, but didn't find 
anything relevant. Could someone point me how to achieve this?


What I'm really looking for, in fact, is a decent way or setting auth 
through LDAP backend while keeping service users (neutron, for example) 
in the SQL backend. I know that this can be achieved with domains 
support (leaving default domain on SQL, and another domain for LDAP 
users. Or maybe there's another of doing this?


Thanks,

Christian Tardif
christian.tar...@servinfo.ca
__
OpenStack Development Mailing 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] [FFE][requirements] VMware nsxlib 0.7.0

On Tue, Jan 31, 2017 at 04:40:22PM +, Gary Kotton wrote:
> Hi,
> At the moment we have a number of bugs in the plugin that are addressed by 
> the patches here. Could we please get this approved so that the Ocata version 
> will be ina state that we can release it. This is blocking us for certain 
> uses cases.
> Thanks
> Gary

As youve said vmware-nsx is the only consumer and that isn't managed by the 
release team so approving this only unblocks your projects with no knock on 
effects:
---
Package  : vmware-nsxlib [vmware-nsxlib>=0.6.0] (used by 1 projects)
Also affects : 1 projects
openstack/vmware-nsx  []
---

In short Looks good to me

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] [openstack-infra] Please add a initial core member to meteos-ui-core.

2017-01-31 Thread Hiroyuki Eguchi

Hello Infra Team.

I've created new projects named meteos-ui
which UI interface for Machine Learning as a Service.

Could you please add me (Hiroyuki Eguchi )
as a initial core member of meteos-ui-core ?

Thanks.

--
Hiroyuki Eguchi

__
OpenStack Development Mailing 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] New mascot design

2017-01-31 Thread Arkady.Kanevsky

I think Russian already owns the bear.

From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
Sent: Tuesday, January 31, 2017 2:49 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [ironic] New mascot design

Hey ironic-ers,
The foundation has passed along a new version of our mascot (attached) to us, 
and would like your feedback on it.

They're hoping to have all mascot-related things ready in time for the PTG, so 
please do send your thoughts quickly, if you have them. :)

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

[openstack-dev] [TripleO][CI] CI freeze and transition to quickstart

2017-01-31 Thread Gabriele Cerami

Hi,

despite CI freeze for substantial change is in order, I recognize
there's always the need to add or modify slightly the jobs for
important fixes or to improve debugging.

Unfortunately in these days we are wrapping up the gap in feature
coverage between tripleo-ci and quickstart, and any of those change is
increasing the list of features to be added to the implementation,
making the wrap a moving target.
Also, I'm seen some more-than-minor changes merged in these days, and
that is making this job even more difficult.

For those reason, we're going to ask everybody, from this moment on, for
every change proposed to tripleo-ci, to propose an equivalent change to
quickstart, or, if it seems too difficult, to open a bug in quickstart,
pointing at the change in tripleo-ci, with some explanation on why it's
needed, if it's not already clear in the commit message.

At the end of this week we're going to make the final cut to the list
of features we're going to transition to quickstart. If a feature, a
test, an improvement, a small fix is added in tripleo-ci without
signaling quickstart in any way, the risk is that the change will go
unnoticed, and will be lost in transition.

thanks for your collaboration.

__
OpenStack Development Mailing 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] [kolla] Phoenix area meet up with the topic of Kolla Feb 15th @ 21:00 UTC

2017-01-31 Thread Steven Dake (stdake)

Hey folks,

Toby Cardone has kindly organized a local (to me) community meetup hosted by 
the Red Hat Software User Group at Insight’s facilities in Tempe, AZ with the 
topic of Kolla on February 15th, 2017 at 21:00 UTC.  Several folks in the Kolla 
IRC channel have asked if remote participation is possible.  I asked Toby and 
he said that sounded great!

The meetup information in more detail is here:

If you are interested in participating the community seminar more information 
can be found here:
https://www.meetup.com/PhoenixRedHatSoftwareUserGroup/events/237219035/

You don’t need to register at the meetup site to attend remotely; only local 
attendance requires signup (to make sure the event’s facilities are not 
overbooked).  Much of this material may be old hat for the community in general 
although I do plan to provide a live demo of the current state of sausage 
making in kolla-kubernetes.

I am using webex for remote participation.  I know this is not ideal since it 
doesn’t run on Linux 64 bit.  One workaround is to use your phone, a 32bit 
android tablet, or a 32 bit linux vm (pretty sure this last one works but not 
100% positive) if you don’t have access to a mac or windows platform.  
Depending on attendance webex may be pokey – please take care to sign in up to 
15 minutes early in the event webex is overloaded.

The remote participation webex information follows:

Wednesday February 15th, 2017 @ 2PM MST (21:00 UTC)
Meeting: 
https://cisco.webex.com/ciscosales/j.php?MTID=mee2e81571288da5c183af4ae2fff0d8e
Meeting number (access code): 208 707 718
Password: OpenStackKolla
Passowrd on callin lines: 67367822
Global dialin #s: 
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC=374661952=1

Regards,
-steve

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

Re: [openstack-dev] [release][all][ptl][stable] the process for creating stable/ocata branches

On Mon, Jan 16, 2017 at 12:27:08PM -0500, Doug Hellmann wrote:

> * I will branch the requirements repository shortly after all of
>   the cycle-with-milestone projects have branched. After the
>   requirements repository is branched and the master requirements
>   list is opened, projects that have not branched will be tested
>   with Pike requirements as the requirements master branch advances
>   and stable/ocata stays stable. Waiting too long to create the
>   stable/ocata branch may result in broken CI jobs in either
>   stable/ocata or master. Don't delay any further than necessary.

I'd just like to highlight this point.  During the newton -> ocata freeze we saw
a number of projects delaying the branch for too long when meant they ended up
testing with the ocata requirements and then shortly after branching they got
requirements updates from newton which in many cases meant things went backwards
:(

From a requirements team POV we'll delay any minimum bumps for a couple of week
to reduce this but there's only so long we can do that.

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

Re: [openstack-dev] [neutron-fwaas] issue with firewall and sfc

2017-01-31 Thread Vikash Kumar

I will be happy to contribute and will join the meeting.

On Tue, Jan 31, 2017 at 8:36 PM, Sridar Kandaswamy (skandasw) <
skand...@cisco.com> wrote:

> Hi Vikash:
>
> The support for VM ports is in progress and we should have that completed
> fairly early in Pike. We have had some prelim thoughts on integration with
> SFC but have not come to that point yet. If u have some interest, u are
> also welcome to join our weekly meeting [1] and we can discuss more.
>
> Thanks
>
> Sridar
>
> [1] http://eavesdrop.openstack.org/#Firewall_as_a_Service_(
> FWaaS)_Team_Meeting
>
> From: Vikash Kumar 
> Reply-To: OpenStack List 
> Date: Tuesday, January 31, 2017 at 2:49 AM
> To: OpenStack List 
> Subject: [openstack-dev] [neutron-fwaas] issue with firewall and sfc
>
> Hi,
>
>I am looking to fwaas_v2, which now allows the firewall rules to get
> apply on VM ports also. The doc suggests it will work in tandem with
> neutron SFC. However, in SFC the port-security is disabled and if thats the
> case, where will the IPTABLE rules will be rendered ?
>
> --
> Regards,
> Vikash
>
> __
> OpenStack Development Mailing 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,
Vikash
__
OpenStack Development Mailing 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] [requirements][stable][relmgt] PTG prep

On Fri, Jan 27, 2017 at 04:46:03PM +0100, Thierry Carrez wrote:
> Hi!
> 
> The requirements team, the stable maintenance team and the release
> management team will share a single room on the Monday and Tuesday of
> the PTG. Since we don't all need 2 full days of coordination (and
> several of us need to also attend some other team meeting at the same
> time), I propose we split the time we have into 4 sessions:
> 
> Monday morning: Stable team session
> Monday afternoon: Release management session
> Tuesday morning: Requirements session
> Tuesday afternoon: All together (stable/requirements/release management)
> 
> We'll use that last session for discussing common topics, but also to
> cover all the stuff that we didn't have time to finish in the
> team-specific sessions.
> 
> To simplify I also propose that we share the preparation etherpad:
> 
> https://etherpad.openstack.org/p/relmgt-stable-requirements-ptg-pike
> 
> Let me know if this proposed plan causes any issue.

Thanks Thierry.

Look sgood to me although I don't know that we have a lot of stable specific
content so Monday may end up more release specific.

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

Re: [openstack-dev] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-01-31 Thread Marios Andreou

On 31/01/17 18:02, Ben Nemec wrote:
> In the spirit of all the core team changes, here are a couple more I'd
> like to propose.
> 
> Dmitry has been very helpful reviewing in instack-undercloud for a long
> time so this is way overdue.  I'm also going to propose that he be able
> to +2 anything Ironic-related in TripleO since that is his primary area
> of expertise.
> 
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet
> modules, and a lot of the changes to instack-undercloud these days are
> primarily in the puppet manifest so it's not a huge stretch to add him.
> 
> As usual, TripleO cores please vote and/or provide comments.  Thanks.

+1

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

Re: [openstack-dev] [ironic] New mascot design

2017-01-31 Thread Pavlo Shchelokovskyy

Hi all,

this new logo actually reminds me of a wide-spread Russian meme

(Warning, might be considered NSFW)

http://knowyourmeme.com/memes/preved-medved-%D0%BF%D1%80%D0%B5%D0%B2%D0%B5%D0%B4-%D0%BC%D0%B5%D0%B4%D0%B2%D0%B5%D0%B4

Not the best connotation to my taste :-/

So yeah, even the previous design was better :(

+1 to Lucas.

Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Feb 1, 2017 at 3:28 AM,  wrote:

> I think Russian already owns the bear.
>
>
>
> *From:* Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
> *Sent:* Tuesday, January 31, 2017 2:49 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [ironic] New mascot design
>
>
>
> Hey ironic-ers,
>
> The foundation has passed along a new version of our mascot (attached) to
> us, and would like your feedback on it.
>
> They're hoping to have all mascot-related things ready in time for the
> PTG, so please do send your thoughts quickly, if you have them. :)
>
>
> // jim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Device tag in the API breaks in the old microversion

2017-01-31 Thread Artom Lifshitz

The more urgent stuff has indeed merged - many thanks to Matt and
other cores for getting this in quickly before rc1. The fixes to tests
do indeed need more attention, which I will provide :)

On Mon, Jan 30, 2017 at 8:49 PM, Matt Riedemann  wrote:
> On 1/26/2017 8:32 PM, Artom Lifshitz wrote:
>>
>> Since the consensus is to fix this with a new microversion, I've
>> submitted some patches:
>>
>> * https://review.openstack.org/#/c/426030/
>>   A spec for the new microversion in case folks want one.
>
>
> Merged.
>
>>
>> * https://review.openstack.org/#/c/424759/
>>   The new microversion itself. I've already had feedback from Alex and
>> Ghanshyam (thanks guys!), and I've tried to address it.
>
>
> +2 from me, +1 from gmann. The Tempest patch for the 2.42 microversion is
> here:
>
> https://review.openstack.org/#/c/426991/1
>
>>
>> * https://review.openstack.org/#/c/425876/
>>   A patch to - as Alex and Sean suggested - stop passing plain string
>> version to the schema extension point.
>>
>
> Needs some work.
>
>
> --
>
> 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



-- 
--
Artom Lifshitz

__
OpenStack Development Mailing 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] [puppet] No meeting today - Jan 31, 2017

2017-01-31 Thread Alex Schultz

Hi all,

Since the agenda[0] for the meeting is empty, I'm canceling the
meeting.  If you wish to talk about something next week, please add it
to the agenda[1].

Thanks,
-Alex

[0] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20170131
[1] https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20170207

__
OpenStack Development Mailing 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] [aodh][vitrage] Aodh generic alarms

2017-01-31 Thread Afek, Ifat (Nokia - IL)

On 30/01/2017, 19:11, "gordon chung"  wrote:
>   
> On 29/01/17 08:52 AM, Afek, Ifat (Nokia - IL) wrote:
> >
> > Vitrage could be enhanced to become an alarm orchestrator.
> > The question is – do you want Vitrage to be one?
> > And how would you describe the role of an alarm orchestrator/manager?
> >
>
> i don't really have an opinion on the orchestrator role although it 
> seems to be leaning that way.
>
> i'll re-ask a question i had earlier since i'm not entirely clear of 
> proposal (if it's still relevant):
>
> if we store a vitrage alarm in aodh, what would the use case be for
> querying it? the alarm occurred and vitrage has already sent a
> notification warning. if i were to query aodh, what additional
> information would i be retrieving?
>

If you query Vitrage (or get a notification from Vitrage) and then you query 
Aodh, then Aodh will not return any additional information. But – if you query 
only Aodh, you will be aware of the fact that the instances are at risk. 
Without the integration, you will see that all instances are OK 
performance-wise, and you might mistakenly conclude that everything is else 
also fine. 

Did I answer your question?

Ifat.

__
OpenStack Development Mailing 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] [puppet] [infra] [fuel] Adding puppet-module-build voting job

Hi,

I have been working on adding a new CI job that will:
- test if "puppet module build ." command works
- be executed only when touching metadata.json

This job will be useful to validate tarballs can be created when
releasing Puppet modules.

If your project is failing on gate-{name}-puppet-module-build, please
let me know and I'll help in fixing it.
I checked all Puppet OpenStack modules and it worked fine, but I might
have missed something for Infra & Fuel modules / projects that have
metadata.json file.

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] [neutron-fwaas] issue with firewall and sfc

2017-01-31 Thread Sridar Kandaswamy (skandasw)

Hi Vikash:

The support for VM ports is in progress and we should have that completed 
fairly early in Pike. We have had some prelim thoughts on integration with SFC 
but have not come to that point yet. If u have some interest, u are also 
welcome to join our weekly meeting [1] and we can discuss more.

Thanks

Sridar

[1] http://eavesdrop.openstack.org/#Firewall_as_a_Service_(FWaaS)_Team_Meeting

From: Vikash Kumar 
>
Reply-To: OpenStack List 
>
Date: Tuesday, January 31, 2017 at 2:49 AM
To: OpenStack List 
>
Subject: [openstack-dev] [neutron-fwaas] issue with firewall and sfc

Hi,

   I am looking to fwaas_v2, which now allows the firewall rules to get apply 
on VM ports also. The doc suggests it will work in tandem with neutron SFC. 
However, in SFC the port-security is disabled and if thats the case, where will 
the IPTABLE rules will be rendered ?

--
Regards,
Vikash
__
OpenStack Development Mailing 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] [containers][magnum] Swarm Mode template

2017-01-31 Thread Kevin Lefevre

Hi, Docker 1.13 has been released with several improvements that brings
swarm mode principles closer to Kubernetes such as docker-compose
service swarm mode.

I'd like to implement a v2 swarm template. I don't know if it's already
been discussed.

Swarm mode is a bit different but a lot simpler to deploy than Swarm
Legacy.

In Kubernetes you can deploy multiples masters at the same time but in
swarm mode you have to:
- bootstrap a first docker node
- run docker swarm init
- get a token (worker or manager)
- bootstrap other worker
- use manager or worker token depending manager count.

I don't know what is the best way to do so in HEAT. I'm sure there are
multiple options (I'm not an expert in HEAT i don't know if they are
feasible) :

- Bootstrap a first server
- Wait for it to ready, run docker swarm init, get both manager and
worker tokens
- if manager count >1, we can bootstrap another resource group for
extra managers which will use a manager token.
- Bootstrap the rest of the worker and use a worker token.

The difficulty is to handle multiples master properly, i'd like to hear
your ideas about that.


-- 
Kevin Lefevre

__
OpenStack Development Mailing 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] [FFE][requirements] FFE for os-dpm

2017-01-31 Thread Andreas Scheuring

Thanks a lot!

Yes, bumping the GC at some point in time makes sense. I'm not 100% sure
about the process.
- I would wait until the UC has merged
- Then merge the corresponding update on networking-dpm
- Then request a bump of the global requirements version

Does that make sense?


-- 
-
Andreas 
IRC: andreas_s



On Di, 2017-01-31 at 10:43 -0600, Matthew Thode wrote:
> On 01/31/2017 09:35 AM, Andreas Scheuring wrote:
> > Hi, I'm requesting a feature freeze exception for raising the upper
> > constraint of the os-dpm library. Therefore the following patch got
> > submitted to gerrit [1].
> > 
> > 
> > os-dpm is a shared library between the projects nova-dpm [2] and
> > networking-dpm [3]. Those projects are still under development (first
> > release outstanding) and should finally host a nova and neutron driver
> > for a new hypervisor type (DPM). One thing that is shared between those
> > projects are common config options. Since the last version, some of them
> > needed to be renamed. To apply them to the projects this new release is
> > required.
> > 
> > The latest release does not pull in any new requirements and is not used
> > by any other projects than [2] and [3].
> > 
> > 
> > Thanks in advance!
> > 
> > 
> > [1] https://review.openstack.org/427195
> > [2] https://github.com/openstack/nova-dpm
> > [3] https://github.com/openstack/networking-dpm
> > 
> 
> Well, thunderbird crashed and I lost the reply.  Here's the short of it.
> 
> I'm fine with a UC bump but it sounds like you also need a GR bump since
> this is a new minimum.  That is likely fine, based on it only actually
> being required by the networking-dpm project, though I'd require an ack
> from them to get a GR bump considered.
> 
> __
> OpenStack Development Mailing 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 Dmitry Tantsur and Alex Schultz as instack-undercloud cores

On Tue, Jan 31, 2017 at 11:02 AM, Ben Nemec  wrote:
> In the spirit of all the core team changes, here are a couple more I'd like
> to propose.
>
> Dmitry has been very helpful reviewing in instack-undercloud for a long time
> so this is way overdue.  I'm also going to propose that he be able to +2
> anything Ironic-related in TripleO since that is his primary area of
> expertise.
>
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet modules,
> and a lot of the changes to instack-undercloud these days are primarily in
> the puppet manifest so it's not a huge stretch to add him.
>
> As usual, TripleO cores please vote and/or provide comments.  Thanks.

/me happy dance to have them aboard
+1 on both.

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



-- 
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] [FFE][requirements] FFE for os-dpm

On 01/31/2017 09:35 AM, Andreas Scheuring wrote:
> Hi, I'm requesting a feature freeze exception for raising the upper
> constraint of the os-dpm library. Therefore the following patch got
> submitted to gerrit [1].
> 
> 
> os-dpm is a shared library between the projects nova-dpm [2] and
> networking-dpm [3]. Those projects are still under development (first
> release outstanding) and should finally host a nova and neutron driver
> for a new hypervisor type (DPM). One thing that is shared between those
> projects are common config options. Since the last version, some of them
> needed to be renamed. To apply them to the projects this new release is
> required.
> 
> The latest release does not pull in any new requirements and is not used
> by any other projects than [2] and [3].
> 
> 
> Thanks in advance!
> 
> 
> [1] https://review.openstack.org/427195
> [2] https://github.com/openstack/nova-dpm
> [3] https://github.com/openstack/networking-dpm
> 

Well, thunderbird crashed and I lost the reply.  Here's the short of it.

I'm fine with a UC bump but it sounds like you also need a GR bump since
this is a new minimum.  That is likely fine, based on it only actually
being required by the networking-dpm project, though I'd require an ack
from them to get a GR bump considered.

-- 
Matthew Thode (prometheanfire)



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

Re: [openstack-dev] [nova][qa] gate-grenade-dsvm-neutron-multinode-live-migration-nv is 100% fail since 1/21


On 1/27/2017 9:35 PM, Matt Riedemann wrote:


The only thing I can think that might be causing some mischief is the
devstack-tools stuff that was integrated recently into the CI system,
which messes with local.conf. But I don't know enough about how that
works, so would need sdague to investigate.



Just to follow up, Sean has the fix here:

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

The unnecessary export was messing things up since devstack-tools strips 
out those lines.


--

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

[openstack-dev] [FFE][requirements] FFE for os-dpm

2017-01-31 Thread Andreas Scheuring

Hi, I'm requesting a feature freeze exception for raising the upper
constraint of the os-dpm library. Therefore the following patch got
submitted to gerrit [1].


os-dpm is a shared library between the projects nova-dpm [2] and
networking-dpm [3]. Those projects are still under development (first
release outstanding) and should finally host a nova and neutron driver
for a new hypervisor type (DPM). One thing that is shared between those
projects are common config options. Since the last version, some of them
needed to be renamed. To apply them to the projects this new release is
required.

The latest release does not pull in any new requirements and is not used
by any other projects than [2] and [3].


Thanks in advance!


[1] https://review.openstack.org/427195
[2] https://github.com/openstack/nova-dpm
[3] https://github.com/openstack/networking-dpm

-- 
-
Andreas 
IRC: andreas_s





__
OpenStack Development Mailing 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] [aodh][vitrage] Aodh generic alarms

2017-01-31 Thread gordon chung

On 31/01/17 08:34 AM, Afek, Ifat (Nokia - IL) wrote:
> If you query Vitrage (or get a notification from Vitrage) and then you query 
> Aodh, then Aodh will not return any additional information. But – if you 
> query only Aodh, you will be aware of the fact that the instances are at 
> risk. Without the integration, you will see that all instances are OK 
> performance-wise, and you might mistakenly conclude that everything is else 
> also fine.

i see. so the proposal was to have Aodh be the place where we collate 
alarms from Aodh AND Vitrage. i agree, that's probably not what Aodh 
should be doing (i'll still push that to Panko)

would a possible workflow be to maybe have Vitrage send alert to Aodh 
and for Aodh to listen to that event and reraise if needed? or if 
vitrage can just reraise, then it can send that event to Panko so we can 
see all information on that resource.

my assumption right now is Vitrage itself is listening for a bunch of 
alerts (from zabbix, etc...) and has a set of 'composite' alarms which 
when it receives alert x and alert y, it 'deduces' that it should send 
an alert z?

cheers,
-- 
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

Re: [openstack-dev] [FFE][requirements] VMware nsxlib 0.7.0

On 01/31/2017 10:40 AM, Gary Kotton wrote:
> Hi,
> 
> At the moment we have a number of bugs in the plugin that are addressed
> by the patches here. Could we please get this approved so that the Ocata
> version will be ina state that we can release it. This is blocking us
> for certain uses cases.
> 
> Thanks
> 
> Gary
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Your review also bumps the minimum version (through a bump to
global-requirements.txt).  Codesearch didn't find anything using
vmware-nsxlib in their requirements.txt though.  Any GR update is going
to have knock-on effects, causing every consuming project to have to
re-release.  I'd need buy-in from them before I consider allowing the
gr-update through, though I'm generally fine with the UC update.

-- 
Matthew Thode (prometheanfire)

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

Re: [openstack-dev] [nova][qa] gate-grenade-dsvm-neutron-multinode-live-migration-nv is 100% fail since 1/21

2017-01-31 Thread Sean Dague

On 01/27/2017 10:42 PM, Ken'ichi Ohmichi wrote:
> 2017-01-27 19:35 GMT-08:00 Matt Riedemann :
>> On 1/27/2017 5:00 PM, Matt Riedemann wrote:
>>>
>>> I noticed that this job is 100% failure since 1/21:
>>>
>>> http://tinyurl.com/zjh5bc5
>>>
>>>
>>> http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/devstack-gate-post_test_hook.txt.gz#_2017-01-27_23_43_40_367
>>>
>>>
>>> For whatever reason, live_migration=False in tempest.conf:
>>>
>>>
>>> http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/new/tempest_conf.txt.gz
>>>
>>>
>>
>> The only thing I can think that might be causing some mischief is the
>> devstack-tools stuff that was integrated recently into the CI system, which
>> messes with local.conf. But I don't know enough about how that works, so
>> would need sdague to investigate.
> 
> Yeah, this misconfiguration happens only on grenade multinode jobs only.
> The live_migration config is set correctly on tempest multinode jobs
> like 
> http://logs.openstack.org/16/411816/5/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/4a95eca/logs/tempest_conf.txt.gz
> which its grenade multinode jobs fails on the same time.

Yes, it has to do with what's supported in merging for the localrc part
of local.conf:

https://github.com/openstack/devstack-tools/blob/e0098fc212a9d6f19c2f65b9d1965066b190814e/devstack/dsconf.py#L313-L330

This is the regex for matching key/values to set - r"([^#=\s]+)\s*\=\s*(.+)"

Which, means that "export A=B" isn't going to match, when "A=B" would.
The whole strategy around merging here may need some rethinking, but at
this point in the freeze the simpler approach should just be -
https://review.openstack.org/#/c/427282/

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [snaps] announce: new snaps for rally, tempest and openstackclients

2017-01-31 Thread James Page

Hi All

Snap packages for rally (0.7.0), tempest (14.0.0) and openstackclients
(currently Newton aligned) are available for use; the associated git
repositories can also be found under the openstack org on github (see [0],
[1], [2]).  Git repos also contain details of use of each snap.

You can consume these snaps from any Ubuntu 16.04 install - for example:

 sudo snap install --edge --classic openstackclients

to enable all client tools provided by the openstackclients snap:

 ls -1 /snap/bin/openstackclients.* | cut -f 2 -d . | xargs sudo snap alias
openstackclients

Snaps will grow support for auto-aliasing at some point, so that second
step will go away in the future.

These are all still pretty fresh, so if you hit issues, please raise bugs
against the appropriate Launchpad projects; we're also hanging out in
#openstack-snaps on freenode if you want to ask any questions directly!

Enjoy

James

[0] https://github.com/openstack/snap-tempest
[1] https://github.com/openstack/snap-rally
[2] https://github.com/openstack/snap-openstackclients
__
OpenStack Development Mailing 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] [containers][magnum] Swarm Mode template

2017-01-31 Thread Spyros Trigazis

Hi.

I have done it by checking the ip address of the master. The current state
of
the heat drivers doesn't allow the distinction between master > 1 or
master=1.

Spyros



On 31 January 2017 at 16:33, Kevin Lefevre  wrote:

> Hi, Docker 1.13 has been released with several improvements that brings
> swarm mode principles closer to Kubernetes such as docker-compose
> service swarm mode.
>
> I'd like to implement a v2 swarm template. I don't know if it's already
> been discussed.
>
> Swarm mode is a bit different but a lot simpler to deploy than Swarm
> Legacy.
>
> In Kubernetes you can deploy multiples masters at the same time but in
> swarm mode you have to:
> - bootstrap a first docker node
> - run docker swarm init
> - get a token (worker or manager)
> - bootstrap other worker
> - use manager or worker token depending manager count.
>
> I don't know what is the best way to do so in HEAT. I'm sure there are
> multiple options (I'm not an expert in HEAT i don't know if they are
> feasible) :
>
> - Bootstrap a first server
> - Wait for it to ready, run docker swarm init, get both manager and
> worker tokens
> - if manager count >1, we can bootstrap another resource group for
> extra managers which will use a manager token.
> - Bootstrap the rest of the worker and use a worker token.
>
> The difficulty is to handle multiples master properly, i'd like to hear
> your ideas about that.
>
>
> --
> Kevin Lefevre
>
> __
> OpenStack Development Mailing 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] [tripleo] Updates from the containers squad: Where are we at?

2017-01-31 Thread Flavio Percoco


Greetings,

In the last month, there’s been no update on what’s been happening in the
containers effort for TripleO so I thought I’d drop an email to… well… provide
updates.

The work in the DFG has been broken down into more granular steps that are
easier to account for. However, I’d like to focus a bit more on the architecture
side of things first.

There have been some major changes in how containers are deployed within TripleO
and how services are containerized. I’ll try to describe those below but bear in
mind that some details may change a little bit and that this is still a work in
progress.

* The new architecture aims to support a hybrid deployment where it’s possible
 to run some services on baremetal and others on containers. This has been done
 to ease the upgrade process from baremetal nodes to a containerize node and it
 doesn’t change the goal of having all services containerized. More details
 about this new architecture can be found here[0]. Please, check out the README
 file.
 
* There’s no heat agent container anymore. Instead, we’re installing puppet in

 the base image for every service and then run puppet from the service
 container. A bit of more details about this change can be found in this blog
 post[0] (Thanks Dan)
 
* The old copy-json file that used to create the config.json for the kolla image

 was replaced with a heat-hook. More about this on this patch.[2]
 
* Several patches for containerizing services have been proposed. TBH, we’ve not

 done a great job at using a single topic BUT if you open the patch[0], you’ll
 see a list of patches depending on it that propose the containerization of
 several projects.
 
* There’s a non-voting CI job that currently only runs on patches that modify

 files related to the containers work. You can read more about this on this
 patch[3]. The goal is to make this job voting as soon as Pike starts.
 
* Perhaps more RDO specific but there’s also been great progress in the building

 pipeline for containers. We’re using kolla images as our base container images
 and the image build process is being integrated with the TripleO CI pipeline.
 This means that new images will be created whenever there’s a promotion in
 TripleO. We’d like to take this one step further for Pike and be able to build
 images on every patch merged in the various projects, just like we’d do with
 RPM packages. I wanted to mention this because I love the fact that this helps
 us testing kolla images thoroughly and also give back to the community in some
 way. More on this can be found here[4]
 
* Support for a containerized deployment has been added to tripleo-quickstart

 and it’s being used for the CI job.
 
* The containers squad will start the work of documenting the current

 architecture as soon as possible. As mentioned in the points above, there have
 been several changes to the architecture that made starting the documentation
 process not worthwhile. We can start documenting things now that we feel more
 comfortable with the current version of the framework.
 
* We’re starting to work on a strategy for upgrades for baremetal nodes to

 containerized nodes. Again, this work was waiting for the architecture to be
 polished out a bit more and the composable upgrades work to mature. Now it
 seems like a good time to kick this off.

Eventually (and likely soon) this will impact other squads and there will be
need of a joint work towards finalizing the containerization process. More
details will be provided as part of the documentation and in future emails.

There are still many things to do, though. There are services that still need to
be containerized, there are more CI jobs to be added and all the services that
have been containerized so far must also be tested in the overcloud. That being
said, I’m personally happy with the progress made so far and I hope you are as
well and that this email is useful to you.

Rock on,
Flavio

[0] https://review.openstack.org/#/c/416421/
[1] https://dprince.github.io/docker-puppet.html
[2] https://review.openstack.org/#/c/416420/
[3] https://review.openstack.org/#/c/423519/
[4] https://etherpad.openstack.org/p/rdo-kolla-build

--
@flaper87
Flavio Percoco


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] [FFE][requirements] VMware nsxlib 0.7.0

2017-01-31 Thread Gary Kotton

Hi,
At the moment we have a number of bugs in the plugin that are addressed by the 
patches here. Could we please get this approved so that the Ocata version will 
be ina state that we can release it. This is blocking us for certain uses cases.
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Ocata FFE, CIFE, RC1

== Ocata FFE (feature freeze exception)

We are now in Feature Freeze, which means we won't add any new feature
in TripleO from now until we release final Ocata.
Some exceptions might be made though. Here are the requirements:

- the feature has to be tracked in a blueprint or bug in Launchpad.
- the request for FFE has to be sent on openstack-dev [tripleo]
mailing-list before Friday 3th February.

If the blueprint is not for Ocata anymore or if FFE hasn't be granted,
the blueprint needs to be moved to pike-1.

I would remind our core reviewers to respect this rule and do not
merge features unless FFE has been granted.
The list of features accepted for Ocata (FFE included) is documented here:
https://launchpad.net/tripleo/+milestone/ocata-rc1
(expect some move today, some blueprints will go in Pike unless FFE is asked).

== CIFE (CI freeze exception)

The last thing we want during release time is to break our CI jobs.
Please do not merge big changes in our CI and we will only accept
fixes that we actually need to make continuous integration to release
Ocata.
Gabriele will send another email about quickstart / tripleo-ci changes.


== RC1
We'll propose RC1 once our blueprints and Critical / High bugs are
completed/fixed. It should happen by PTG time, so we'll have 2 more
weeks to make the final release.
Note that this time we'll start branching projects at the very end of
our cycle, so we avoid the backports (like we had in Newton).

Until final release, focus should be on:
- Critical / High bugs for ocata-rc1
- Blueprints with FFE granted for ocata-rc1
- CI stabilization

Any question / feedback is welcome as usual.

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

[openstack-dev] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-01-31 Thread Ben Nemec

In the spirit of all the core team changes, here are a couple more I'd 
like to propose.


Dmitry has been very helpful reviewing in instack-undercloud for a long 
time so this is way overdue.  I'm also going to propose that he be able 
to +2 anything Ironic-related in TripleO since that is his primary area 
of expertise.


Alex has ramped up quickly on TripleO and has also been helping out with 
instack-undercloud quite a bit.  He's already core for the puppet 
modules, and a lot of the changes to instack-undercloud these days are 
primarily in the puppet manifest so it's not a huge stretch to add him.


As usual, TripleO cores please vote and/or provide comments.  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

Re: [openstack-dev] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-01-31 Thread John Trowbridge



On 01/31/2017 11:02 AM, Ben Nemec wrote:
> In the spirit of all the core team changes, here are a couple more I'd
> like to propose.
> 
> Dmitry has been very helpful reviewing in instack-undercloud for a long
> time so this is way overdue.  I'm also going to propose that he be able
> to +2 anything Ironic-related in TripleO since that is his primary area
> of expertise.
> 

+1 long overdue. Dmitry reviews a ton of TripleO patches.

> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet
> modules, and a lot of the changes to instack-undercloud these days are
> primarily in the puppet manifest so it's not a huge stretch to add him.
> 

+1 as well.


__
OpenStack Development Mailing 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] Supporting our global community

2017-01-31 Thread Ian Y. Choi

Hello,

Thanks a lot for this important message.

As an I18n team contributor and an non-US citizen, I quite agree with
the note.

FYI: ujuc - I18n Korean language coordinator translated the message into
Korean language
=>
https://ujuc.kr/openstack-%EB%B2%88%EC%97%AD-supporting-our-global-community-c5a419757cc7#.h3crayt1i

With many thanks,

/Ian

Jonathan Bryce wrote on 1/30/2017 3:34 AM:

OpenStack is a global open source community. The OpenStack Foundation serves
members in 180 countries focused on advancing the capabilities and
accessibility of open infrastructure everywhere. We fundamentally believe
diversity and collaboration are a powerful force for innovation, and it has
been amazing to see the product of tens of thousands of people around the world
over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President Trump
that targets individuals from 7 countries. The order restricts the travel and
movement of people in a discriminatory way that results in a restriction on
access to talent and ideas. It is still unclear how the policies will play out
and be enforced, but we will be watching, advocating for and supporting our
community members to the best of our ability.

This executive order will not impact the governance of the Foundation or the
way the community operates globally. We will continue to support user groups
and community members that are active in the seven countries named by the
executive order, alongside our 120+ user groups around the world. However, we
have two scheduled events in the United States within the next six months that
will attract a global audience: the PTG (Project Teams Gathering) in Atlanta,
Feb 20-24, a smaller event that will bring together hundreds of upstream
contributors, and the OpenStack Summit in Boston, May 8-11, our larger event
that happens every six months.

This executive order could impact some community members' ability to travel to
Atlanta and Boston, but unfortunately it is too late at this point to change
the location of these events. The following three OpenStack Summits, however,
are now scheduled to occur outside of the United States. The next Summit will
be in November 2017 in Sydney, Australia and we are working to finalize the
details so we can announce the following two Summit locations soon.

We’ve already heard from one community member, Mohammed Naser, who is concerned
that his plans to travel from Canada to Atlanta to attend the PTG may be
restricted, simply because he a dual citizen of Canada and Iraq. Mohammed has
been contributing code to OpenStack since 2011 and is the CEO and Founder of
Vexxhost. Blocking his travel would serve no purpose and rob the community of a
valuable contributor during an important event. If you are concerned about the
impact or have any questions, please don't hesitate to reach out to me at
jonat...@openstack.org.

Political actions like this highlight the importance of our collective values.
The Four Opens, the founding principles of our community, exist to ensure the
free flow of talent and ideas, across geographic, national, organizational or
other lines that might divide us. We believe in humanity. We believe in
opportunity. We believe in the power of collaboration across borders, and we
will continue to carry forward our mission.

We also posted this online:
https://www.openstack.org/blog/2017/01/supporting-our-global-community/

Jonathan Bryce
Mark Collier
Lauren Sell

__
OpenStack Development Mailing 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 Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-01-31 Thread Juan Antonio Osorio

+1

On Tue, Jan 31, 2017 at 6:48 PM, John Trowbridge  wrote:

>
>
> On 01/31/2017 11:02 AM, Ben Nemec wrote:
> > In the spirit of all the core team changes, here are a couple more I'd
> > like to propose.
> >
> > Dmitry has been very helpful reviewing in instack-undercloud for a long
> > time so this is way overdue.  I'm also going to propose that he be able
> > to +2 anything Ironic-related in TripleO since that is his primary area
> > of expertise.
> >
>
> +1 long overdue. Dmitry reviews a ton of TripleO patches.
>
> > Alex has ramped up quickly on TripleO and has also been helping out with
> > instack-undercloud quite a bit.  He's already core for the puppet
> > modules, and a lot of the changes to instack-undercloud these days are
> > primarily in the puppet manifest so it's not a huge stretch to add him.
> >
>
> +1 as well.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-01-31 Thread James Slagle

On Tue, Jan 31, 2017 at 11:02 AM, Ben Nemec  wrote:
> In the spirit of all the core team changes, here are a couple more I'd like
> to propose.
>
> Dmitry has been very helpful reviewing in instack-undercloud for a long time
> so this is way overdue.  I'm also going to propose that he be able to +2
> anything Ironic-related in TripleO since that is his primary area of
> expertise.
>
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet modules,
> and a lot of the changes to instack-undercloud these days are primarily in
> the puppet manifest so it's not a huge stretch to add him.
>
> As usual, TripleO cores please vote and/or provide comments.  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

+1. Dmitry is also one of the top reviewers and committers to
tripleo-docs. I wouldn't be opposed to him having +2 there as well.

-- 
-- 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] [FFE][requirements] FFE for os-dpm

On 01/31/2017 10:52 AM, Andreas Scheuring wrote:
> Thanks a lot!
> 
> Yes, bumping the GC at some point in time makes sense. I'm not 100% sure
> about the process.
> - I would wait until the UC has merged
> - Then merge the corresponding update on networking-dpm
> - Then request a bump of the global requirements version
> 
> Does that make sense?
> 
> 
> -- - Andreas IRC: andreas_s

Bumping the GR requires a re-release of all consuming projects.  I don't
think that's a problem, but we'd need to discuss it as a team.

In general the process goes like this.

1. Update UC
2. Update GR

If subscribed to requirements
  3. networking-dpm gets an update automatically when the periodic runs
else
  3. networking-dpm needs a manual update, can occur before GR update.

-- 
Matthew Thode (prometheanfire)

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

Re: [openstack-dev] [tripleo] Updates from the containers squad: Where are we at?

2017-01-31 Thread Fox, Kevin M

Great to hear the containerization process is going well. :)

Can we set aside some time during the PTG to talk about the process of 
detecting stale/building fresh containers at the PTG? Its a problem that all 
the kolla deliverables would also like solved. So maybe we can work together on 
it?

Thanks,
Kevin

From: Flavio Percoco [fla...@redhat.com]
Sent: Tuesday, January 31, 2017 8:13 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tripleo] Updates from the containers squad: Where 
are we at?

Greetings,

In the last month, there’s been no update on what’s been happening in the
containers effort for TripleO so I thought I’d drop an email to… well… provide
updates.

The work in the DFG has been broken down into more granular steps that are
easier to account for. However, I’d like to focus a bit more on the architecture
side of things first.

There have been some major changes in how containers are deployed within TripleO
and how services are containerized. I’ll try to describe those below but bear in
mind that some details may change a little bit and that this is still a work in
progress.

* The new architecture aims to support a hybrid deployment where it’s possible
  to run some services on baremetal and others on containers. This has been done
  to ease the upgrade process from baremetal nodes to a containerize node and it
  doesn’t change the goal of having all services containerized. More details
  about this new architecture can be found here[0]. Please, check out the README
  file.

* There’s no heat agent container anymore. Instead, we’re installing puppet in
  the base image for every service and then run puppet from the service
  container. A bit of more details about this change can be found in this blog
  post[0] (Thanks Dan)

* The old copy-json file that used to create the config.json for the kolla image
  was replaced with a heat-hook. More about this on this patch.[2]

* Several patches for containerizing services have been proposed. TBH, we’ve not
  done a great job at using a single topic BUT if you open the patch[0], you’ll
  see a list of patches depending on it that propose the containerization of
  several projects.

* There’s a non-voting CI job that currently only runs on patches that modify
  files related to the containers work. You can read more about this on this
  patch[3]. The goal is to make this job voting as soon as Pike starts.

* Perhaps more RDO specific but there’s also been great progress in the building
  pipeline for containers. We’re using kolla images as our base container images
  and the image build process is being integrated with the TripleO CI pipeline.
  This means that new images will be created whenever there’s a promotion in
  TripleO. We’d like to take this one step further for Pike and be able to build
  images on every patch merged in the various projects, just like we’d do with
  RPM packages. I wanted to mention this because I love the fact that this helps
  us testing kolla images thoroughly and also give back to the community in some
  way. More on this can be found here[4]

* Support for a containerized deployment has been added to tripleo-quickstart
  and it’s being used for the CI job.

* The containers squad will start the work of documenting the current
  architecture as soon as possible. As mentioned in the points above, there have
  been several changes to the architecture that made starting the documentation
  process not worthwhile. We can start documenting things now that we feel more
  comfortable with the current version of the framework.

* We’re starting to work on a strategy for upgrades for baremetal nodes to
  containerized nodes. Again, this work was waiting for the architecture to be
  polished out a bit more and the composable upgrades work to mature. Now it
  seems like a good time to kick this off.

Eventually (and likely soon) this will impact other squads and there will be
need of a joint work towards finalizing the containerization process. More
details will be provided as part of the documentation and in future emails.

There are still many things to do, though. There are services that still need to
be containerized, there are more CI jobs to be added and all the services that
have been containerized so far must also be tested in the overcloud. That being
said, I’m personally happy with the progress made so far and I hope you are as
well and that this email is useful to you.

Rock on,
Flavio

[0] https://review.openstack.org/#/c/416421/
[1] https://dprince.github.io/docker-puppet.html
[2] https://review.openstack.org/#/c/416420/
[3] https://review.openstack.org/#/c/423519/
[4] https://etherpad.openstack.org/p/rdo-kolla-build

--
@flaper87
Flavio Percoco

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

[openstack-dev] [vitrage] Added Vitrage release notes

2017-01-31 Thread Afek, Ifat (Nokia - IL)

Hi,

I added release notes for the Vitrage projects. Please go over them, and let me 
know if I missed an important feature:
https://review.openstack.org/#/c/427311/
https://review.openstack.org/#/c/427130/
https://review.openstack.org/#/c/427121/

Note that these changes must be merged before Thursday, Feb 2nd.

Thanks,
Ifat.


__
OpenStack Development Mailing 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] [FFE][requirements] VMware nsxlib 0.7.0

On 01/31/2017 12:18 PM, Gary Kotton wrote:
> Hi,
> At the moment we are the only consuming project. This is blocking us at the 
> moment. How do you suggest moving this forwards?
> Could we remove the upper constraints?
> Thanks
> Gary
> 
> On 1/31/17, 6:48 PM, "Matthew Thode"  wrote:
> 
> On 01/31/2017 10:40 AM, Gary Kotton wrote:
> > Hi,
> > 
> > At the moment we have a number of bugs in the plugin that are addressed
> > by the patches here. Could we please get this approved so that the Ocata
> > version will be ina state that we can release it. This is blocking us
> > for certain uses cases.
> > 
> > Thanks
> > 
> > Gary
> > 
> > 
> > 
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> Your review also bumps the minimum version (through a bump to
> global-requirements.txt).  Codesearch didn't find anything using
> vmware-nsxlib in their requirements.txt though.  Any GR update is going
> to have knock-on effects, causing every consuming project to have to
> re-release.  I'd need buy-in from them before I consider allowing the
> gr-update through, though I'm generally fine with the UC update.
> 
> -- 
> Matthew Thode (prometheanfire)
> 
> 
> 

We'll discuss it in the #openstack-requirements channels, but if you are
the only consumer that does help.

-- 
Matthew Thode (prometheanfire)



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] [tripleo] Feature Freeze Exception request for octavia-services-integration

2017-01-31 Thread Brent Eagles

Hi,

I'd like to request a feature freeze exception for patches submitted
against the octavia-services-integration blueprint (
https://blueprints.launchpad.net/tripleo/+spec/octavia-service-integration).
The service will not be deployed by default and is not currently part of
scenario testing so should have little impact on other services. Basic
configuration of the services is a first step in preparing for fully
functional Octavia integration (
https://blueprints.launchpad.net/tripleo/+spec/octavia-support) and
production readiness. Also, as a fully functional Octavia deployment
introduces some new issues of what can be done during deployment, having
the basic services easily deployable allows contributors and other
interested parties to better evaluate, discuss, develop and test solutions.

Cheers,

Brent Eagles
__
OpenStack Development Mailing 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] Updates from the containers squad: Where are we at?

2017-01-31 Thread Flavio Percoco


On 31/01/17 17:17 +, Fox, Kevin M wrote:

Great to hear the containerization process is going well. :)

Can we set aside some time during the PTG to talk about the process of 
detecting stale/building fresh containers at the PTG? Its a problem that all 
the kolla deliverables would also like solved. So maybe we can work together on 
it?



Absolutely, I saw you added a topic similar to this in the tripleo agenda. I
think it'd be awesome to sit and talk about this.

Flavio


Thanks,
Kevin

From: Flavio Percoco [fla...@redhat.com]
Sent: Tuesday, January 31, 2017 8:13 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [tripleo] Updates from the containers squad: Where 
are we at?

Greetings,

In the last month, there’s been no update on what’s been happening in the
containers effort for TripleO so I thought I’d drop an email to… well… provide
updates.

The work in the DFG has been broken down into more granular steps that are
easier to account for. However, I’d like to focus a bit more on the architecture
side of things first.

There have been some major changes in how containers are deployed within TripleO
and how services are containerized. I’ll try to describe those below but bear in
mind that some details may change a little bit and that this is still a work in
progress.

* The new architecture aims to support a hybrid deployment where it’s possible
 to run some services on baremetal and others on containers. This has been done
 to ease the upgrade process from baremetal nodes to a containerize node and it
 doesn’t change the goal of having all services containerized. More details
 about this new architecture can be found here[0]. Please, check out the README
 file.

* There’s no heat agent container anymore. Instead, we’re installing puppet in
 the base image for every service and then run puppet from the service
 container. A bit of more details about this change can be found in this blog
 post[0] (Thanks Dan)

* The old copy-json file that used to create the config.json for the kolla image
 was replaced with a heat-hook. More about this on this patch.[2]

* Several patches for containerizing services have been proposed. TBH, we’ve not
 done a great job at using a single topic BUT if you open the patch[0], you’ll
 see a list of patches depending on it that propose the containerization of
 several projects.

* There’s a non-voting CI job that currently only runs on patches that modify
 files related to the containers work. You can read more about this on this
 patch[3]. The goal is to make this job voting as soon as Pike starts.

* Perhaps more RDO specific but there’s also been great progress in the building
 pipeline for containers. We’re using kolla images as our base container images
 and the image build process is being integrated with the TripleO CI pipeline.
 This means that new images will be created whenever there’s a promotion in
 TripleO. We’d like to take this one step further for Pike and be able to build
 images on every patch merged in the various projects, just like we’d do with
 RPM packages. I wanted to mention this because I love the fact that this helps
 us testing kolla images thoroughly and also give back to the community in some
 way. More on this can be found here[4]

* Support for a containerized deployment has been added to tripleo-quickstart
 and it’s being used for the CI job.

* The containers squad will start the work of documenting the current
 architecture as soon as possible. As mentioned in the points above, there have
 been several changes to the architecture that made starting the documentation
 process not worthwhile. We can start documenting things now that we feel more
 comfortable with the current version of the framework.

* We’re starting to work on a strategy for upgrades for baremetal nodes to
 containerized nodes. Again, this work was waiting for the architecture to be
 polished out a bit more and the composable upgrades work to mature. Now it
 seems like a good time to kick this off.

Eventually (and likely soon) this will impact other squads and there will be
need of a joint work towards finalizing the containerization process. More
details will be provided as part of the documentation and in future emails.

There are still many things to do, though. There are services that still need to
be containerized, there are more CI jobs to be added and all the services that
have been containerized so far must also be tested in the overcloud. That being
said, I’m personally happy with the progress made so far and I hope you are as
well and that this email is useful to you.

Rock on,
Flavio

[0] https://review.openstack.org/#/c/416421/
[1] https://dprince.github.io/docker-puppet.html
[2] https://review.openstack.org/#/c/416420/
[3] https://review.openstack.org/#/c/423519/
[4] https://etherpad.openstack.org/p/rdo-kolla-build

--
@flaper87
Flavio Percoco

Re: [openstack-dev] gate jobs - papercuts

2017-01-31 Thread Steve Martinelli

On Tue, Jan 31, 2017 at 12:49 PM, Davanum Srinivas 
wrote:

> Folks,
>
> Here's the list of job failures that failed in the gate queue.
> captured with my script[1][2] since around 10:00 AM today. All jobs
> failed with just one bad test.
>
> http://logs.openstack.org/48/423548/11/gate/gate-keystone-
> python27-db-ubuntu-xenial/a1f55ca/
>- keystone.tests.unit.test_v3_auth.TestMFARules
>
> 

This was due to a race condition between token issuance and validation,
should be fixed.
__
OpenStack Development Mailing 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] gate jobs - papercuts

2017-01-31 Thread Matthew Treinish

On Tue, Jan 31, 2017 at 12:49:13PM -0500, Davanum Srinivas wrote:
> Folks,
> 
> Here's the list of job failures that failed in the gate queue.
> captured with my script[1][2] since around 10:00 AM today. All jobs
> failed with just one bad test.
> 
> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/
>- tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/
>  - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
> http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/
>- tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON
> http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/
>  - 
> tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON
> http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/
>- keystone.tests.unit.test_v3_auth.TestMFARules
> http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/
>   - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
> http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/
>- 
> tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps
> 
> So our gate is now 36 deep with stuff running for little more than 4
> hours repeatedly Can folks look deeper please?
> 
> Thanks,
> Dims
> 
> [1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e
> [2] http://paste.openstack.org/show/597071/

Just as an aside this basic view is integrated into the home page on
openstack-health:

http://status.openstack.org/openstack-health/#/

under the section "Failed Tests in Last 10 Failed Runs". It also hooks into
elastic-recheck and will point out e-r hits there too. So, people don't need
to run this script manually to see what is failing.

Thanks,

Matt Treinish


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] [tripleo] Updates from the containers squad: Where are we at?

On Tue, Jan 31, 2017 at 11:13 AM, Flavio Percoco  wrote:
> Greetings,
>
> In the last month, there’s been no update on what’s been happening in the
> containers effort for TripleO so I thought I’d drop an email to… well…
> provide
> updates.
>
> The work in the DFG has been broken down into more granular steps that are
> easier to account for. However, I’d like to focus a bit more on the
> architecture
> side of things first.
>
> There have been some major changes in how containers are deployed within
> TripleO
> and how services are containerized. I’ll try to describe those below but
> bear in
> mind that some details may change a little bit and that this is still a work
> in
> progress.
>
> * The new architecture aims to support a hybrid deployment where it’s
> possible
>  to run some services on baremetal and others on containers. This has been
> done
>  to ease the upgrade process from baremetal nodes to a containerize node and
> it
>  doesn’t change the goal of having all services containerized. More details
>  about this new architecture can be found here[0]. Please, check out the
> README
>  file.
>  * There’s no heat agent container anymore. Instead, we’re installing puppet
> in
>  the base image for every service and then run puppet from the service
>  container. A bit of more details about this change can be found in this
> blog
>  post[0] (Thanks Dan)
>  * The old copy-json file that used to create the config.json for the kolla
> image
>  was replaced with a heat-hook. More about this on this patch.[2]
>  * Several patches for containerizing services have been proposed. TBH,
> we’ve not
>  done a great job at using a single topic BUT if you open the patch[0],
> you’ll
>  see a list of patches depending on it that propose the containerization of
>  several projects.
>  * There’s a non-voting CI job that currently only runs on patches that
> modify
>  files related to the containers work. You can read more about this on this
>  patch[3]. The goal is to make this job voting as soon as Pike starts.

Excellent plan and it's aligned with our TripleO CI with oooq roadmap.

>  * Perhaps more RDO specific but there’s also been great progress in the
> building
>  pipeline for containers. We’re using kolla images as our base container
> images
>  and the image build process is being integrated with the TripleO CI
> pipeline.
>  This means that new images will be created whenever there’s a promotion in
>  TripleO. We’d like to take this one step further for Pike and be able to
> build
>  images on every patch merged in the various projects, just like we’d do
> with
>  RPM packages. I wanted to mention this because I love the fact that this
> helps
>  us testing kolla images thoroughly and also give back to the community in
> some
>  way. More on this can be found here[4]
>  * Support for a containerized deployment has been added to
> tripleo-quickstart
>  and it’s being used for the CI job.
>  * The containers squad will start the work of documenting the current
>  architecture as soon as possible. As mentioned in the points above, there
> have
>  been several changes to the architecture that made starting the
> documentation
>  process not worthwhile. We can start documenting things now that we feel
> more
>  comfortable with the current version of the framework.
>  * We’re starting to work on a strategy for upgrades for baremetal nodes to
>  containerized nodes. Again, this work was waiting for the architecture to
> be
>  polished out a bit more and the composable upgrades work to mature. Now it
>  seems like a good time to kick this off.
>
> Eventually (and likely soon) this will impact other squads and there will be
> need of a joint work towards finalizing the containerization process. More
> details will be provided as part of the documentation and in future emails.
>
> There are still many things to do, though. There are services that still
> need to
> be containerized, there are more CI jobs to be added and all the services
> that
> have been containerized so far must also be tested in the overcloud. That
> being
> said, I’m personally happy with the progress made so far and I hope you are
> as
> well and that this email is useful to you.

Excellent summary Flavio, I wish you could send more updates on $topic :-)
It has been very useful so far.

Thanks,

> Rock on,
> Flavio
>
> [0] https://review.openstack.org/#/c/416421/
> [1] https://dprince.github.io/docker-puppet.html
> [2] https://review.openstack.org/#/c/416420/
> [3] https://review.openstack.org/#/c/423519/
> [4] https://etherpad.openstack.org/p/rdo-kolla-build
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing 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

Re: [openstack-dev] [FFE][requirements] VMware nsxlib 0.7.0

2017-01-31 Thread Gary Kotton

Hi,
At the moment we are the only consuming project. This is blocking us at the 
moment. How do you suggest moving this forwards?
Could we remove the upper constraints?
Thanks
Gary

On 1/31/17, 6:48 PM, "Matthew Thode"  wrote:

On 01/31/2017 10:40 AM, Gary Kotton wrote:
> Hi,
> 
> At the moment we have a number of bugs in the plugin that are addressed
> by the patches here. Could we please get this approved so that the Ocata
> version will be ina state that we can release it. This is blocking us
> for certain uses cases.
> 
> Thanks
> 
> Gary
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Your review also bumps the minimum version (through a bump to
global-requirements.txt).  Codesearch didn't find anything using
vmware-nsxlib in their requirements.txt though.  Any GR update is going
to have knock-on effects, causing every consuming project to have to
re-release.  I'd need buy-in from them before I consider allowing the
gr-update through, though I'm generally fine with the UC update.

-- 
Matthew Thode (prometheanfire)

__
OpenStack Development Mailing 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] gate jobs - papercuts

2017-01-31 Thread Davanum Srinivas

Folks,

Here's the list of job failures that failed in the gate queue.
captured with my script[1][2] since around 10:00 AM today. All jobs
failed with just one bad test.

http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/
   - tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/
 - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/
   - tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON
http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/
 - 
tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON
http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/
   - keystone.tests.unit.test_v3_auth.TestMFARules
http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/
  - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/
   - tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps

So our gate is now 36 deep with stuff running for little more than 4
hours repeatedly Can folks look deeper please?

Thanks,
Dims

[1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e
[2] http://paste.openstack.org/show/597071/

-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing 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] Feature Freeze Exception request for octavia-services-integration

On Tue, Jan 31, 2017 at 12:56 PM, Brent Eagles  wrote:
> Hi,
>
> I'd like to request a feature freeze exception for patches submitted against
> the octavia-services-integration blueprint
> (https://blueprints.launchpad.net/tripleo/+spec/octavia-service-integration).
> The service will not be deployed by default and is not currently part of
> scenario testing so should have little impact on other services. Basic
> configuration of the services is a first step in preparing for fully
> functional Octavia integration
> (https://blueprints.launchpad.net/tripleo/+spec/octavia-support) and
> production readiness. Also, as a fully functional Octavia deployment
> introduces some new issues of what can be done during deployment, having the
> basic services easily deployable allows contributors and other interested
> parties to better evaluate, discuss, develop and test solutions.

no blocker on my side.

> Cheers,
>
> Brent Eagles
>
> __
> OpenStack Development Mailing 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] [TripleO] Proposing Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-01-31 Thread Ben Nemec




On 01/31/2017 11:03 AM, James Slagle wrote:

On Tue, Jan 31, 2017 at 11:02 AM, Ben Nemec  wrote:

In the spirit of all the core team changes, here are a couple more I'd like
to propose.

Dmitry has been very helpful reviewing in instack-undercloud for a long time
so this is way overdue.  I'm also going to propose that he be able to +2
anything Ironic-related in TripleO since that is his primary area of
expertise.

Alex has ramped up quickly on TripleO and has also been helping out with
instack-undercloud quite a bit.  He's already core for the puppet modules,
and a lot of the changes to instack-undercloud these days are primarily in
the puppet manifest so it's not a huge stretch to add him.

As usual, TripleO cores please vote and/or provide comments.  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


+1. Dmitry is also one of the top reviewers and committers to
tripleo-docs. I wouldn't be opposed to him having +2 there as well.



Oh, good call.  I forgot to mention that too.  +1 to adding him as docs 
core as well.


__
OpenStack Development Mailing 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] [watcher][keystone] getting AttributeError: 'module' object has no attribute 'epoll'

2017-01-31 Thread Pradeep Singh

Thanks Christophe, I will give it a try.

Thanks,
Pradeep

On Tuesday, January 31, 2017, Christophe Fontaine <
christophe.fonta...@qosmos.com> wrote:

> Hi,
> I got the same problem in a totally different project, but with the same
> error.
> From what I saw, the problem do not come from requests, but from
> urllib3, which was updated to version 1.20 [1] 2 weeks ago.
>
> Using urllib3 version 1.19 resolved my issue.
>
> Hope this helps,
> Christophe
>
> [1] https://pypi.python.org/pypi/urllib3/1.20
>
>
> On 01/31/2017 12:11 PM, Чадин Александр wrote:
>
>> Hi Pradeep Singh.
>>
>> Seems that there are some issues with requests 2.13.0.
>> Try to install requests==2.12.0
>>
>> Best wishes,
>> ___
>> Alexander Chadin,
>> Engineer
>> Software Solutions Department
>> Servionica Ltd.
>> Work email: a.cha...@servionica.ru 
>> Mobile: +7(916)693-58-81
>>
>> On 28 Jan 2017, at 19:31, Pradeep Singh >> > wrote:
>>>
>>> Hello All,
>>>
>>> I am installing watcher  following[1].
>>> I have executed the commands mentioned here[2] to install the watcher.
>>> When i execute the command 'watcher strategy list', i am getting below
>>> exception:
>>>
>>> AttributeError: 'module' object has no attribute 'epoll' in watcher-api.
>>>
>>> Full stack trace of the logs are here[3].
>>>
>>> Could you please help me in resolving the issue. Thanks.
>>>
>>>
>>> [1]http://docs.openstack.org/developer/watcher/deploy/installation.html.
>>> [2]http://paste.openstack.org/show/596805/
>>> [3]http://paste.openstack.org/show/596803/
>>> 
>>> __
>>> OpenStack Development Mailing 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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> This message, including attachments, is CONFIDENTIAL. It may also be
> privileged or otherwise protected by law. If you received this email by
> mistake, please let us know by reply and then delete it from your system;
> you should not copy it or disclose its contents to anyone. All messages
> sent to and from Enea may be monitored to ensure compliance with internal
> policies and to protect our business. Emails are not secure and cannot be
> guaranteed to be error free as they can be intercepted, amended, lost or
> destroyed, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of email transmission. Anyone who communicates with
> us by email accepts these risks.
>
> __
> OpenStack Development Mailing 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] [Shaker] Shaker Image Builder fails in Ocata due to OS::Glance::Image deprecation

2017-01-31 Thread Sai Sindhur Malleni

Hey,

Starting Ocata, looks like only glance v2 is enabled by default. This
breaks the shaker image builder template since we make use of the resource
type OS::Glance::Image and creating images from url links is not supported
in v2. How do we want deal with this? Maybe have the user pass in the
name/image-id and pass them as properties to the shaker image builder
template or instead advise the use to turn on the v1 API?
Thoughts/suggestions?

-- 
Sai Sindhur Malleni
Software Engineer
Red Hat Inc.
100 East Davie Street
Raleigh, NC, USA
Work: (919) 754-4557 | Cell: (919) 985-1055
__
OpenStack Development Mailing 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] [elastic-recheck] Miscellaneous questions of potential Neutron interest

2017-01-31 Thread Ihar Hrachyshka

Hi all,

we were looking at expanding usage of elastic-recheck in Neutron, and
several questions popped up that we would like to ask.

1. Are all jobs eligible for coverage with queries? The reason we ask
is that there was some disagreement on whether all job runs are
eligible, or e.g. gate queue job runs only. For example, in Neutron,
we have fullstack and functional tests that are in check queue but not
in gate queue. Can we still post queries for those jobs? Will e-r bot
match against those queries?

2. Review velocity is not stable in the project. Sometimes we get
immediate reviews, sometimes not so much (the last one took me a month
to land a query). It's important that new queries get timely feedback.
Can we consider expanding core reviewer team to smoothen the process?
If not, how can we make sure queries land in time?

3. I see some IRC channels have elastic-recheck bot reporting about
identified failures in the channels. How can we add the bot to our
channel?

Thanks for the answers,
Ihar

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

Re: [openstack-dev] [elastic-recheck] Miscellaneous questions of potential Neutron interest

2017-01-31 Thread Matthew Treinish

On Tue, Jan 31, 2017 at 10:38:58AM -0800, Ihar Hrachyshka wrote:
> Hi all,
> 
> we were looking at expanding usage of elastic-recheck in Neutron, and
> several questions popped up that we would like to ask.
> 
> 1. Are all jobs eligible for coverage with queries? The reason we ask
> is that there was some disagreement on whether all job runs are
> eligible, or e.g. gate queue job runs only. For example, in Neutron,
> we have fullstack and functional tests that are in check queue but not
> in gate queue. Can we still post queries for those jobs? Will e-r bot
> match against those queries?

The elastic recheck bot listens to all jobs, and we can add queries for
any gate failure. In the past we limited it to just dsvm jobs and just projects
in openstack/ namespace. But we haven't done either of those in a really long 
time,
the dsvm limitation was just for like the first month of the project.
> 
> 2. Review velocity is not stable in the project. Sometimes we get
> immediate reviews, sometimes not so much (the last one took me a month
> to land a query). It's important that new queries get timely feedback.
> Can we consider expanding core reviewer team to smoothen the process?
> If not, how can we make sure queries land in time?

Well there are really only 3 cores on the project, and if some of us aren't
working or are busy with other things the queue can get backed up and things
fall through the cracks. Although, fwiw new queries aren't a steady stream
either. We've gone months where just mriedem or me were the only people
pushing queries.

I'm totally in favor of expanding the review team, the issue here is that not
many people have stood up to start tackling reviews. The only reviews from
non-cores I normally see are people from a project team piling on to a query
for a bad gate bug they're hitting at the time. e-r queries aren't that hard
to review and there are just a few things we look for which are outlined here:
https://github.com/openstack-infra/elastic-recheck#queries
if people step up and start helping out with the review load we definitely can
expand the core team.

> 
> 3. I see some IRC channels have elastic-recheck bot reporting about
> identified failures in the channels. How can we add the bot to our
> channel?

This is a just specified in a config file:

https://github.com/openstack-infra/puppet-elastic_recheck/blob/master/files/recheckwatchbot.yaml#L1-L7

It's just no project (besides QA) has ever chosen to subscribe to irc
notifications before. There was discussion about it back when we first
introduced the bot, but it wasn't turned on because of concerns around channel
noise. (https://review.openstack.org/#/c/79123/ )

What the bot reports to irc is also configurable. So you can have it return
on failures for a particular project (or group of projects) and also only on
identified or unidentified failures.

Thanks,

Matt Treinish

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] [containers][magnum] Swarm Mode template

2017-01-31 Thread Kevin Lefevre

On Tue, 2017-01-31 at 17:01 +0100, Spyros Trigazis wrote:
> Hi.
> 
> I have done it by checking the ip address of the master. The current
> state of
> the heat drivers doesn't allow the distinction between master > 1 or
> master=1.
> 

Please, could you elaborate on this ?

Also what is your opinion about starting a new swarm driver for swarm
mode ?  

> Spyros
> 
> 
> 
> On 31 January 2017 at 16:33, Kevin Lefevre 
> wrote:
> > Hi, Docker 1.13 has been released with several improvements that
> > brings
> > swarm mode principles closer to Kubernetes such as docker-compose
> > service swarm mode.
> > 
> > I'd like to implement a v2 swarm template. I don't know if it's
> > already
> > been discussed.
> > 
> > Swarm mode is a bit different but a lot simpler to deploy than
> > Swarm
> > Legacy.
> > 
> > In Kubernetes you can deploy multiples masters at the same time but
> > in
> > swarm mode you have to:
> > - bootstrap a first docker node
> > - run docker swarm init
> > - get a token (worker or manager)
> > - bootstrap other worker
> > - use manager or worker token depending manager count.
> > 
> > I don't know what is the best way to do so in HEAT. I'm sure there
> > are
> > multiple options (I'm not an expert in HEAT i don't know if they
> > are
> > feasible) :
> > 
> > - Bootstrap a first server
> > - Wait for it to ready, run docker swarm init, get both manager and
> > worker tokens
> > - if manager count >1, we can bootstrap another resource group for
> > extra managers which will use a manager token.
> > - Bootstrap the rest of the worker and use a worker token.
> > 
> > The difficulty is to handle multiples master properly, i'd like to
> > hear
> > your ideas about that.
> > 
> > 
> > --
> > Kevin Lefevre
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- 
Kevin Lefevre

__
OpenStack Development Mailing 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 Dmitry Tantsur and Alex Schultz as instack-undercloud cores

2017-01-31 Thread Brent Eagles

On Tue, Jan 31, 2017 at 12:32 PM, Ben Nemec  wrote:

> In the spirit of all the core team changes, here are a couple more I'd
> like to propose.
>
> Dmitry has been very helpful reviewing in instack-undercloud for a long
> time so this is way overdue.  I'm also going to propose that he be able to
> +2 anything Ironic-related in TripleO since that is his primary area of
> expertise.
>
> Alex has ramped up quickly on TripleO and has also been helping out with
> instack-undercloud quite a bit.  He's already core for the puppet modules,
> and a lot of the changes to instack-undercloud these days are primarily in
> the puppet manifest so it's not a huge stretch to add him.
>
> As usual, TripleO cores please vote and/or provide comments.  Thanks.
>
> -Ben
>
>
+1!

Cheers,

Brent
__
OpenStack Development Mailing 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] Neutron CI team meeting

2017-01-31 Thread Armando M.

Hi folks,

Recently [1], a new meeting has been setup to give the neutron team a
dedicated time to discuss any upstream CI matter (gate issues, testing
strategies, etc), as well as an overflow space to be used after the main
team meeting section [3]. Kudos to Ihar for being our first chair.

Needless to say, attendance is welcome.

Cheers,
Armando

[1] https://review.openstack.org/#/c/426311/
[2] https://wiki.openstack.org/wiki/Meetings/NeutronCI
[3] https://wiki.openstack.org/wiki/Network/Meetings#Bugs_and_Gate_issues
__
OpenStack Development Mailing 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] Make sure you have placement-api running in dsvm jobs on master


This is a quick heads up that once this nova change merges:

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

The n-cpu service will fail to start in dsvm jobs unless the 
placement-api service is also enabled, which it is by default in devstack:


https://github.com/openstack-dev/devstack/blob/0c6956862e6ac1cdb51b674c872183074df98c50/stackrc#L58

This is the warning in case you've been overriding services but you're 
still running nova in your dsvm CI jobs.


--

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] gate jobs - papercuts

2017-01-31 Thread Matthew Treinish

On Tue, Jan 31, 2017 at 01:19:41PM -0500, Steve Martinelli wrote:
> On Tue, Jan 31, 2017 at 12:49 PM, Davanum Srinivas 
> wrote:
> 
> > Folks,
> >
> > Here's the list of job failures that failed in the gate queue.
> > captured with my script[1][2] since around 10:00 AM today. All jobs
> > failed with just one bad test.
> >
> > http://logs.openstack.org/48/423548/11/gate/gate-keystone-
> > python27-db-ubuntu-xenial/a1f55ca/
> >- keystone.tests.unit.test_v3_auth.TestMFARules
> >
> > 
> 
> 
> This was due to a race condition between token issuance and validation,
> should be fixed.

Is there a bug open for this? If so lets get an elastic-recheck query up for it
so we can track it and get it off the uncategorized page:

http://status.openstack.org/elastic-recheck/data/integrated_gate.html

Our categorization rate is quite low right now and it'll only make things harder
to debug other failures if we've got a bunch of unknown races going on.

We have a lot of tools to make debugging the gate easier and making everyone 
more
productive. But, it feels like we haven't been utilizing them fully lately which
makes gate backups more likely and digging out of the hole harder.

Thanks,

Matt Treinish

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] [containers][magnum] Swarm Mode template

2017-01-31 Thread Spyros Trigazis

Hi,

The hack-ish way is to check if the current master has a different ip than
the
swarm_api_api and based on that decide whether to swarm init or join. The
proper way is to have two resource groups (as you said) one for the primary
master and one for the secondary masters. This requires some plumping
though.

We decided two have a _v2 driver in /contrib initially. I have a prototype
working
based on fedora-25 (docker 1.12.6). I can push and work together on it, if
you
want.

Spyros

On 31 January 2017 at 20:52, Kevin Lefevre  wrote:

> On Tue, 2017-01-31 at 17:01 +0100, Spyros Trigazis wrote:
> > Hi.
> >
> > I have done it by checking the ip address of the master. The current
> > state of
> > the heat drivers doesn't allow the distinction between master > 1 or
> > master=1.
> >
>
> Please, could you elaborate on this ?
>
> Also what is your opinion about starting a new swarm driver for swarm
> mode ?
>
> > Spyros
> >
> >
> >
> > On 31 January 2017 at 16:33, Kevin Lefevre 
> > wrote:
> > > Hi, Docker 1.13 has been released with several improvements that
> > > brings
> > > swarm mode principles closer to Kubernetes such as docker-compose
> > > service swarm mode.
> > >
> > > I'd like to implement a v2 swarm template. I don't know if it's
> > > already
> > > been discussed.
> > >
> > > Swarm mode is a bit different but a lot simpler to deploy than
> > > Swarm
> > > Legacy.
> > >
> > > In Kubernetes you can deploy multiples masters at the same time but
> > > in
> > > swarm mode you have to:
> > > - bootstrap a first docker node
> > > - run docker swarm init
> > > - get a token (worker or manager)
> > > - bootstrap other worker
> > > - use manager or worker token depending manager count.
> > >
> > > I don't know what is the best way to do so in HEAT. I'm sure there
> > > are
> > > multiple options (I'm not an expert in HEAT i don't know if they
> > > are
> > > feasible) :
> > >
> > > - Bootstrap a first server
> > > - Wait for it to ready, run docker swarm init, get both manager and
> > > worker tokens
> > > - if manager count >1, we can bootstrap another resource group for
> > > extra managers which will use a manager token.
> > > - Bootstrap the rest of the worker and use a worker token.
> > >
> > > The difficulty is to handle multiples master properly, i'd like to
> > > hear
> > > your ideas about that.
> > >
> > >
> > > --
> > > Kevin Lefevre
> > >
> > > ___
> > > ___
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > > bscribe
> > > 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:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> Kevin Lefevre
>
> __
> OpenStack Development Mailing 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] [ffe][requirements][gnocchi] upper-constraint gnocchiclient 3.0.0

2017-01-31 Thread gordon chung

hi,

we'd like to request this patch be accepted: 
https://review.openstack.org/#/c/426917/

the new client removes some encoding done that was previously required 
by gnocchiv3 and ceilometer newton but is not relevant to either 
ceilometer ocata or gnocchi v3.1 (which we are trying to release). 
because this encoding remains in gnocchiclient 2.8.2, we cannot merge 
require changes to gnocchi since the new gnocchi doesn't understand 
encoding. there is no way for gnocchi understand both.

cheers,
-- 
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

Re: [openstack-dev] [ironic] New mascot design

2017-01-31 Thread Rafael Xavier

Hey. 

Just missing the drumsticks. 

\m/ ʕ•͡ᴥ•ʔ \m/ 


Regards. 

--- 
Rafael Xavier 
Federal University of Campina Grande 
Distributed Systems Lab 


From: "Jim Rollenhagen"  
To: "OpenStack Development Mailing List (not for usage questions)" 
 
Sent: Terça-feira, 31 de janeiro de 2017 17:49:09 
Subject: [openstack-dev] [ironic] New mascot design 

Hey ironic-ers, 

The foundation has passed along a new version of our mascot (attached) to us, 
and would like your feedback on it. 

They're hoping to have all mascot-related things ready in time for the PTG, so 
please do send your thoughts quickly, if you have them. :) 

// jim 

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

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

Re: [openstack-dev] gate jobs - papercuts


On 1/31/2017 11:49 AM, Davanum Srinivas wrote:

Folks,

Here's the list of job failures that failed in the gate queue.
captured with my script[1][2] since around 10:00 AM today. All jobs
failed with just one bad test.

http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/
   - tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/
 - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/
   - tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON
http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/
 - 
tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON
http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/
   - keystone.tests.unit.test_v3_auth.TestMFARules
http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/
  - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/
   - tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps

So our gate is now 36 deep with stuff running for little more than 4
hours repeatedly Can folks look deeper please?

Thanks,
Dims

[1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e
[2] http://paste.openstack.org/show/597071/



I know of two issues impacting the cells v1 job, one of which is fixed, 
the other has a patch recently posted.


The first was one I posted about last night, total blocker for the cells 
v1 job which was kicking things out of the gate for Nova, but that is fixed:


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

The other one that's not fixed yet (was just identified today) has a 
patch up now:


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

--

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] gate jobs - papercuts

2017-01-31 Thread Davanum Srinivas

Thanks MattT, MattR and Steve. Since that last update 4 runs failed

http://logs.openstack.org/20/396620/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/e82ace8/
* tempest.api.compute.admin.test_migrations.MigrationsAdminTest -
test_resize_server_revert_deleted_flavor
* tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON
- test_create_list_show_delete_interfaces

http://logs.openstack.org/45/423645/19/gate/gate-grenade-dsvm-neutron-dvr-multinode-ubuntu-xenial/61dbd0e/
http://logs.openstack.org/45/423645/19/gate/gate-grenade-dsvm-neutron-dvr-multinode-ubuntu-xenial/61dbd0e/
* Both runs failed with the following
  "Failed to fetch
http://mirror.regionone.osic-cloud1.openstack.org/ubuntu/pool/main/o/openssl/openssl_1.0.2g-1ubuntu4.6_amd64.deb;

* 
http://logs.openstack.org/04/427004/2/gate/gate-keystone-python35-db/1502dbe/console.html
  35 mins of zero logs and then timed out

Thanks,
Dims

On Tue, Jan 31, 2017 at 3:32 PM, Matt Riedemann  wrote:
> On 1/31/2017 11:49 AM, Davanum Srinivas wrote:
>>
>> Folks,
>>
>> Here's the list of job failures that failed in the gate queue.
>> captured with my script[1][2] since around 10:00 AM today. All jobs
>> failed with just one bad test.
>>
>>
>> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/ecb3d0a/
>>-
>> tempest.api.compute.servers.test_servers_negative.ServersNegativeTestJSON
>>
>> http://logs.openstack.org/48/426448/2/gate/gate-tempest-dsvm-neutron-full-ssh/71f6c8c/
>>  - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
>>
>> http://logs.openstack.org/48/376548/8/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/cf3028b/
>>- tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON
>>
>> http://logs.openstack.org/68/417668/8/gate/gate-tempest-dsvm-neutron-full-ssh/27bda02/
>>  -
>> tempest.api.compute.volumes.test_attach_volume.AttachVolumeShelveTestJSON
>>
>> http://logs.openstack.org/48/423548/11/gate/gate-keystone-python27-db-ubuntu-xenial/a1f55ca/
>>- keystone.tests.unit.test_v3_auth.TestMFARules
>>
>> http://logs.openstack.org/61/424961/1/gate/gate-tempest-dsvm-cells-ubuntu-xenial/8a1f9e7/
>>   - tempest.api.compute.admin.test_servers.ServersAdminTestJSON
>>
>> http://logs.openstack.org/23/426823/3/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/0204168/
>>-
>> tempest.scenario.test_security_groups_basic_ops.TestSecurityGroupsBasicOps
>>
>> So our gate is now 36 deep with stuff running for little more than 4
>> hours repeatedly Can folks look deeper please?
>>
>> Thanks,
>> Dims
>>
>> [1] https://gist.github.com/dims/54b391bd5964d3d208113b16766ea85e
>> [2] http://paste.openstack.org/show/597071/
>>
>
> I know of two issues impacting the cells v1 job, one of which is fixed, the
> other has a patch recently posted.
>
> The first was one I posted about last night, total blocker for the cells v1
> job which was kicking things out of the gate for Nova, but that is fixed:
>
> https://review.openstack.org/#/c/427009/
>
> The other one that's not fixed yet (was just identified today) has a patch
> up now:
>
> https://review.openstack.org/#/c/427394/
>
> --
>
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing 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] [ironic] New mascot design

2017-01-31 Thread Jim Rollenhagen

Hey ironic-ers,

The foundation has passed along a new version of our mascot (attached) to
us, and would like your feedback on it.

They're hoping to have all mascot-related things ready in time for the PTG,
so please do send your thoughts quickly, if you have them. :)

// 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] [ffe][requirements][gnocchi] upper-constraint gnocchiclient 3.0.0